Re: [qubes-users] Intel ME and AEM/HEADS

2019-01-29 Thread Chris Laprise

On 1/29/19 8:59 PM, Frank Beuth wrote:
Can someone explain the interaction between Anti Evil Maid/HEADS and the 
Intel Management Engine to me?


I read an article which stated that disabling Intel ME also prevents 
installing AEM (and related technologies), but I am not sure why (or if 
this is really true). Is ME needed to access the TPM?


Someone correct me if I'm wrong... IIRC the ME processor is needed to 
operate the TXT feature which verifies code present at boot. TXT 
utilizes a TPM but is separate.


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

Newer systems also have the TPM built into the CPU and I believe these 
integrated TPMs also rely on ME to function.


-

Qubes is essentially based on the premise that you have to trust the CPU 
manufacturer, but hopefully (someday) _only_ the CPU manufacturer. IOW, 
reducing the number of trusted parties as much as possible. However, 
many of us believe there needs to be progress beyond even this goal and 
that fully open source CPUs should be used as the main component in PCs; 
this would have the effect of bolstering trust and accountability.


--

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/3a36c461-eae6-d00e-13d3-4b4f9467f6d2%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Intel ME and AEM/HEADS

2019-01-29 Thread Frank Beuth
Can someone explain the interaction between Anti Evil Maid/HEADS and the Intel 
Management Engine to me?


I read an article which stated that disabling Intel ME also prevents installing 
AEM (and related technologies), but I am not sure why (or if this is really 
true). Is ME needed to access the TPM?


--
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/20190130015916.2c5m35qlnupvherv%40web.local.
For more options, visit https://groups.google.com/d/optout.


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

2019-01-29 Thread unman
On Mon, Jan 28, 2019 at 01:30:29PM -0800, goldsm...@riseup.net wrote:
> On 2019-01-28 19:46, billol...@gmail.com wrote:
> > On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote:
> >> On 2019-01-27 19:15, billol...@gmail.com wrote:
> >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote:

> To Billollib
>  
>  First, Its disappointing you didn't apologise for hijacking my thread.
>  
>  Second, you complain I misrepresented you in my summary. Perhaps you
> forget writing the following: " 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."
> My summary of the above was: "It's the Users of software that subvert
> OS's.". I think that's a fair summary of what you said about Users -
> in this case scientists.
> 
> Finally: Please, no further hijacking of other peoples posts
> 

To state the obvious it's not your thread, and no one need apologise for
commenting, or taking the discussion in a new direction.
I doubt that Billollib "forgot writing" anything. I assume that he felt
that you represented him, and you had missed the point of what he wrote.
Let's try to be civil please.

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


[qubes-users] passhprase or os boot doesn't prompt from gui anymore?

2019-01-29 Thread cooloutac
Just want to make sure this is normal behavior.  I noticed a couple weeks ago 
the passphrase asks me type in from boot prompt and doesn't ask me to type in 
passphrase from gui screen anymore.   Is this normal?

Thanks, 
Rich.

-- 
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/ba6f48f8-4a81-4e66-b0ac-b8f4d2a214e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: 4.0.1 persistent external LVM block device attach

2019-01-29 Thread Eric
Got around to checking and this issue has been open for over
a year: https://github.com/QubesOS/qubes-issues/issues/3437

-- 
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/9f7.5c50cc77%40qubes-os.info.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Script Error

2019-01-29 Thread R A F
Hi People

Currently I use Qubes 4.0 and Standalone VM based on debian template.
When I browse internet very often I get this error message and CPU gets crazy

chrome://global/content/bindings/notification.xml:35

Does anyone have similar issues?

Regards
Raf

-- 
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/d17b55bd-f191-4a92-a4b0-10826974457a%40googlegroups.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-29 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/29/19 11:33 AM, Patrik Hagara wrote:
> 
> Update!
> 
> Managed to get rid of the error (and more importantly, the
> annoying artifacts) by forcing Xorg to use the generic modesetting
> driver instead of i915/i965.
> 
> Pages that have been helpful: *
> https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX * 
> https://ask.fedoraproject.org/en/question/130414/enabling-glamordri3-f
edora-29-gnome-xorg/
>
> 
*
> https://www.reddit.com/r/Fedora/comments/5uo6ta/modesetting_driver_fed
ora_25/
>
> 
*
> https://www.phoronix.com/scan.php?page=news_item=Fedora-Xorg-Intel-
DDX-Switch
>
> 
Great! Very nice :)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlxQdd8ACgkQFBMQ2OPt
CKU3dxAAuf/KxeuXzvscYiAIbehsJ3Z2h+t4DofMtwDCGECetUx0h3LSnrqaLxVL
1hC8q8psqGZfEhnnQ8XymLQMIUbBF0dIl7GGOEm7a/YBrr3e6/sewbPUy4OYZeZf
4dFv/vxTLbOhv/k2RnkW/BefF37O5Y779+uheafbhgAYjXCSQSZYiEYLaiiyzTc+
qEBC8teu0Eg9ljnXEfW+Ukm2UilEaP/uGIqM3Gv8Z5mu6/tsAczHFxwmQKc4jnCV
3bFOFw+ck8mLGIb85IdgErwi8chRMprtJQi20TfxQMokkmob+7qlspCg0LOr7+qi
R7FyuPeADDuoTWrotebtiyt8+KVBK6TASllSa2ipuYWFKHII5VS8JIK3vVgcYyTb
X0KwMz8c4cFHqPHZHu/90njVEr9FHLoVXdyXDXoTg19fS/CNZKrkGOqFwLxIx68T
/LSlvOgB+xBzlEmntG4feJxXOTQIVydzXTU/8o5J/xsOWBGZfNR4ToHDokMLB9cI
j/ij6mUv6/LOO20g1u2BHfUyNEj11QV2rYuDf4/Osqf+vjPhU6g+tN0OjkQtSYIO
REK7Mdpc1icPzG5KE1pXw0reMFbOdNzQY/JgjU/Cx75c2OFBU5jDE9QuRyyeo+4R
kEJEvPbyQdgFXiGQNflb51Ynqq5AWJaMlA/AtszC3lYRAdUWUrA=
=q2fJ
-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/bdfdec5d-7f26-6200-1367-0a90e7c74206%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


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

2019-01-29 Thread qma ster
Broadcom hardware/software is a proprietary piece of crap that doesn't work 
well at the opensource operating systems. It could be easier to just replace 
your Broadcom MiniPCIe card with something from Atheros ath9k family which has 
opensource drivers / opensource firmware and work perfectly almost everywhere. 
Just make sure that either your BIOS doesn't have a wifi whitelist or you know 
how to remove it / where to obtain a hacked BIOS with it removed (e.g. 
bios-mods site). E.g. check AR9462 miniPCIe card: 2.4GHz+5.0GHz 300 Mbps 
802.11n Wifi, costs just 8 dollars at aliexpress with free shipping from china 
--> and problem solved

-- 
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/e3d8eedd-7a2f-479e-aefa-7944be976036%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2019-01-29 Thread Alexandre Belgrand
Le mardi 29 janvier 2019 à 02:24 -0800, goldsm...@riseup.net a écrit :
> To Alexandre
> So you found this stuff on the internet and were gullible enough to
> swallow it, hook line and sinker, without first verifying its
> authenticity. I suppose your allegations against the Debian Team's
> security keys are based on equally unstable foundations.
> 
> The making of serious random and unsolicited allegations with the
> intention of scaremongering, could be described as TROLLING. 

No, but I talked to Debian developers and attended Debian conferences
in the past. The main GPG key of Debian distros is only protected by a
password, not even a smartcard. Today, this is not enough.

All Debian developers should sign code with a smartcard and the main
GPG key should be protected in an HSM. Unless this is the case, you can
consider Debian keys as "compromised". Please note that I have been
using Debian since 1998. But at least I am aware of the lack of
security of Linux distros.

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


Re: getting rid of ME on modern CPUs (Re: [qubes-users] QSB #46: APT update mechanism vulnerability)

2019-01-29 Thread Stuart Perkins
Like I said, we need to reverse engineer.

On Mon, 28 Jan 2019 17:56:17 +
Holger Levsen  wrote:

>On Mon, Jan 28, 2019 at 11:46:55AM -0600, Stuart Perkins wrote:
>> Up to a certain manufacture, you can go to coreboot and lose the ME 
>> entirely.  After that point, setting the HAP bit may be your best option.  
>> We need someone to to reverse engineer the ME and implement enough of it in 
>> coreboot to take over so the newer ones will run.  
>
>thats not enough. on modern intel cpus there's boot-guard which will
>prevent booting with coreboot unless it's signed with a secret intel
>key.
>
>

-- 
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/20190129071645.629953f1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


pgpW4tGXCZNTw.pgp
Description: OpenPGP digital signature


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

2019-01-29 Thread Patrik Hagara
On 1/25/19 3:16 PM, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 25, 2019 at 01:58:59PM +0100, Patrik Hagara wrote:
>> On 1/24/19 5:18 PM, Patrik Hagara wrote:
>>> On 1/20/19 1:57 AM, Marek Marczykowski-Górecki wrote:
 Hi all,

 There is updated "kernel" package available in current-testing
 repository - it's a Linux long term support 4.19.x series, as an update
 over 4.14.x before. Since the upgrade switches to the next major LTS
 branch, I'll keep it in current-testing repository longer than usual 1-2
 weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
 Please report new issues the usual way, at qubes-issues[1], or
 simply by replying here. In either case, please mark it clearly it
 happens after updating to 4.19, preferably including a link to the
 update:
 https://github.com/QubesOS/updates-status/issues/850

 4.19.x kernel was already available as kernel-latest package for some
 time. Users of kernel-latest will see the update to 4.19.15 too, but
 kernel-latest soon will carry 4.20.x kernel version.

 [1] https://github.com/QubesOS/qubes-issues/issues


>>>
>>> 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).
> 
>> The only error message I've been able to find so far is in dom0 Xorg log:
> 
>>> (EE) intel(0): Failed to submit rendering commands (Bad address),
>> disabling acceleration.
> 
> This is very likely related. Normally I'd say "Bad address" indicate
> user-space issue, but the only thing changed is the kernel version... It
> may be also that some kernel API have changed and the driver is using
> parts that weren't there before.
> 
> Anyway, I've looked into 'intel' X driver sources and the version we
> currently have (2.99.917) is the latest one. On the other hand, there
> was over 800 commits since that release and some of them may be related.
> For example maybe this: https://bugs.freedesktop.org/show_bug.cgi?id=105886
> 
> This suggests you may want to try enabling or disabling composition, if
> i3wm supports it.
> 
>> Duckduckgo-ing the error message yielded a few [1][2] Arch Linux bug
>> reports describing the same symptoms. The first bug report also has a
>> kernel patch [3] linked, which supposedly fixes the issue (haven't tried
>> it).
> 
> That patch is from 2014, already included in 3.19+
> 
>> [1] https://bugs.archlinux.org/task/43143
>> [2] https://bugs.archlinux.org/task/55732
>> [3]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91

Update!

Managed to get rid of the error (and more importantly, the annoying
artifacts) by forcing Xorg to use the generic modesetting driver instead
of i915/i965.

Steps (all commands in dom0):

1) check the driver currently in use (`xrandr --listproviders`), it's
the last string (should be "name:Intel" now)

2) create file /etc/X11/xorg.conf.d/20-intel.conf (as root) with the
following contents (also make sure there are no other files in that
directory with "Device" "Driver" set to "intel"):

> Section "Device"
>   Identifier "Intel Graphics"
>   Driver "modesetting"
>   Option "AccelMethod" "glamor"
>   Option "DRI" "3"
> EndSection

3) restart the X server (eg. using `sudo systemctl restart lightdm`)

4) use the same xrandr command as in step 1, the driver should now be
"modesetting" and you should see no errors in /var/log/Xorg.0.log, nor
any graphical artifacts


As a side note, I discovered a reliable reproducer for the issue: run
`glxgears` in dom0 and then start thunderbird in some appvm. For me,
this always triggered the i915 bug (logged in /var/log/Xorg.0.log) and
the gears stopped turning (due to the acceleration being disabled, I guess).

My hardware (sorry for not mentioning this earlier): Lenovo T480s with
i7-8650U, no discrete GPU.

Pages that have been helpful:
* https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX
*
https://ask.fedoraproject.org/en/question/130414/enabling-glamordri3-fedora-29-gnome-xorg/
*
https://www.reddit.com/r/Fedora/comments/5uo6ta/modesetting_driver_fedora_25/
*
https://www.phoronix.com/scan.php?page=news_item=Fedora-Xorg-Intel-DDX-Switch


Cheers,
Patrik

-- 
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 

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

2019-01-29 Thread goldsmith
On 2019-01-28 21:51, Alexandre Belgrand wrote:
> Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit :
>> To Alexandre Belgrand
>>
>> I'm intrigued how you know can catagorically state "CAs and GNU/Linux
>> distributions are #1 targets for national
>> intelligence agencies". This is classified information and therefore
>> only available to a "Spook". Otherwise, it's entered the public
>> domain
>> via say a whistle blower like Ed Snowden. If that's how you came upon
>> it, please state the source and location.
> 
> I am not a whistle blower, but I believe that all CAs and GNU/Linux
> distributions are primary targets for Intelligence agencies. This is
> not secret, this is why I am writing it, sitting behind my real IP. 
> 
> You will find this information on Internet. Look for the recent
> problems with China for example.
> 
> Stealing root certificates allow Intelligence agencies to set-up mirage
> Internet : i.e. decrypt SSL/crypted content and present modified
> content to the user and make man-in-the-middle attack.
> 
> Think about Debian private keys. The keys are stored on a server in a
> datacenter, not even on smartcards. What can stop a remote attacker
> with a remote console (either directly or using Intel ME) from stealing
> the keys and then breaking password using a keylogger in Intel ME.
> Answer : nothing can stop a local government from doing so.
> 
> Think about SSL X509 certificates. To deliver encrypted content, the
> private key has to be on the server. You only need serial console
> access to steal the private key. 
> 
> The only solution is to compile the same bytecode and verifying hashes
> online, but Debian is lagging behind important patches, because they
> don't understand what already happened.

To Alexandre
So you found this stuff on the internet and were gullible enough to
swallow it, hook line and sinker, without first verifying its
authenticity. I suppose your allegations against the Debian Team's
security keys are based on equally unstable foundations.

The making of serious random and unsolicited allegations with the
intention of scaremongering, could be described as TROLLING. 

-- 
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/0efc60370976fc6e0e12530b8a9c89e1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


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

2019-01-29 Thread qubes-fan


Jan 28, 2019, 9:25 PM by alexandre.belgr...@mailbox.org:

> Le lundi 28 janvier 2019 à 16:47 +0100, > qubes-...@tutanota.com 
> >  a
> écrit :
>
>> What do you yourself use?
>>
> Hope I can answer too. 
>
> I use an X230 with Intel ME disabled from BIOS. It costs about 160€ on
> the second hand market and it has pretty decent hardware. Lenovo claims
> that Intel ME can be disabled, but Intel ME is still running and may
> accept remote shadow connections given a signed certificate from Intel.
>
> This is why I am only reading the mailing list and not using Qubes. At
> present, I consider Qubes as an interesting development, but not
> reaching its goals because dom0 can be penetrated using Intel ME.
>
> I am quite amused by tails sending an update command on each boot. You
> can be sure to light red light in a control center and be penetrated
> within seconds if need be. Remember that governments have control of
> most outgoing nodes. So neither do I use Tor.
>
> You just can't simply store valuable documents on a computer when
> connected to a network. Companies that care about security should have
> a complete process to manage workstations and internal networks,
> without access to the Internet. We are back to ancien times.
>
> Kind regards,
> Alexandre Belgrand
>

Hardware is only one part, right? The question was about the package you use. 
What OS, network, apps...yu propose? So, what so you use?

Realize please, that you stand against SW, the OS (Qubes), arguing about HW. 
Also you argue about statements Qubes devs and especially Joanna Rutkowska, 
never claimed. They never claimed that Qubes is IME resistant. Actually the 
opossite. If they did, post their statement here please. I heard her instead  
stressing publicky and repeatedly that the IME is a global issue, not only of 
Intel (see PSP), to be addressed. You are fighting against non-existent claims 
arguing against Qubes. Even the name of the Qubes-OS - A REASONABLY secure OS. 
They dont claim Qubes is - An omnipotent 100% solution and IME resistant. Or do 
they? :)

The IME attack is only one of many possible attacks. If you are opened to this 
kind of attack only, and resistant against many others, present in the 
traditional OSes, you increased your sec reasonably.

Lets put it other way round. Everyone of us is a wrench-decryption 
non-resistant. If an adversary starts your thumb-wrench party, what 
finger-wrench decrypts your password and all the secrets? Now knowing this, do 
you use passwords or you just gave up, because the found that terrible 
wrench-security-hole in the system? Do you let your phone unencrypted and 
unlocked, available to anyone, your credit card number CVV and PIN public, 
cause both ways it can be cracked? Your email password, chat pass, your https 
cert if you own the domain? Do you keep your house unlocked at all times, cause 
both ways the lock can be hacked? Do you see the point?

And the last question. Last but not least. You stated in one of your 
conversations here that you want people to stop using Qubes for security. 
Interesting - why would wish to do that? What is the benefit for you? How do we 
know you are not just another IS spook tasked with the attack on reasonable 
secure system, which provides very high security for even semi-tech users? 

Also if you would like to increase you paranoia, read the Yasha Levine, 
Surveillance Valley. In that case you can forget everything and ask only one 
question - can the tech that was designed to enslave us, save us? And if so, 
how one does 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/84ef99dc3a6aad1e8e035b5dda640ed306d27792.ca...@mailbox.org
>  
> >
>  .
> 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/LXO7VPB--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.


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

2019-01-29 Thread Alexandre Belgrand
Le mardi 29 janvier 2019 à 09:51 +0200, Ilpo Järvinen a écrit :
> Yeah yeah, the only modification was that chip as claimed in the
> article? 
> Magically all the necessary signal pins were routed to its location
> but nothing else was changed (and you cannot have that many pins in 
> that sized chip anyway which will seriously limit the possible
> functionality 
> and processing speed). ...But it must all be true and present in
> thousands
> of servers because a sensational article so claims (funny though that
> the 
> so claimed victims of the attack consistently denied presence of such
> a 
> chip in their servers but I guess you'll anyway think they must be
> lying 
> for the benefit of the Chinese, damage control, because of the 
> "investigation", or whatever reason).


Good point. Obviously, this article has had access to classified
informations and is  part of a new "name and shame" policy. So can we
trust it?

My personal opinion is that adding backdoors in consumer electronics is
like an arms race. Once it starts, it cannot and will not stop.

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