Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 26/01/2019 7.34 PM, unman wrote:
> On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net
> wrote:
>> 
>> Am I right in thinking  that the recently discovered apt
>> vulnerability (DSA 4371-1) in Debian based systems could and
>> should have been mitigated against many years ago  by downloading
>> and activating an apt package; "apt-transport-https", which
>> forces apt updates via https? The researcher (Max Justicz) who
>> discovered the vulnerability has stated it couldn't have been
>> exploited if https had been implemented.
>> 
>> If "apt-transport-https" is the magic bullet, why in the past
>> hasn't it been implemented by default? And, why for the future,
>> is it not being implemented immediately by Qubes, Debian et al?
>> 
>> During the past decade many people with good foresight had
>> predicted the apt vulnerabilty and urged administrators to
>> install the solution;"apt-transport-https". Regrettably, the
>> vocal majority of so-called experts said that's unnecessary
>> because the packages are signed. Was that incompetent advice? or
>> was it a coordinated response from agents of State Actors to hide
>> a deliberate backdoor? I've no idea, but given Snowdens
>> revelations I would not rule anything out.
> 
> No you're not right in thinking this. You seem to have missed the
> section where Max explicitly say that "a malicious mirror could
> still exploit a bug like this, even with https." So
> apt-transport-https is no magic bullet, particularly as a cursory 
> glance suggests that it allows forcing SSL version to SSLv3, which
> is known to be insecure.
> 
> Imagine that apt-transport-https *had* been adopted - have you
> actually looked at the list of vulnerabilities in libcurl, and the
> various breakages in the TLS CA system? I can imagine some one 
> posting exactly like you: "Was the move to https incompetent
> advice? or was it a coordinated response from agents of State
> Actors to hide a deliberate backdoor? I've no idea, but given
> Snowdens revelations I would not rule anything out."
> 
> I would rule some things out. And in this case it looks like a
> simple mistake. And if you read any of the arguments re http/https
> you'd see that there are reasonable arguments on both sides, and
> the "so called experts" took reasoned positions.
> 
> It's always been open to you to install the package and switch to
> https transport in your Debian templates, of course. And Qubes had
> already started to use that by default too. Not to downplay the
> importance of the bug, but let's not lose our heads.
> 

In addition, from a Qubes perspective, it's worth reiterating this
part of the QSB:

| Normally, we do not release Qubes Security Bulletins (QSBs) to address
| vulnerabilities that only affect VMs internally without affecting the
| rest of the Qubes system, i.e. vulnerabilities that do not undermine
| the Qubes security model.
|
| For example, we do not release QSBs to address bugs in Firefox or
| Linux kernel USB stacks, because Qubes OS was designed under the
| primary assumption that in a typical desktop OS there will be
| countless such bugs and that humankind will never be able to patch all
| of them promptly (at least not as quickly as developers introduce new
| bugs). This is, in fact, the very reason we designed Qubes OS as an
| implementation of the security-by-compartmentalization approach.

Whenever we're tempted to ask, "Why didn't Qubes secure X inside of a
domU?" we should remember this. Not only is it unrealistic to expect
the small Qubes team to fix vulnerabilities in software that many
larger teams have failed to fix; it also misses the whole point of
Qubes in the first place, which is to accept that such vulnerabilities
are inevitable and protect ourselves from them by compartmentalizing
them, limiting the damage they can do.

[I can imagine a cynic responding, "Then why did you issue a QSB at
all?" Even though there was no failure in the Qubes security model
here (in fact, it did exactly what it was supposed to by limiting the
damage this bug could do), we care far more about keeping users safe
than about the "optics" of issuing a QSB. We would rather let some
people misinterpret the situation and mistakenly think that this shows
some flaw in Qubes if it means getting the word out so our users can
secure their systems as quickly as possible.]

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxNHwUACgkQ203TvDlQ
MDBzvhAAwRQ6ZjTY/dznI3o9fsR9ZSiv0gaCwZYRDqNwoUvXQqKlnqOLhV4Z8WuN
8F3Jcd812AcRIFmsmCXDiFQIW7SF59ywmtwRTukbpuVty+ZdxbIq5zo9WriZH93k
1P/91onvoCrtGI2CgTR8yb0PRF3xBhsKHwmFkKj4Kq1ablM2l1UYlN3VZ6GjxLlc
TyXus26LChVm48jcoOB3PTMKpWw91LbTQPebl3OlwhpsilCWKSw0ge3MylLMFJLr
q2MGmUxCtpJQTaoyMEAAReEEiV/UaytTJikDQcQ3YjiaCVqxodYqD5/dUfD5lFLp
+o7a6wb//eHtwCMQG+RWWIlLaxNlPsUxT2BvujVmNeOn+e1z+jdktRxXK/Vknq8d

Re: [qubes-users] Help installing package in template VM via snap

2019-01-26 Thread unman
On Sat, Jan 26, 2019 at 01:33:15PM +0100, 799 wrote:
> Hello,
> 
> I am trying to update my multimedia howto for Qubes and would like to use
> a  fedora-29--minimal template instead of debian.
> 
> I try to install a package via snap but the template VM is not allowed to
> access the repository:
> 
> snap install , results in:
> api.snapcraft.io ... read: connection refused.
> 
> Question:
> What are the correct steps to allow internet access for the template VM?
> If possible only to api.snapcraft.io?
> 
> I looked at the Qubes docs https://www.qubes-os.org/doc/software-update-vm/
> but couldn't find a solution, can someone point me into the right direction?
> 

There's a package in qubes-testing which you can install in the template
qubes-snapd-helper. You can then use snap in qubes based on the template
- I think that will fit your use case.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127020944.3vrwb435fgk3bgpy%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread unman
On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote:
> 
> Am I right in thinking  that the recently discovered apt vulnerability
> (DSA 4371-1) in Debian based systems could and should have been
> mitigated against many years ago  by downloading and activating an apt
> package; "apt-transport-https", which forces apt updates via https? The
> researcher (Max Justicz) who discovered the vulnerability has stated it 
> couldn't have been exploited if https had been implemented.
> 
> If "apt-transport-https" is the magic bullet, why in the past hasn't it
> been implemented by default? And, why for the future, is it not being
> implemented immediately by Qubes, Debian et al?
> 
> During the past decade many people with good foresight had predicted the
> apt vulnerabilty and urged administrators to install the
> solution;"apt-transport-https". Regrettably, the vocal majority of
> so-called experts said that's unnecessary because the packages are
> signed. Was that incompetent advice? or was it a coordinated response
> from agents of State Actors to hide a deliberate backdoor? I've no idea,
> but given Snowdens revelations I would not rule anything out.

No you're not right in thinking this.
You seem to have missed the section where Max explicitly say that "a
malicious mirror could still exploit a bug like this, even with https."
So apt-transport-https is no magic bullet, particularly as a cursory
glance suggests that it allows forcing SSL version to SSLv3, which is
known to be insecure.

Imagine that apt-transport-https *had* been adopted - have you actually
looked at the list of vulnerabilities in libcurl, and the various
breakages in the TLS CA system? I can imagine some one
posting exactly like you: "Was the move to https incompetent advice? or
was it a coordinated response from agents of State Actors to hide a
deliberate backdoor? I've no idea, but given Snowdens revelations I
would not rule anything out."

I would rule some things out. And in this case it looks like a simple
mistake. And if you read any of the arguments re http/https you'd see
that there are reasonable arguments on both sides, and the "so called
experts" took reasoned positions.

It's always been open to you to install the package and switch to https
transport in your Debian templates, of course. And Qubes had already
started to use that by default too.
Not to downplay the importance of the bug, but let's not lose
our heads.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127013421.7pdxo4adq4tmqefe%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: looking for quickest way to copy text from dom0-Terminal to another VM

2019-01-26 Thread unman
On Sat, Jan 26, 2019 at 09:39:47AM +0100, 799 wrote:
> Am Sa., 26. Jan. 2019, 04:33 hat Andrew David Wong 
> geschrieben:
> 
> >
> > Please take a look at this issue:
> >
> > https://github.com/QubesOS/qubes-issues/issues/3571
> 
> 
> 
> Happy to see that this topic (no clipboard from dom0) is at least known.
> I don't agree that copying from dom0 is dangerous because "The user could
> have secrets in dom0, e.g., keyfiles".
> 
> 
> My passwords are in a vault VM and if someone messes up handling from dom0
> it is very likely that he/she didn't understand the security concept behind
> Qubes and therefore the user is likely the biggest attack surface NOT the
> clipboard.
> 
> Please offer a solution where the user can choose (free software!!) to
> enable/disable the clipboard (choosing means freedom).
> 
> It seems there is a workaround, can this be bound to a key (maybe also
> using xclip in dom0)?
> echo -n dom0 > qubes-clipboard.bin.source .
> 
Of course there's a workaround:
 | tee file
qvm-copy-to-vm  file

You can script this and create a key binding yourself.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127005844.umz6ewf36xnyozwm%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] QSB #46: APT update mechanism vulnerability

2019-01-26 Thread unman
On Sat, Jan 26, 2019 at 11:42:27AM +0100, Alexandre Belgrand wrote:
> Le mercredi 23 janvier 2019 ŕ 18:05 +0100, Marek Marczykowski-Górecki a
> écrit :
> > We have just published Qubes Security Bulletin (QSB) #46:
> > APT update mechanism vulnerability.
> 
> Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
> and injection may occur during apt-get install/update using man-in-the-
> middle attack, at least in some countries. Unless packages are compiled
> with reproducible builds and fingerprints are available online, there
> is no way to avoid such an attack.

What a great start to the week.
Do you have *any* evidence for this claim?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190127005426.3qne7kcdcvv6pses%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] yubikey full disk encryption install help needed

2019-01-26 Thread imamushroom
Hello,

I'm running Qubes 4.01 and on a Lenovo T430 and my root partition is encrypted.

I want to install a yubikey challenge-response for the disk encryption password 
but having difficulty working out how to do it. I'm a qubes newbie.

I've seen this https://github.com/eworm-de/mkinitcpio-ykfde package but I can't 
seem to install the software on dom0 and follow the instructions, presumably 
this is for security reasons. 

Would I need to install it on to dom0 or would another vm like sys_usb be more 
appropriate?

Could anyone give any instructions on how to do this in qubes please, even if 
it is using a different software package.

Thanks in advance,
imamushroom

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c6a4fbe1-ab8d-4ed4-b685-18741445ee14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: looking for quickest way to copy text from dom0-Terminal to another VM

2019-01-26 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 26/01/2019 2.39 AM, 799 wrote:
> Am Sa., 26. Jan. 2019, 04:33 hat Andrew David Wong 
>  geschrieben:
> 
>> 
>> Please take a look at this issue:
>> 
>> https://github.com/QubesOS/qubes-issues/issues/3571
> 
> 
> 
> Happy to see that this topic (no clipboard from dom0) is at least 
> known. I don't agree that copying from dom0 is dangerous because 
> "The user could have secrets in dom0, e.g., keyfiles".
> 
> 
> My passwords are in a vault VM and if someone messes up handling 
> from dom0 it is very likely that he/she didn't understand the 
> security concept behind Qubes and therefore the user is likely the 
> biggest attack surface NOT the clipboard.
> 

There are legitimate uses for secrets in dom0. For example, the
Qubes backup system requires the encryption secret for the backup to
be in dom0.

> Please offer a solution where the user can choose (free
> software!!) to enable/disable the clipboard (choosing means
> freedom).
> 

Well, "free software" doesn't mean that anyone else is forced to
implement whichever features you personally want for you in order to
give you all the choices you want. Rather, it means that you're free
to modify the software yourself in order to use it the way you want:

https://en.wikipedia.org/wiki/Free_software

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxM1wMACgkQ203TvDlQ
MDC0JA//e3LtdyTqodBJypPxispE2136xpCXZzB6olKJ7Ylz2wTxZG1VUSvKjiQR
rb3QOZzIJpebcNkBLd4cQzNJmDEYL9uUK+FkvsvDbhO08wk7MYcKSzwfCRfjWMuP
7six9Aag4n7Iiov5dSjoD/y7MMIyudfOW7PEN7CG5mmgVYGWgtUD3VVas/xp6wE+
JygAe1Y78xQo9rs9LQTPU0VT2O1IDIpcJ+qgZpdIlHmEqPLqqJKp9IHviKjhqceX
I8apkxdkfE8jPZ7CQm8QIcKmCv1mxGfpztKDFD3UwQG8m8xOr5EyzUasJUp3pYk8
vUHHpa/y2kGLTJOmYlCLqMoHhaOvmtr2slScv6qbN4NvUCQksJUYdkfHNwoNqhV+
8eeuJG6Bk0KtahWdk2hMvFD4xv3UzaveC6wuzX9GcjVlT/XURJlt2oFeHRAasMCD
8emT4zcIUR5V+2oiwWUspLISW+0GD2+OtibhiyXKfrJcvnIe8N6MDBm0WjAvK5lE
c9gEAFfZdW38Fl+Q6trnWDahzOCLdL1H84nLYUUz4GHaF1CJRPt8rz29R0U21C8E
8/cHz1W5ILLe4VNdvDMri3fVz4jN9ScK+doRZTW6F4d7g9z0ZRFHUM55MsK2sLC1
wlGRemCQTY7tNHE4ilw92AUYK4k7Fx0zRphyfJX3uHQ/dsAybsI=
=CIzB
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8660c7ec-b2ae-dcb7-f604-27cf892f4f74%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] QSB #46: APT update mechanism vulnerability

2019-01-26 Thread Chris Laprise

On 01/26/2019 05:42 AM, Alexandre Belgrand wrote:

Le mercredi 23 janvier 2019 à 18:05 +0100, Marek Marczykowski-Górecki a
écrit :

We have just published Qubes Security Bulletin (QSB) #46:
APT update mechanism vulnerability.


Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
and injection may occur during apt-get install/update using man-in-the-
middle attack, at least in some countries. Unless packages are compiled
with reproducible builds and fingerprints are available online, there
is no way to avoid such an attack.



WAT?

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ef6f8a6b-2bcf-17d3-2798-402906016f4b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: QSB #46: APT update mechanism vulnerability

2019-01-26 Thread John S.Recdep
On 1/26/19 6:41 PM, Aly Abdellatif wrote:
> @John S.cde
> 
> 1. Go into sys-firewall and delete rpms available in 
> /var/lib/qubes/dom0-updates/packages
> 
> and then in dom0 use sudo qubes-dom0-update qubes-template-whonix-gw-14
> --enablerepo=qubes*testing --clean   
> 
> 

there is nothing in that dir/  (in sys-firewall) nor  in sys-net
/packagesbut  it seems removing them from /var/lib/qubes/updates/rpm
  fixed   the diskquota  error 



on an interesting note folks over at other distros  like  linuxmint seem
wholly unconcerned with reinstall and seem certainthat just
upgrading apt is all that is necessary



when I mentioned that recent comment  in this thread  about  "stolen
keys"  I am asked for a reference for this, and accused of FUD   :)

I am not a SA, so that comment would be very serious if true correct ?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9886bfcb-7e87-85b6-c8c2-46eb6a7d5499%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ALL VMs are not working -- qmemman

2019-01-26 Thread Aly Abdellatif
This also worked for me .

Thanks a lot Lorenzo !!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/528bc506-0e2d-4696-9430-0aa994fd0227%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ALL VMs are not working -- qmemman

2019-01-26 Thread Nick Darren
On Sunday, January 27, 2019 at 1:04:11 AM UTC+8, Lorenzo Lamas wrote:
> I also had this error after installing these packages from Dom0 
> Security-Testing repo.
> I posted about it in the QSB #46 thread, but havent got a reply there. 
> Fortunately, with help of someone else I was able to fix it:
> https://groups.google.com/d/msg/qubes-users/5D8AxG3jtdw/CqyWjGEiGgAJ

Thank you Lorenzo, that's indeed an issues with that and now everything is 
working back as usual. I nearly boot onto live-cd and revert those packages, 
back to the old version but your mail really saves us this time!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16c0f48e-ff60-46a6-b06f-d0818d149889%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: QSB #46: APT update mechanism vulnerability

2019-01-26 Thread Aly Abdellatif
@John S.Recdep

1. Go into sys-firewall and delete rpms available in 
/var/lib/qubes/dom0-updates/packages

and then in dom0 use sudo qubes-dom0-update qubes-template-whonix-gw-14
--enablerepo=qubes*testing --clean   


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5c645f57-61b9-4be9-ba46-f88db35e2270%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: QSB #46: APT update mechanism vulnerability

2019-01-26 Thread John S.Recdep
On 1/26/19 9:30 AM, Aly Abdellatif wrote:
> @John S redcap
> 
> Go into the updateVM and delete unneeded rpms :
> /var/lib/qubes/dom0-updates/packages
> 
> If you didnt change your updateVM, it will be in sys-firewall
> 
> And then add  - - clean in your qubes-dom0-update 
> Command
> 


hmm, this is a /var/lib/qubes/updates/rpm/directory with 4 rpm in it
(2 whonix-gw one is the 2018, one the 2019, 1 deb-9 2019 and 1 whonix-ws
 2018)

(there is no /var/lib/qubes/dom0-updatesjust  /updatesin this
4.0-> 4.1 install)


suppose that is the one,  not sure what you mean  by  sys-firewall being
"it"

so something like
sudo qubes-dom0-update qubes-template-whonix-gw-14
--enablerepo=qubes*testing --clean ??

after deleting the 4 template rpms in /rpm  ?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b32a9e8-4b82-88ba-48ad-56dec611c6a3%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ALL VMs are not working -- qmemman

2019-01-26 Thread Lorenzo Lamas
I also had this error after installing these packages from Dom0 
Security-Testing repo.
I posted about it in the QSB #46 thread, but havent got a reply there. 
Fortunately, with help of someone else I was able to fix it:
https://groups.google.com/d/msg/qubes-users/5D8AxG3jtdw/CqyWjGEiGgAJ

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2ed1d57e-5e02-4fa3-ae06-fc5669dee13a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How to connect any qube to Updates Proxy

2019-01-26 Thread 19hundreds

I'm not sure I nailed this one but I've found a way to connect standaloneVM to 
the Updates Proxy in R4.0. 

It looks to me that this not documented anywhere so I thought to share the 
solution.
https://www.reddit.com/r/Qubes/comments/agyune/how_to_use_update_proxy_on_standalonevm/
 


If you see any improvement or anything stupid in what I did, please let me know

-- 
1900
https://www.reddit.com/user/19hundreds 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/LX9tNlq--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread Alexandre Belgrand
Le samedi 26 janvier 2019 à 04:39 -0800, goldsm...@riseup.net a écrit :
> If "apt-transport-https" is the magic bullet, why in the past hasn't
> it
> been implemented by default? And, why for the future, is it not being
> implemented immediately by Qubes, Debian et al?

Furtermore, very few Debian repos support https.
Here is the stanza to use https in Debian (adapt it for other flavors):

deb https://deb.debian.org/debian/ unstable main contrib non-free
deb-src https://deb.debian.org/debian/ unstable main contrib non-free

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4e0a5edcde58d2ce674a85bd67201f57f4dfc401.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: looking for quickest way to copy text from dom0-Terminal to another VM

2019-01-26 Thread gone
Stuart Perkins wrote on Sat, 26 January 2019 13:32
> On Sat, 26 Jan 2019 01:01:44 +0100
> Since dom0 exists to do the sole job of managing the
> other VM's, one must question why the text you wish to
> insert into another domain is "in" dom0 to begin with.
> --

That's completely right and also the reason why I would not
want to create my questions about qubesOS to this board
somehow in dom0. But when I have a question about dom0 I
often have to quote several lines of text from a dom0
terminal and get those to an www- or mailagent in an appVM.
In order to avoid frustration, I think this should not be
too laborious to handle.  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9b2.5c4c7292%40qubes-os.info.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ALL VMs are not working -- qmemman

2019-01-26 Thread Nick Darren
On Saturday, January 26, 2019 at 9:49:54 PM UTC+8, Aly Abdellatif wrote:
> When I rebooted Qubes OS after installing i3. All VMs are not working(xfce or 
> i3) with the error
> 
> 
>  :Domain t has failed to start :Failed to connect to qmemman:[Errno 2] No 
> such file or directory
> 
> 

> with journalctl -xe ; I have this error : Failed to start Qubes memory 
> management daemon 
> 
> 
> systemctl start qubes-qmemman.service is not working with the error : 
> 
> Job for qubes-qmemman.service failed because the control process exited with 
> error code
> 
> Same with systemctl restart qubes-qmemman.service
> 
> And with ystemctl status qubes-qmemman.service : I have the same error with 
> the on in journalctl -xe
> 
> 
>  Failed to start Qubes memory management daemon
> 
> 
> 
> PS: I only edited the conf file in i3(everything was working) and I added in 
> /etc/systemd/system/ a file that call i3lock when suspending(this is when I 
> rebooted). I also deleted this file after having the error above but without 
> success.
> 
> Thanks in advance
> Aly Abdellatif

I have the same exact problems after booting qubes.

Before that I was upgrading these packages on dom0 before qubes-qmemman.service 
issue failed to start:

qubes-mgmt-salt-dom0-update-4.0.5-1.fc25.noarch
qubes-desktop-linux-manager-4.0.14-1.fc25.noarch
qubes-manager-4.0.26-1.fc25.noarch

@marek do you have any idea on this?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6ac9ed09-ae41-4484-8e64-6540c7cf546d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] ALL VMs are not working -- qmemman

2019-01-26 Thread Aly Abdellatif
When I rebooted Qubes OS after installing i3. All VMs are not working(xfce or 
i3) with the error


 :Domain t has failed to start :Failed to connect to qmemman:[Errno 2] No 
such file or directory


with journalctl -xe ; I have this error : Failed to start Qubes memory 
management daemon 


systemctl start qubes-qmemman.service is not working with the error : 

Job for qubes-qmemman.service failed because the control process exited with 
error code

Same with systemctl restart qubes-qmemman.service

And with ystemctl status qubes-qmemman.service : I have the same error with the 
on in journalctl -xe


 Failed to start Qubes memory management daemon



PS: I only edited the conf file in i3(everything was working) and I added in 
/etc/systemd/system/ a file that call i3lock when suspending(this is when I 
rebooted). I also deleted this file after having the error above but without 
success.

Thanks in advance
Aly Abdellatif

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/eabdaff0-f1fe-423a-b5c3-905e8e2facdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] looking for quickest way to copy text from dom0-Terminal to another VM

2019-01-26 Thread Stuart Perkins



On Sat, 26 Jan 2019 01:01:44 +0100
haaber  wrote:

>On 1/25/19 9:04 PM, gone wrote:
>> 1st of all, I have read this:
>> https://www.qubes-os.org/doc/copy-from-dom0/
>>
>> Maybe I just draw a mental blank but I can't find a really
>> quick way to copy text (not files) from dom0-Terminal to
>> another VM (into a post like this for instance). I thinking
>> of some easy and logical keyboardcshortcuts like the ones
>> that exist for copying text between domUs.
>> When I've  marked some arbitrary textlines in the dom0
>> terminal and then use "copy" from the right-clic-menu, how
>> can I go on most easily?  
>
>I am annoyed by the same thing, but maybe there is a security
>consideration I do not know. So I copy a text with mouse, cat it in a
>txt file and copy-to-vm it away in my mail-vm for example. Don't know if
>there is faster. Bernhard
>

Since dom0 exists to do the sole job of managing the other VM's, one must 
question why the text you wish to insert into another domain is "in" dom0 to 
begin with.  The less you do with dom0 the better.  Everything you do in dom0 
which is NOT simply managing the other domains is a potential security hole.

Stuart - Qubes 3.2 user on a Ghosted Lenovo T520.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190126073235.3d1aca9d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Debian Template APT Vulnerability - A ticking bomb?

2019-01-26 Thread goldsmith


Am I right in thinking  that the recently discovered apt vulnerability
(DSA 4371-1) in Debian based systems could and should have been
mitigated against many years ago  by downloading and activating an apt
package; "apt-transport-https", which forces apt updates via https? The
researcher (Max Justicz) who discovered the vulnerability has stated it
couldn't have been exploited if https had been implemented.

If "apt-transport-https" is the magic bullet, why in the past hasn't it
been implemented by default? And, why for the future, is it not being
implemented immediately by Qubes, Debian et al?

During the past decade many people with good foresight had predicted the
apt vulnerabilty and urged administrators to install the
solution;"apt-transport-https". Regrettably, the vocal majority of
so-called experts said that's unnecessary because the packages are
signed. Was that incompetent advice? or was it a coordinated response
from agents of State Actors to hide a deliberate backdoor? I've no idea,
but given Snowdens revelations I would not rule anything out.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9e814631ba39955e16a2ff28096b58e7%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Help installing package in template VM via snap

2019-01-26 Thread 799
Hello,

I am trying to update my multimedia howto for Qubes and would like to use
a  fedora-29--minimal template instead of debian.

I try to install a package via snap but the template VM is not allowed to
access the repository:

snap install , results in:
api.snapcraft.io ... read: connection refused.

Question:
What are the correct steps to allow internet access for the template VM?
If possible only to api.snapcraft.io?

I looked at the Qubes docs https://www.qubes-os.org/doc/software-update-vm/
but couldn't find a solution, can someone point me into the right direction?

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2uYQuuT3B5AevFEzPA82kvd5TY5EL7S9q_-ZOo_51B1Og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 4.0.x - Linux kernel 4.19.15 package available in testing repository

2019-01-26 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/24/19 5:18 PM, Patrik Hagara wrote:
> I get weird graphical artifacts with the new kernel after ~an hour
> of usage. Windows from AppVMs turn all white sometimes when
> switching workspaces in i3wm. Events like mousing over an
> interactive table rows in a browser (when the current row gets
> highlighted) return that particular section of the window back to
> normal (but not the whole window, for that I need to trigger a
> repaint of the whole window by eg. making it full-screen and
> immediately switching back to non-full-screen).
> 
> Haven't had to time to debug this issue yet, will look closer over
> the next weekend or two. For now I've reverted to using the old
> kernel from stable repo and the issue went away.
> 

I am also getting graphical artifacts with KDE. Although I think that
I also had some in the past now they appear very soon. Sometimes I
have to close and reopen a window because it stops redrawing except I
move or resize it.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlxMRz8ACgkQFBMQ2OPt
CKWgIA/+ISduFIH5euTsqOzUGnoaxC0xK4PG/tdkMoIHEnIwOt6Zd0hTkNhDSXwv
YelHOiL3WVlNvVxG4ZAahJsDrUdA7MR98nHd4rDlc53htmH+7ZhD6rVEJMRzEbIU
zbT0Ipwv0I5lsd/cXKY0bZq4Dp8scdpm4qF9hVBRayDynU4w6KrqbMzvhSMbV84d
Wz/34eGUAO0EHaYC8RFAqF84bpsdEALnJFQppIaPuj1wmFyiB4vURvNor5hYxmwi
OYKiQrRr+QVN/eUJghXmbnruV9X1YtbZmTHD7+hQkWWRZ02nIsnQHJoHhGyDhGJd
BNhnbpjAmZWMKe9UUiuVllWHgPre4s4e9T5EQBvf3dSmuVWKNASJkNDOe3sLLbKh
zchsS+opGsKIo/wIojJQ0JsyRbwxgBlMmYbeiNHDyQVKb5/O1T4/8Q3iYO0sMD9D
XuJUtD9Ip4/xH/H9QSL9kyiYEuoK2Pl8GWyeoCK6171IPJlwgvm7oxbIqYS5ckH2
/0NDnFJfhOG0PylCsIbLYBsPeYJ+yy8m7D22v8WkNSPfGtlqSwTUS7U8cOe8pX1r
xZrs7rqJ/c+8wmy6ZIRZk8lYLMGXSf1LyCpJQJC9mDHDp1CoP/WV3HVDXBuovYye
wWZdoxvh2jtdAkZOFAC9iw0EiUeDc9O3uccW/z+N8h+utC4XYx0=
=f+V0
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5992b29e-2f25-d4ae-1b22-2289464fad46%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Lenovo G505s A10-5750m / qubes 4.0rc5 / Unsupported Hardware Detected

2019-01-26 Thread qma ster
> I think to order this material for a future flash coreboot on G505s. can you 
> confirm that the material is OK?

Sorry for late reply, these links are almost ok but it's better to get CH341A 
with a green PCB because there were a few bad black CH341A with 5V instead of 
3.3V while we haven't heard of such cases for green CH341A

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1678ebc3-77ef--9076-e22ad5606898%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Materials for BIOS flash procedure

2019-01-26 Thread qma ster
Sorry for such a late reply, hope you already know about "Flashing a BIOS chip" 
article at DangerousPrototypes forums which uses G505S as an example. And 
another "Flashing KB9012" article is optional and not urgent (since it's not 
replacing the proprietary KB9012 firmware, just removing the serial numbers 
from it) so maybe you could wait for this 30-pin cable. I would have happily 
shared one of my spare cables but I'm concerned about privacy (postal address 
etc) and the international shipping could cost for me more than simply ordering 
10pcs to your address. But your message is pretty old so I hope you got it 
resolved.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/34de72fc-b48e-4581-b41e-40be49c75029%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How many gigabytes of memory is required for G505s?

2019-01-26 Thread qma ster
> and yes it is the best - remember to install coreboot with microcode
> updates btw (check binary only repo + generate microcode from tree)

"Generate microcode from tree" option does not work for G505S. Luckily these 
confusing options have been hidden at the latest coreboot from the boards which 
do not support this method. And I am using a script at "G505S hacking" 
dangerous prototypes page to patch the coreboot sources with the latest 
microcode

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b2bddbaa-9827-4064-887f-61fed2e4548b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] g505s BIOS settings for installing 4.0.1

2019-01-26 Thread qma ster
Proprietary UEFI on this G505S laptop is a real piece of sheet and I really 
encourage you to "upgrade" it to coreboot opensource BIOS as soon as possible! 
There is a great "Flashing a BIOS chip" detailed step-by-step article at 
DangerousPrototypes site which uses this G505S laptop as an example, and if 
you'd have any questions regarding the coreboot build/configuration - we will 
be happy to help you. Although I could just send you my own coreboot build, it 
is discouraged because to become a productive member of our small community 
you'd have to be able to build coreboot on your own. So please try following 
this way, and if you'd have any questions we will happily answer

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/acd2a912-d13c-49d5-91b1-2a2f753cfedf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] QSB #46: APT update mechanism vulnerability

2019-01-26 Thread Alexandre Belgrand
Le mercredi 23 janvier 2019 à 18:05 +0100, Marek Marczykowski-Górecki a
écrit :
> We have just published Qubes Security Bulletin (QSB) #46:
> APT update mechanism vulnerability.

Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
and injection may occur during apt-get install/update using man-in-the-
middle attack, at least in some countries. Unless packages are compiled
with reproducible builds and fingerprints are available online, there
is no way to avoid such an attack.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16d91083bd8dbf847a75b8548de0c1b8ac5a58bc.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HCL - 20HRCTO1WW Lenovo Thinkpad X1 Carbon

2019-01-26 Thread berne . campbell
On Friday, 25 January 2019 20:38:03 UTC+11, Jean-Philippe Ouellet  wrote:
> On Wed, Jan 23, 2019 at 11:45 PM Berne Campbell
>  wrote:
> >
> > Lenovo Thinkpad X1 Carbon 20HRCTO1WW
> >
> > I had to disable secure-boot to boot of USB stick for installation (Used 
> > Rufus in Windows in DD mode, MBR partition scheme). Perhaps a signed shim 
> > could be used to ease installation.
> >
> > Builtin LCD display is working
> > Internal Keyboard is working
> > TrackPoint (including scrolling) is working
> > TrackPad is working
> > Wireless networking is working
> > Battery/AC power monitoring is working
> > Bluetooth doesn't due to Qubes OS Security stance on BT
> > Bluetooth mouse connected via USB cable is not working - not sure if it has 
> > a wired-mode or if its just for charging.
> > Hot Keys: -
> >   - Volume Up, Down, Mute working
> >   - Microphone Mute not working
> >   - LCD Brightness Up/Down is working
> >   - Display (external/mirror/etc) is working (brings up display dialog)
> >   - Wireless/RF kill button is not working
> >   - Settings button not working
> >   - Bluetooth button removes/adds USB device (8087_0a2b)
> >   - Keyboard button (F11) does nothing
> >   - Star button (F12) does nothing
> > Keyboard backlight works (Fn+Space)
> > USB Mass Storage works
> > Internal mass storage NVME works
> >
> > So far, looking good. Thanks for the hardwork ITL and the Qubes OS team.
> >
> > I'm happy to share further details.
> >
> > Cheers,
> > Berne
> 
> Does it have stable suspend/resume? Roughly how many cycles have you
> put it through?

Yes, I can shut the lid, put my laptop in my backpack and resume later. So far 
I've done maybe a dozen, so not a lot but so far so good.

Also external monitor works (HDMI).

Cheers,
Berne

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fd11b9a2-15a6-4ec2-834a-2ef66dae29f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: QSB #46: APT update mechanism vulnerability

2019-01-26 Thread Aly Abdellatif
@John S redcap

Go into the updateVM and delete unneeded rpms :
/var/lib/qubes/dom0-updates/packages

If you didnt change your updateVM, it will be in sys-firewall

And then add  - - clean in your qubes-dom0-update 
Command

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ec709af9-a8a0-41fd-902f-cdad95a1ad9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: looking for quickest way to copy text from dom0-Terminal to another VM

2019-01-26 Thread 799
Am Sa., 26. Jan. 2019, 04:33 hat Andrew David Wong 
geschrieben:

>
> Please take a look at this issue:
>
> https://github.com/QubesOS/qubes-issues/issues/3571



Happy to see that this topic (no clipboard from dom0) is at least known.
I don't agree that copying from dom0 is dangerous because "The user could
have secrets in dom0, e.g., keyfiles".


My passwords are in a vault VM and if someone messes up handling from dom0
it is very likely that he/she didn't understand the security concept behind
Qubes and therefore the user is likely the biggest attack surface NOT the
clipboard.

Please offer a solution where the user can choose (free software!!) to
enable/disable the clipboard (choosing means freedom).

It seems there is a workaround, can this be bound to a key (maybe also
using xclip in dom0)?
echo -n dom0 > qubes-clipboard.bin.source .

- O

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ3yz2t-o6x7bHazw6kY7uSXd2s7Z3Gn4BTsTih_pKrvPY-Vfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.