[qubes-users] Re: Broadcom wireless driver issue.

[qubesbcmissue]

Extra info : I have already tried running a Fedora 29 TemplateVM then setting 
the default kernel as none in order to make it run the fc29.x86_64 kernel. I 
did the same with my sys-net VM and set its TemplateVM as the modified one. 
Unfortunately it did not work. While I got the kernels running on both machines 
and had already built the modules in the TemplateVM, first no device shows up 
when clicking the Network tray icon and if I run an $ lspci to the sys-net 
terminal the system just freezes conpletely. I have set the adapter to 
permissive mode and with the no-strict-reset option marked as true.

-- 
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/7bf5c5bc-76b7-4ec1-9eb6-cf2ac5816174%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Broadcom wireless driver issue.

[qubesbcmissue]

o I’m trying to get wireless networking properly configured.
First I decided to do this by installing Fedora 29 as a main OS, since I 
supposed that if I get it working there, it should work in a Qubes Fedora 
29-based VM, right? Well not so fast.
I got my BCM4331 working in the pure Fedora 29 OS by first enabling the RPM 
Free & Nonfree repos and then
# dnf install akmods "kernel-devel-uname-r == $(uname -r)" # dnf install 
broadcom-wl # dnf akmods then # reboot and boom, I have WiFi.
Now in the Qubes OS Fedora 29 Template VM, since this is the place we’re 
supposed to install drivers, I entered the first command and I got a No match 
argument error. So I decided to just modify this to install the package for the 
non-qubes kernel, i.e. # dnf install akmods kernel-devel-4.19.8-300.fc29.x86_64 
. Installed successfully. Same with # dnf broadcom-wl
But if I run # akmods or # akmods force I get an error that says it has failed 
to build the wl-kmod for the 4.14.18-1.pvops.qubes.x86_64 kernel. I decide to 
change the command again to run for the other kernel and everything goes well :
# akmods --kernels 4.19.8-300.fc29.x86_64 Checking kmods exist for 
4.19.8-300.fc29.x86_64 [ OK ]
But if I run the NetVM where the adapter is attached, it is listed in the $ 
lspci command but not in $ ip a or $ iwconfig. So if I get that right, the 
driver has been successfully configured for the 4.19.8-300.fc29.x86_64 kernel 
however it’s kind of pointless since the VM uses the 
4.14.18-1.pvops.qubes.x86_64 kernel.
What am I supposed to do here? Try and find a way to have 
4.19.8-300.fc29.x86_64 as TemplateVM's main kernel or install the drivers in 
4.14.18-1.pvops.qubes.x86_64 one?

Someone on the /r/sub suggested I enable the latest ,unstable, kernels packages 
through dom0 along with some extra modules.  I did that but I’m not sure what 
do I do next. Do I just run # dnf install whatever package I want installed? 
Everything seems to be properly installed (broadcom-wl, akmod-wl, kmod-wl) but 
# akmods still fails:
Building and installing wl-kmod [ FAILED] Building rpms failed; see 
/var/cache/akmods/wl/6.30.223.271-20-for-4.19.12-3.pvops.qubes.x86_64.failed.log
 for details


Here is the log https://pastebin.com/P17PmzDP

-- 
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/4b2d0174-95dc-49a2-ab21-e8527fbd74e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0.1 Dell Inspiron 7380

[mrf...@t-online.de]

Hello again,

does any one have a clue or a hint for me please?

Further I would like to know do you think this fits for issue tracker?

1:07:55,633 WARNING kernel:[0.00] ACPI BIOS Warning (bug): Incorrect 
checksum in table [FACP] - 0x8B, should be 0xBF (20170728/tbprint-211)
21:07:55,636 INFO kernel:[0.546000] PCI: Using host bridge windows from ACPI; if 
necessary, use "pci=nocrs" and report a bug

Thank you in advance for effort!! & looking forward to hopefully hearing from 
you :)

Kind Regards,
Fabian

 


On 1/13/19 2:11 AM, mrf...@t-online.de wrote:

Hello all,

first in advance: -> THANK YOU for taking time & excuse my bad English!

I really wanted to get this issue fixed by my own trough searching qubes 
website, forums, newsgroups and so on...
Unfortunately "the graphical installation interface /*still*/ fails to start" :(

Current uefi settings:
- latest firmware
- any legacy on
- disabled stuff like camera, bluetooth, and so on (for testing some various 
more like audio)

My last tries were on 4.0.1 rc2 (with Troubleshooting) and some previous Qubes 
versions with different custom kernel parameters.
I also tried an usb2ethernet adapter for vnc install option without success.
The next boarder: try using inst.text option and prepare an empty disc with 
cryptsetup because:
"encryption requested for LUKS device nvme0n1p2 but no encryption key specified for 
this drive." (lsblk & fdisk lists nvme0n1 only)
 -> do I have to create that device & encryption key how ever?
 -> does inst.text option needs a kickstart because there is no prompt 
available for passphrase input during setup?
 -> will Qubes show an other behavior after the installation regarding 
graphic issues?

After spend a few hours on it I would be very very happy for any hints and 
support!!!
If I had to guess I would say it depends on event in file X.log row contains 
34.992 + 35.068 V_BIOS address * out of range
But I have no clue to come along or deal with it...
Therefore I collect log files which hopefully will help to clarify and 
eliminate that nightmare.

I kindly ask you please help me get this solved and run Qubes - appreciate it ;)

Kind Regards,
Fabian
--
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/00be5ff8-0ee6-f934-9216-c6649d9bfecc%40t-online.de 
.

For more options, visit https://groups.google.com/d/optout.


--
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/af6b547b-1c63-c6f7-f825-d74c8e072403%40t-online.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Window7 VM install - No device drivers found

[imamushroom]

On Sunday, 27 January 2019 20:38:51 UTC+1, imamushroom  wrote:
> Hello,
> 
> I'm following the instructions here: https://www.qubes-os.org/doc/windows-vm/ 
> and everything went well up to a point. Windows setup boots but when it gets 
> to the partitioning and formatting section the message in Windows "No device 
> drivers found" message appears.
> 
> Clearly, it's not recognising the drive within the VM.
> 
> How do I get around this?
> 
> I'm using the Win7_Pro_SP1_English_COEM_x64.iso, i.e. OEM version as I have a 
> license for this.
> 
> Thanks,
> imamushroom

I'm using Qubes 4.01 with an encrypted disk - sorry forgot to mention that!

-- 
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/d4c330ff-4d1e-454f-b014-b2e14bb35e6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Window7 VM install - No device drivers found

[imamushroom]

Hello,

I'm following the instructions here: https://www.qubes-os.org/doc/windows-vm/ 
and everything went well up to a point. Windows setup boots but when it gets to 
the partitioning and formatting section the message in Windows "No device 
drivers found" message appears.

Clearly, it's not recognising the drive within the VM.

How do I get around this?

I'm using the Win7_Pro_SP1_English_COEM_x64.iso, i.e. OEM version as I have a 
license for this.

Thanks,
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/848df38f-f487-416a-bb9e-bbc053f6209c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[billollib]

On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:
>[snip]
> Qubes provides a framework for using software - it doesn't take away the
> onus on users to use that software properly, and to ensure they are aware
> of good practice.  (As an aside I'm always baffled by people querying
> how they can use Facebook under Tor or Whonix. What are they thinking?)
> I regularly audit templates with tripwire, running from an
> offline openBSD qube, and do standards checks with debsums. I do good
> deal of my work offline in openBSD and then transfer encrypted in to
> other qubes for transmission. That seems like overkill, and isn't for
> everyone: it might be for you.
> 
> unman

I think this is the most important thing you wrote. I used to do network 
security for a small scientific government network back in the 1990s, and I 
constantly ran into the problem that there is an inverse relationship between 
security and usability.  The scientists on my network were constantly finding 
ways of going around whatever security measures I put in place precisely 
because they didn't want to deal with the "hassle."   

But I'm no different, really.  Not too many years ago, I routinely disabled 
SELinux when I installed a new OS simply because I considered it too much of a 
hassle to learn how to use it effectively.  It made it difficult for me to do 
stuff.  Everybody yelled at me, but it just wasn't worth the effort to me. Now, 
I've learned it a bit and it's not such a hassle.

There's this balance between the inconvenience/damage associated with an 
intrusion versus the inconvenience associated with the security configuration.  
For me on the computer I'm using as I write this, it wouldn't be the end of the 
world if *everything* on my computer were owned by someone else.  It would be a 
hassle, but not fatal -- I have insurance, etc. for the financial information I 
have here, and I don't really care if someone sees the email conversations I 
have on this machine.

So, considering the financial stuff, for instance.  There's a hassle with 
someone getting my credit card information.  It's happened (though not because 
of a computer glitch).  My card gets frozen, I can't use it for a week or two, 
I have to make a bunch of phone calls, etc.  But I'm financially protected and 
eventually I'll be fine.  The problem is the hassle factor, not financial ruin. 
My biggest security concern is someone using up all my bandwidth; I live in a 
rural area and have metered service.  Someone using up 5 gigs of bandwith is 
more concerning to me than them owning 5 gigs of data from my machine. So, I 
have to ask myself, which is more hassle -- dealing with the intrusion, or 
dealing with the security hassle?

It's my responsibility to determine where that balance is, and nobody else's.  
And it's likely different for everybody.  For instance, I used to have a blog, 
but I'm a litigation consultant and I started seeing my blog posts turning up 
in court.  So I don't blog any more. I can't be on Facebook, or LinkedIn, or 
Doximity, or ResearchGate.  That's not a problem for me, but it would drive my 
wife crazy.  I use one laptop for some stuff, and I use a different laptop, 
differently configured, for other stuff.

And, the higher up the food chain you go with respect to people interested in 
surveilling you, the less chance you have of keeping them out.  I'm out of the 
business now, but back in the day I occasionally did some classified work. I 
remember some years ago, I called a friend of mine who worked for the 
government.  I called him using the work phone of an acquaintance to ask him a 
technical question.  He picked up the phone and immediately said "Hey, Bill, 
how you doing?"

I was stunned. I asked him how the hell he knew it was me.  He said "Bill, I'm 
with the .  We always know where you are."

I have another friend who spent his early career working for a government 
contractor.  His job was to break into people's houses at night and install 
keyloggers on their computers. With a subpoena, of course.  All the security 
software in the world won't help you with that.

The key, for me, is to achieve the maximum security that I can achieve and stay 
below my maximum hassle tolerance.  Qubes is nice because it adds a big uptick 
in transparent security with only a small uptick in hassle -- at least for 
someone who is fairly conversant with sysadmin stuff.  So for me it's a big 
win. But it's not all there is.

There's no such thing as perfect security.  There's only finding the balance 
between one's perceived risk, one's actual vulnerability, and one's tolerance 
for hassle.  And any security configuration is self-defeating if:

1) People take it for granted and think that it's all they have to think about, 
and/or
2) It's enough of a hassle that you start going around it to do your work.


billo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe fr

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

[unman]

On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote:
> On 2019-01-27 01:34, 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.
> 
> Apologies. I've reposted this because the subscripts weren't clear in
> the earlier post. Hopefully this will be clearer.
> Thank you for your responses.
> I appear to have prodded a hornets nest! I make no apology for that.
> It’s good and allows everyone an opportunity to express their views.
> Hopefully backed up by facts.
> Here's some background as to where I'm coming from:
> 1/ I use Debian based templates; including Whonix, exclusively (I do
> have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat,
> monetised etc). So, all my apps (including service apps like
> sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited.
> At this point for me its game over. I'm completely stuffed. Now when
> Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the
> vulnerability was publicly announced, saying its comparable to a firefox
> exploit: I get angry and say what complete and utter PR horsesh*t. 
> 
> 2/ Nobody's going to blame Qubes for an vulnerability like this in
> Debian etc. However, the least I'd expect from Qubes is a timely
> warning. Personally, I got a warning from Whonix a good 12 hrs before
> Qubes alerted us!
> 
> 3/ Most people have made an assumption that the good guys i.e. Max
> Justicz found the vulnerability first. Personally I never assume
> anything and prefer to think "worst case scenario". In this case I have
> had no privacy or security whatsoever for possibly years. Whilst Dom0's
> been protected, I'm not - what use is that?
> 
> Now turning to Unman's comments:
> 1/
>  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.
> With respect Unman, you seem to have missed the section where Max
> explicitly says "Supporting http is fine. I just think it’s worth making
> https repositories the default  the safer default  and allowing users to
> downgrade their security at a later time if they choose to do so".
> 
> Furthermore, The Guardian Project have been promoting the use of https

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

[Alexandre Belgrand]

Le dimanche 27 janvier 2019 à 16:47 +, unman a écrit :
> I'd be interested to know what system has been graced with your
> approval.
> If you believe all this, then what makes you think that national
> intelligence agencies haven't infiltrated *bsd, coreboot and any
> other
> system you can name. 
> imo Qubes does a reasonable job of providing a more secure system
> that's usable by ordinary users.

Simply no x86 system is reasonably secure.

> Spreading unfounded allegations is a disservice to the community.

Qubes is interesting because it is trying to answer security needs and
the design is nice. 

But think about Intel ME backdoor. Imagine that any officer with a
signed certificate of Intel can penetrate dom0 in your computer within
seconds and then view your screen, move your mouse and type on your
keyboard. This is reality and Qubes cannot change it.

-- 
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/65d4efc1f6cc5203a5fc0802e2cdff2e9fc992f7.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.

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

[unman]

On Sun, Jan 27, 2019 at 03:33:11PM +0100, Alexandre Belgrand wrote:
> Le dimanche 27 janvier 2019 à 13:11 +, Holger Levsen a écrit :
> > I *believe* they probably misunderstood evil32.com and it's fallout.
> 
> CAs and GNU/Linux distributions are #1 targets for national
> intelligence agencies.
> 
> Debian developers are not using smartcards to store their GPG keys,
> including the master key signing code. It is very likely that Debian
> master key has been stolen. I would be very surprised if it had not
> been stolen.
> 
> One reason why nobody wants to use SSL, including OpenBSD, is that
> there is a wide belief that SSL private keys have been stolen.
> Therefore there is no need to use SSL, as it does not offer a real
> protection.
> 
> This is simply GAME OVER (part 1 of the game).
> 
> One reason why I am not using Qubes, is that it does not offer a real
> protection compared to Debian, as both systems are IMHO compromised.
> 
> At present, any government with a valid certificate from Intel can use
> Intel ME backdoor to access all resources from a computer, including
> keyboard and screen and there is no way to secure an X86 computer.
> 
> If Qubes was making a wide use of Smartcards with a separate pinpad
> reader and was using a hardened operating system like OpenBSD or even a
> hardened GNU/Linux, I would have a closer look at it.
> 

I'd be interested to know what system has been graced with your
approval.
If you believe all this, then what makes you think that national
intelligence agencies haven't infiltrated *bsd, coreboot and any other
system you can name. 
imo Qubes does a reasonable job of providing a more secure system
that's usable by ordinary users.
Spreading unfounded allegations is a disservice to the community.

-- 
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/20190127164722.becnlytbz5bidzhz%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qube Window Manager; unable to list all open windows

[Chris Laprise]

On 01/27/2019 09:32 AM, Franz wrote:

Command `wmctrl -l` gives the following error

|Cannot get client list properties. (_NET_CLIENT_LIST or _WIN_CLIENT_LIST)|


This works for me with KDE.




But when I use |wmctrl| to display info about the window manager, Qubes 
is indeed found:

[user@personal ~]$ wmctrl -m
Name: Qubes
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

What I am trying to do is to gracefully close firefox, but I get the 
same error:


[user@personal ~]$ wmctrl -c firefox
Cannot get client list properties.
(_NET_CLIENT_LIST or _WIN_CLIENT_LIST)


You could try using 'xdotool' instead:
xdotool search --name Firefox

See my 'halt-vm-by-window' script from 'Qubes-scripts' project for 
examples. You could go through the list of matching windows, find the VM 
name with 'xprop', then issue a command like "qvm-run $vmname 'pkill 
firefox'" which should send a normal TERM signal to Firefox. Its best to 
wait about 5 seconds before trying to shut down the VM so the browser 
state has time to be written to disk.


--

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/d0ba286e-c567-43b3-785b-bc3ca1bc4246%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

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

[Alexandre Belgrand]

Le dimanche 27 janvier 2019 à 13:11 +, Holger Levsen a écrit :
> I *believe* they probably misunderstood evil32.com and it's fallout.

CAs and GNU/Linux distributions are #1 targets for national
intelligence agencies.

Debian developers are not using smartcards to store their GPG keys,
including the master key signing code. It is very likely that Debian
master key has been stolen. I would be very surprised if it had not
been stolen.

One reason why nobody wants to use SSL, including OpenBSD, is that
there is a wide belief that SSL private keys have been stolen.
Therefore there is no need to use SSL, as it does not offer a real
protection.

This is simply GAME OVER (part 1 of the game).

One reason why I am not using Qubes, is that it does not offer a real
protection compared to Debian, as both systems are IMHO compromised.

At present, any government with a valid certificate from Intel can use
Intel ME backdoor to access all resources from a computer, including
keyboard and screen and there is no way to secure an X86 computer.

If Qubes was making a wide use of Smartcards with a separate pinpad
reader and was using a hardened operating system like OpenBSD or even a
hardened GNU/Linux, I would have a closer look at it.


-- 
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/1d33856a9f5065d64564649bd56b6a0b6d746d7c.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qube Window Manager; unable to list all open windows

[Franz]

Command `wmctrl -l` gives the following error

Cannot get client list properties.
(_NET_CLIENT_LIST or _WIN_CLIENT_LIST)

But when I use wmctrl to display info about the window manager, Qubes is
indeed found:
[user@personal ~]$ wmctrl -m
Name: Qubes
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

What I am trying to do is to gracefully close firefox, but I get the same
error:

[user@personal ~]$ wmctrl -c firefox
Cannot get client list properties.
(_NET_CLIENT_LIST or _WIN_CLIENT_LIST)

Best

-- 
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/CAPzH-qDeMHmEpneeCQ2bsz3%3D1arL1voXR3_VFyz5CDqKjh5MrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[unman]

On Sun, Jan 27, 2019 at 01:11:37PM +, Holger Levsen wrote:
> On Sun, Jan 27, 2019 at 12:54:26AM +, unman wrote:
> > > Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
> > Do you have *any* evidence for this claim?
> 
> I *believe* they probably misunderstood evil32.com and it's fallout.
> 
> 
> -- 
> tschüß,
>   Holger
> 
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> 

Do you think so? That doesn't seem what they are claiming. 
Alexandre , what was it you meant?

The problem is that I *already* see this sort of claim spreading - see
another posting by John Redcap - and eventually there'll be a group of
users convinced that all signing keys have been stolen.
It's very difficult to stop a canard like this.
Unless, of course, Alexandre has some evidence?

-- 
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/20190127140934.rmrnn3azaqsffy7w%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

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

[Holger Levsen]

On Sun, Jan 27, 2019 at 12:54:26AM +, unman wrote:
> > Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
> Do you have *any* evidence for this claim?

I *believe* they probably misunderstood evil32.com and it's fallout.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

-- 
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/20190127131137.owl7xgjibz5m4sxv%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Holger Levsen]

On Sun, Jan 27, 2019 at 02:37:16AM -0800, goldsm...@riseup.net wrote:
> > 2/ 
> > Imagine that apt-transport-https *had* been adopted - have you actually
> > looked at the list of vulnerabilities in libcurlnd the various
> > breakages in the TLS CA system?

that. plus, apt is running as root and apt-transport-https needs to
parse untrusted input...

> You appear to be saying that Debian have created a package;
> apt-transport-https which is not fit for purpose? Have you notifified
> them of this? and if so what was their response?

one of the reasons Debian has not made apt-transport-https is that there
is a trade-off between gaining some security properties by using https
and loosing some (see above in this very mail)...

what really would need to be done would be to rewrite/patch apt, to do all the
certificate verification as less priviledged user. I *believe* modern apt
suports this (at least I have an _apt user in my /etc/passwd on stretch
systems, but not on jessie), but I'm not sure (read: i have no idea)
whether apt-transport-https uses that too.


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

-- 
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/20190127125649.khw72kcuj4yrw7al%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

[Achim Patzner]

On 20190127 at 01:34 + unman wrote:
> I would rule some things out. And in this case it looks like a simple
> mistake.

It could even be intention. Most of you do not think about the cost
associated with TLS (and growing with key lengths). But there always
were (and will be) discussions whether offering a certain service
(especially free of charge) will be worth it considering the attached
cost. We're lucky that technology stepped up a bit (I remember doing
performance analysis when SSL was pushed into the market by Netscape
and found out that it cost about an eightfold increase in CPU
resources); you might want to read 
https://blog.cloudflare.com/how-expensive-is-crypto-anyway/ to get a
more recent look at things. But with Quantum computers just around the
corner there will be a new arms race current CPUs are not prepared for.
And keep in mind that only protecting "important targets" is stupid; if
you do not encrypt everything you are attaching target markers to your
secrets.

Crypto is added cost and designers will always try to find a balance
between cost and security...


Achim


-- 
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/6e557736131daa986892765e94eac2a6d25b9dec.camel%40noses.com.
For more options, visit https://groups.google.com/d/optout.

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

[goldsmith]

On 2019-01-27 01:34, 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.

Apologies. I've reposted this because the subscripts weren't clear in
the earlier post. Hopefully this will be clearer.
Thank you for your responses.
I appear to have prodded a hornets nest! I make no apology for that.
It’s good and allows everyone an opportunity to express their views.
Hopefully backed up by facts.
Here's some background as to where I'm coming from:
1/ I use Debian based templates; including Whonix, exclusively (I do
have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat,
monetised etc). So, all my apps (including service apps like
sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited.
At this point for me its game over. I'm completely stuffed. Now when
Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the
vulnerability was publicly announced, saying its comparable to a firefox
exploit: I get angry and say what complete and utter PR horsesh*t. 

2/ Nobody's going to blame Qubes for an vulnerability like this in
Debian etc. However, the least I'd expect from Qubes is a timely
warning. Personally, I got a warning from Whonix a good 12 hrs before
Qubes alerted us!

3/ Most people have made an assumption that the good guys i.e. Max
Justicz found the vulnerability first. Personally I never assume
anything and prefer to think "worst case scenario". In this case I have
had no privacy or security whatsoever for possibly years. Whilst Dom0's
been protected, I'm not - what use is that?

Now turning to Unman's comments:
1/
 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.
With respect Unman, you seem to have missed the section where Max
explicitly says "Supporting http is fine. I just think it’s worth making
https repositories the default  the safer default  and allowing users to
downgrade their security at a later time if they choose to do so".

Furthermore, The Guardian Project have been promoting the use of https
for apt package retrieval for many years. Here's their latest statement;
"There is a new vulnerability in Debian’s apt that allows anything that
can Man-in-the-Middle (MITM) your traffic to get root on your
Debian/Ubuntu/etc boxes. Using encrypted

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

[goldsmith]

On 2019-01-27 01:34, 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.
Thank you for your responses.
I appear to have prodded a hornets nest! I make no apology for that.
It’s good and allows everyone an opportunity to express their views.
Hopefully backed up by facts.
Here's some background as to where I'm coming from:
1/ I use Debian based templates; including Whonix, exclusively (I do
have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat,
monetised etc). So, all my apps (including service apps like
sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited.
At this point for me its game over. I'm completely stuffed. Now when
Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the
vulnerability was publicly announced, saying its comparable to a firefox
exploit: I get angry and say what complete and utter PR horsesh*t. 

2/ Nobody's going to blame Qubes for an vulnerability like this in
Debian etc. However, the least I'd expect from Qubes is a timely
warning. Personally, I got a warning from Whonix a good 12 hrs before
Qubes alerted us!

3/ Most people have made an assumption that the good guys i.e. Max
Justicz found the vulnerability first. Personally I never assume
anything and prefer to think "worst case scenario". In this case I have
had no privacy or security whatsoever for possibly years. Whilst Dom0's
been protected, I'm not - what use is that?

Now turning to Unman's comments:
1/ 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.
With respect Unman, you seem to have missed the section where Max
explicitly says "Supporting http is fine. I just think it’s worth making
https repositories the default  the safer default  and allowing users to
downgrade their security at a later time if they choose to do so".

Furthermore, The Guardian Project have been promoting the use of https
for apt package retrieval for many years. Here's their latest statement;
"There is a new vulnerability in Debian’s apt that allows anything that
can Man-in-the-Middle (MITM) your traffic to get root on your
Debian/Ubuntu/etc boxes. Using encrypted connections for downloading
updates, like HTTPS or Tor Onion Services, reduces this vulnerability to
requiring root on th