Re: [qubes-users] more spontaneous rebooting, or, i’m as mad as hell and i’m not gonna take this anymore!

[Jon deps]

On 5/12/19 11:51 PM, google-urqzgfyzkpiwjxpxxpr...@public.gmane.org wrote:

related:
https://www.mail-archive.com/qubes-users-/jypxa39uh5tlh3mboc...@public.gmane.org/msg27890.html 



system may appear stable for over a month then flat-out reboot or may 
reboot within days. quite unpredictable.
tried toggling rc6 for i915, downgrading xen, kernels, disabling 
microcode_ctl, downgrading bios version and toggling assorted bios 
options. nothing.
fan works, sensors register values within operating range, reboots 
happen also when system is idle.

not a clue in logs (with default verbosity.)
in short, my trusty X220 has turned into a mysterious timebomb.
switching hardware in order to regain a solid (as in mucho uptime) system.

to unman, could you be a little bit more specific about the rig you 
mentioned which seems immune to this particular issue?

anyone else with system uptime 60+ days?

thank you



did you say how much RAM you have, how long it has been installed?  any 
new updates / upgrades ?


is it all stock hardware  SSD?

X220  is circa  what year , I know thinkpads are a good fit for qubes, 
but one might wonder if that means forever  :)


hate me but what about backing up all your qubes and reinstalling

--
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/4a2cfaa4-4af8-b430-0c74-a32b52d5f639%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Where can I find the documentation for qube services?

[unman]

On Wed, May 15, 2019 at 11:44:40PM -0700, Eccentric Butterfly wrote:
> Services include for example: clocksync, cups, qubes-firewall.
> 
> I would in particular like to know what meminfo-writer does as 
> https://qubes-os.org/doc/disposablevm-customization/ tells you to disable the 
> service on any new sys-net VM that you create. This is confusing because the 
> service appears to be switched off in the default sys-net VM anyways.
> 

man qvm-service

On meminfo-writer see:
https://www.qubes-os.org/doc/qmemman

I dont understand your confusion - yes, the default sys-net has the
service disabled. If you create a new sys-net qube then you should
disable the service, just as you say.

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

Re: [qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

['Ilpo Järvinen' via qubes-users]

On Thu, 16 May 2019, g80vmgm...@riseup.net wrote:

> From XSA297:
> """
> Work is ongoing on xen-devel to develop core-aware scheduling, which
> will mitigate the cross-domain leak by ensuring that vcpus from
> different domains are never concurrently scheduled on sibling threads.
> However, this alone will not prevent cross-privilege level leakage from
> within the same domain, including leakage from Xen.
> """
> 
> I'm sorry, I'm not subscribed to xen-devel and am too lazy to go through
> its archives.  Is anyone from the Qubes team monitoring this--or better,
> participating in it?
> 
> I can imagine a few Qubes-specific mitigations that might use some Xen
> scheduling features to defend against future types of side-channel info
> leaks in CPUs:
> 
> 1) Schedule each domain in a given security label ('color') on a
> specific CPU.  If there are not enough CPUs, make clear to the user
> which colors might be scheduled on the same physical CPU core.
> 
> 2) Most (all?) CPUs that support Qubes have at least 2 cores.  Assign
> the first core the 'high' security label.  Assign all other cores the
> 'low' security label.  Assign dom0, possible future AdminVM, and any
> user-designated VMs the 'high' security label.  Schedule high-labeled
> VMs exclusively on high-labeled CPU cores, and never schedule a
> low-labeled VM on a high-labeled CPU core.
> 
> Information could still leak through e.g. shared caches, and special
> attention obviously must be paid there, but this might be a useful
> mitigation for similar kinds of attacks discovered in the future.
>
> It could be worthwhile to sketch out what kinds of features Qubes might
> need from Xen in order to accomplish this kind of thing and work with
> them while they develop this new scheduler.

There is also some L3 cache region masking feature (CAT, which is also 
supported by Xen) onwards from Broadwell (but it might be only available 
for Xeons). And whether it could really close the L3 side-channels or 
not probably depends on internal L3 architecture (if an off-masked L3 
region contains the attacked data, whether it is retrieved by CPU or not).


-- 
 i.

-- 
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/alpine.DEB.2.20.1905162013440.30836%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How would an adversary hack into your appVMs?

['awokd' via qubes-users]

Eccentric Butterfly:

I'm curious if and how someone could hack into your appVMs if there is a 
firewall VM in the way. How would they detect that there is a VM on your PC 
that is accessing the network connection provided by that VM? Would it just 
appear to them that all the network traffic is coming from sys-firewall?


All network traffic would appear to be coming from sys-net, not 
sys-firewall. Someone sniffing network traffic would have a difficult 
time finding out if it came from a particular VM unless it was running a 
significantly different OS than the others. Most common way to 
compromise a client is to get them to click on a bad link that then 
exploits an OS or application vulnerability.


 Suppose, for example, someone is using seriously out of date packages 
and the entire firewall VM becomes a nest for hackers to get busy, would 
they then easily be able to hack your appVMs and thus easily have access 
to your files?




If it was an external attack, they'd have to compromise sys-net first, 
then sys-firewall. If they could manage that, they could likely vector 
into AppVMs with the same attacks, but if they're that good they could 
hack into almost every GNU/Linux server out there.


--
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/602d6d8f-c07e-683f-d081-90da32244858%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Where can I find the documentation for qube services?

['awokd' via qubes-users]

Eccentric Butterfly:

Services include for example: clocksync, cups, qubes-firewall.

I would in particular like to know what meminfo-writer does as 
https://qubes-os.org/doc/disposablevm-customization/ tells you to disable the 
service on any new sys-net VM that you create. This is confusing because the 
service appears to be switched off in the default sys-net VM anyways.

Only place might be source code. Some modules have a README describing 
them, but I don't know about those.


--
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/46d6af2f-1d1d-0745-cffe-1effd222451f%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] AppVM Qube date created ?

[Jon deps]

Hello  is there any way to see the date an AppVM/s  were created ?  This 
would be convenient.


--
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/291ad33c-e293-1a8b-ca7d-194f863b7004%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

[g80vmgmsqw]

Ilpo Järvinen:
> On Thu, 16 May 2019, g80vmgm...@riseup.net wrote:
> 
>> From XSA297:
>> """
>> Work is ongoing on xen-devel to develop core-aware scheduling, which
>> will mitigate the cross-domain leak by ensuring that vcpus from
>> different domains are never concurrently scheduled on sibling threads.
>> However, this alone will not prevent cross-privilege level leakage from
>> within the same domain, including leakage from Xen.
>> """
>>
>> I'm sorry, I'm not subscribed to xen-devel and am too lazy to go through
>> its archives.  Is anyone from the Qubes team monitoring this--or better,
>> participating in it?
>>
>> I can imagine a few Qubes-specific mitigations that might use some Xen
>> scheduling features to defend against future types of side-channel info
>> leaks in CPUs:
>>
>> 1) Schedule each domain in a given security label ('color') on a
>> specific CPU.  If there are not enough CPUs, make clear to the user
>> which colors might be scheduled on the same physical CPU core.
>>
>> 2) Most (all?) CPUs that support Qubes have at least 2 cores.  Assign
>> the first core the 'high' security label.  Assign all other cores the
>> 'low' security label.  Assign dom0, possible future AdminVM, and any
>> user-designated VMs the 'high' security label.  Schedule high-labeled
>> VMs exclusively on high-labeled CPU cores, and never schedule a
>> low-labeled VM on a high-labeled CPU core.
>>
>> Information could still leak through e.g. shared caches, and special
>> attention obviously must be paid there, but this might be a useful
>> mitigation for similar kinds of attacks discovered in the future.
>>
>> It could be worthwhile to sketch out what kinds of features Qubes might
>> need from Xen in order to accomplish this kind of thing and work with
>> them while they develop this new scheduler.
> 
> There is also some L3 cache region masking feature (CAT, which is also 
> supported by Xen) onwards from Broadwell (but it might be only available 
> for Xeons). And whether it could really close the L3 side-channels or 
> not probably depends on internal L3 architecture (if an off-masked L3 
> region contains the attacked data, whether it is retrieved by CPU or not).
> 
> 

Interesting.  I have not heard of this feature before.  I'll look into
it.  Thanks!

I think it's also time to seriously consider deploying something like
TRESOR[1], especially in combination with 2) above.  It must be
carefully designed so it doesn't leave the keys _more_ exposed to leaks,
though.

[1]: Tilo Mueller, Felix C. Freiling, Andreas Dewald. "TRESOR Runs
Encryption Securely Outside RAM".
https://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor.pdf

-- 
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/7a059aff-8806-5cc2-d963-a7342c029654%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] more spontaneous rebooting, or, i’m as mad as hell and i’m not gonna take this anymore!

[google]

On 2019-05-15 12:48, unman wrote:

x230 i7 16GB on docking station.
x230 i7 16GB - coreboot
x230 i7 12GB


alright, i'll report back once i've done some testing. thank you unman!

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

Re: [qubes-users] Re: Spontaneous rebooting

[google]

On 2019-05-14 11:33, goo...@subvertising.org wrote:

calling unman et al. : what systems are sporting 60+
days uptime?


according to unman, the i7 X230 does not reboot spontaneously.

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

[qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

[g80vmgmsqw]

Marek Marczykowski-Górecki:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear Qubes Community,
> 
> We have just published Qubes Security Bulletin (QSB) #49: Microarchitectural
> Data Sampling speculative side channel (XSA-297).
> The text of this QSB is reproduced below.
> This QSB and its accompanying signatures will always be available in
> the Qubes Security Pack (qubes-secpack).
> 
> View QSB #49 in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and read
> it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> ```
> 
> 
>  ---===[ Qubes Security Bulletin #49 ]===---
> 
>  2019-05-15
> 
> 
> Microarchitectural Data Sampling speculative side channel (XSA-297)
> 
> Summary
> 
> 
> On 2018-05-14, the Xen Security Team published Xen Security Advisory
> 297 (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 /
> XSA-297) [1] with the following description:
> 
> | Microarchitectural Data Sampling refers to a group of speculative
> | sidechannels vulnerabilities.  They consist of:
> | 
> |  * CVE-2018-12126 - MSBDS - Microarchitectural Store Buffer Data Sampling
> |  * CVE-2018-12127 - MLPDS - Microarchitectural Load Port Data Sampling
> |  * CVE-2018-12130 - MFBDS - Microarchitectural Fill Buffer Data Sampling
> |  * CVE-2019-11091 - MDSUM - Microarchitectural Data Sampling Uncacheable 
> Memory
> | 
> | These issues pertain to the Load Ports, Store Buffers and Fill Buffers
> | in the pipeline.  The Load Ports are used to service all memory reads.
> | The Store Buffers service all in-flight speculative writes (including
> | IO Port writes), while the Fill Buffers service all memory writes
> | which are post-retirement, and no longer speculative.
> | 
> | Under certain circumstances, a later load which takes a fault or
> | assist (an internal condition to processor e.g. setting a pagetable
> | Access or Dirty bit) may be forwarded stale data from these buffers
> | during speculative execution, which may then be leaked via a
> | sidechannel.
> | 
> | MDSUM (Uncacheable Memory) is a special case of the other three.
> | Previously, the use of uncacheable memory was believed to be safe
> | against speculative sidechannels.
> | 
> | For more details, see:
> |   
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html
> | 
> | An attacker, which could include a malicious untrusted user process on
> | a trusted guest, or an untrusted guest, can sample the content of
> | recently-used memory operands and IO Port writes.
> | 
> | This can include data from:
> | 
> |  * A previously executing context (process, or guest, or
> |hypervisor/toolstack) at the same privilege level.
> |  * A higher privilege context (kernel, hypervisor, SMM) which
> |interrupted the attacker's execution.
> | 
> | Vulnerable data is that on the same physical core as the attacker.
> | This includes, when hyper-threading is enabled, adjacent threads.
> | 
> | An attacker cannot use this vulnerability to target specific data.
> | An attack would likely require sampling over a period of time and the
> | application of statistical methods to reconstruct interesting data.
> 
> This is yet another CPU hardware bug related to speculative execution.
> 
> Only Intel processors are affected.
> 
> Patching
> =
> 
> The Xen Project has provided patches that mitigate this issue. A CPU
> microcode update is required to take advantage of them. Note that
> microcode updates may not be available for older CPUs. (See the Intel
> advisory linked above for details.)
> 
> The specific packages that resolve the problems discussed in this
> bulletin are as follows:
> 
>   For Qubes 4.0:
>   - Xen packages, version 4.8.5-6
>   - microcode_ctl 2.1-28.qubes1
>   - kernel-qubes-vm package, version 4.19.43-1 (optional)
> 
> The packages are to be installed in dom0 via the Qubes VM Manager or via
> the qubes-dom0-update command as follows:
> 
>   For updates from the stable repository (not immediately available):
>   $ sudo qubes-dom0-update
> 
>   For updates from the security-testing repository:
>   $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
> 
> A system restart will be required afterwards.
> 
> These packages will migrate from the security-testing repository to the
> current (stable) repository over the next two weeks after being tested
> by the community.
> 
> If you use Anti Evil Maid, you will need to reseal your secret
> passphrase to new PCR values, as PCR18+19 will change due to the new
> Xen binaries.
> 
> Credits
> 
> 
> See the original Xen Security Advisory.
> 
> References
> ===
> 
> [1] https://xenbits.xen.org/xsa/advisory-297.html
> 
> - --
> The Qubes Security Team
> 

[qubes-users] Installing dom0 updates from source

['Public Email Account' via qubes-users]

For the newest security updates mention in  
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-049-2019.txt how 
can I install the security updates from security-testing repo but from source 
code? I prefer to compile or install everything from source code. I do not 
trust pre-baked binaries. I know, microcode is binary. But Intel is horrible so 
there is no way to escape closed source binary. But there is probably a higher 
security risk from not having latest microcode than that of the microcode 
itself being dangerous right? It is not known if microcode contains backdoors 
but it is known that the security vulnerabilities from lack of microcode is as 
dangerous as a backdoor.

But to my question how can I install latest dom0 updates from source?
Thank you
Granny

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-- 
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/bHojCYJjOwlLpxFYR5BzMAUbdB8G77Z5edZcFkF-8VkKxy_5tFnB-916B-wPMSO-OcDMDrpOLH29uRMt3Iy0gSIRDFizl-FbPNsEs4Y0Cak%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Bluetooth devices

[Franz]

On Tue, May 7, 2019 at 12:51 PM  wrote:

> Hello everyone!
>
> I would like to know if it's possible to use Bluetooth devices (mouse,
> keyboard...) on Qubes OS?
>
> I use Qubes 4.0 on a SanDisk Extreme Pro 256gb USB 3.1 key.
>
>
There is no way to get any form of security with bluetooth. So it is at
odds with Qubes. But if you live totally isolated I imagine you should be
able to get it working in dom0.

-- 
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-qAucVr%3DmCnf%2B9QwSrW4iPnoFhXKvWrPiWT8RvYh8TEOOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] whonix-gw: 'Hash sum mismatch' on update

[Chris Laprise]

I'm getting a hash sum error when updating my whonix-gw-14 template 
today. No error occurred when updating whonix-ws-14.


See below for the apt-get output...

--

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

---

user@host:~$ sudo apt-get update && sudo apt-get dist-upgrade -V
Hit:1 
tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion 
stretch InRelease

Hit:2 https://deb.qubes-os.org/r4.0/vm stretch InRelease
Hit:3 https://deb.whonix.org stretch InRelease
Get:4 https://cdn-aws.deb.debian.org/debian-security stretch/updates 
InRelease [94.3 kB]

Ign:5 https://cdn-aws.deb.debian.org/debian stretch InRelease
Ign:6 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/main amd64 Packages
Ign:6 https://deb.debian.org/debian-security stretch/updates/main amd64 
Packages
Ign:6 https://deb.debian.org/debian-security stretch/updates/main amd64 
Packages
Get:8 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/main Translation-en [219 kB]
Ign:6 https://deb.debian.org/debian-security stretch/updates/main amd64 
Packages
Ign:9 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/contrib amd64 Packages
Ign:10 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/contrib Translation-en
Ign:9 https://deb.debian.org/debian-security stretch/updates/contrib 
amd64 Packages
Ign:10 https://deb.debian.org/debian-security stretch/updates/contrib 
Translation-en
Ign:9 https://deb.debian.org/debian-security stretch/updates/contrib 
amd64 Packages
Get:11 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/non-free amd64 Packages [1600 B]
Ign:10 https://deb.debian.org/debian-security stretch/updates/contrib 
Translation-en
Ign:12 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/non-free Translation-en
Ign:9 https://deb.debian.org/debian-security stretch/updates/contrib 
amd64 Packages
Get:7 https://cdn-aws.deb.debian.org/debian stretch Release [118 kB] 

Ign:12 https://deb.debian.org/debian-security stretch/updates/non-free 
Translation-en
Err:6 https://deb.debian.org/debian-security stretch/updates/main amd64 
Packages
  Could not open file 
/var/lib/apt/lists/partial/deb.debian.org_debian-security_dists_stretch_updates_main_binary-amd64_Packages.xz 
- open (13: Permission denied)
Ign:6 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/main amd64 Packages
Ign:10 https://cdn-aws.deb.debian.org/debian-security 
stretch/updates/contrib Translation-en
Get:13 https://cdn-aws.deb.debian.org/debian stretch Release.gpg [2434 
B]
Ign:14 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages 

Ign:14 https://deb.debian.org/debian stretch/main amd64 Packages 

Ign:15 https://cdn-aws.deb.debian.org/debian stretch/main Translation-en 

Ign:14 https://deb.debian.org/debian stretch/main amd64 Packages 

Ign:15 https://deb.debian.org/debian stretch/main Translation-en 

Hit:16 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Contents 
(deb)
Ign:17 https://cdn-aws.deb.debian.org/debian stretch/contrib amd64 
Packages
Err:16 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Contents 
(deb)

  Hash Sum mismatch
  Hashes of expected file:
   - Filesize:454716312 [weak]
   - 
SHA256:df16245f9b562e1a117f47de690ade03764ae5657f5ec0369f9022bbd986b73f

   - MD5Sum:a1d10bd031a34924bec90b1fb5a6cc73 [weak]
  Hashes of received file:
   - 
SHA256:79dd0f0cf90997bdbf3ce0f53afaa387940dd5cf5ecdc5481797c1ed3b97b140

   - MD5Sum:c8cfadf002c939766747bf23a01d976c [weak]
   - Filesize:54725988 [weak]
  Release file created at: Sat, 27 Apr 2019 09:29:22 +
Ign:18 https://cdn-aws.deb.debian.org/debian stretch/contrib 
Translation-en
Ign:19 https://cdn-aws.deb.debian.org/debian stretch/contrib amd64 
Contents (deb)
Ign:20 https://cdn-aws.deb.debian.org/debian stretch/non-free amd64 
Packages
Hit:21 https://cdn-aws.deb.debian.org/debian stretch/non-free 
Translation-en
Hit:22 https://cdn-aws.deb.debian.org/debian stretch/non-free amd64 
Contents (deb)

Fetched 436 kB in 26s (16.7 kB/s)
Reading package lists... Done
E: Failed to fetch 
https://deb.debian.org/debian-security/dists/stretch/updates/main/binary-amd64/Packages 
 Could not open file 
/var/lib/apt/lists/partial/deb.debian.org_debian-security_dists_stretch_updates_main_binary-amd64_Packages.xz 
- open (13: Permission denied)
E: Failed to fetch 
https://cdn-aws.deb.debian.org/debian-security/dists/stretch/updates/contrib/binary-amd64/Packages 
 Could not open file 
/var/lib/apt/lists/partial/deb.debian.org_debian-security_dists_stretch_updates_contrib_binary-amd64_Packages.xz 
- open (13: Permission denied)
E: Failed to fetch 
https://cdn-aws.deb.debian.org/debian/dists/stretch/main/binary-amd64/Packages.gz 
 Could not open file 
/var/lib/apt/lists/partial/deb.debian.org_debian_dists_stretch_main_binary-amd64_Packages.xz 
- open (13: Permission denied)
E: Failed to fetch 

[qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

[Chris Laprise]

On 5/15/19 6:24 PM, Marek Marczykowski-Górecki wrote:

Only Intel processors are affected.
I think the pattern showing AMD to be more conscientious in their 
processor designs is now undeniable. Even if its only a matter of 
degree, the difference appears to be rather substantial.


You should consider recommending a switch to AMD processors as a 
short-term mitigation against CPU vulnerabilities.


--

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/42d6b17d-dd3e-2610-ce18-5bb62421a46c%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Why does the spectre poc still work?

[Marco Marais]

I already have all the patches installed including the ones fixing MDS. And all 
CVEs are reported to be NOT VULNERABLE by this tool. 
https://github.com/speed47/spectre-meltdown-checker
Also, same result by the one whonix provides.

But this poc still works, why?
https://github.com/crozone/SpectrePoC

-- 
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/36551b12-2803-422f-8122-c690d5a87825%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Do you need to harden sys-firewall in any way?

[Claudio Chinicz]

On Thursday, 16 May 2019 09:49:25 UTC+3, Eccentric Butterfly  wrote:
> There seems to not be much information on this. Are there any steps you can 
> or should take to harden your firewall vm? There are services in the qube 
> settings called: qubes-firewall, qubes-network, qubes-update-check, 
> qubes-updates-proxy. Neither of them are used in sys-net or sys-firewall. 
> Should they be?

Hi, check this out: 
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/

Maybe it"ll answer your concerns and even raise them..

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/ba35bb36-43c7-49eb-9f4f-b58b8e0fd481%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How would an adversary hack into your appVMs?

[Eccentric Butterfly]

I'm curious if and how someone could hack into your appVMs if there is a 
firewall VM in the way. How would they detect that there is a VM on your PC 
that is accessing the network connection provided by that VM? Would it just 
appear to them that all the network traffic is coming from sys-firewall? 
Suppose, for example, someone is using seriously out of date packages and the 
entire firewall VM becomes a nest for hackers to get busy, would they then 
easily be able to hack your appVMs and thus easily have access to your files?

-- 
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/be26cce3-640b-48fe-a37f-3094e0ce9014%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Do you need to harden sys-firewall in any way?

[Eccentric Butterfly]

There seems to not be much information on this. Are there any steps you can or 
should take to harden your firewall vm? There are services in the qube settings 
called: qubes-firewall, qubes-network, qubes-update-check, qubes-updates-proxy. 
Neither of them are used in sys-net or sys-firewall. Should they be?

-- 
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/2e295408-7380-4ba2-b7aa-f75f0b8c1a56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Where can I find the documentation for qube services?

[Eccentric Butterfly]

Services include for example: clocksync, cups, qubes-firewall.

I would in particular like to know what meminfo-writer does as 
https://qubes-os.org/doc/disposablevm-customization/ tells you to disable the 
service on any new sys-net VM that you create. This is confusing because the 
service appears to be switched off in the default sys-net VM anyways.

-- 
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/a195d8fe-e61e-45a0-8c6b-453373a7117a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.