Re: [qubes-users] qvm-convert-img: ValueError: No icon received

[Holger Levsen]

On Sun, Nov 26, 2017 at 05:50:17PM +, Unman wrote:
> > > It's a bug Holger.
> > > Scoot on over to GitHub and raise an issue
> > is it really? I cannot believe it's broken (in 3.2) and noone has raised
> > an issue yet…
> Well someone has to be first :-)
> 
> truth , I dont think that many people use the feature.
> But this is a bug for sure - same in deb8 and Fedora, at least for my
> 3.2

done now, as https://github.com/QubesOS/qubes-issues/issues/3344


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

[qubes-users] Re: Failed to load Kernel Modules

[cooloutac]

On Wednesday, November 22, 2017 at 10:44:58 AM UTC-5, haaber wrote:
> This is the first line while booting. So I checked  systemctl status
> systemd-modules-load.service that says the below. I see no errors .. all
> OK then??
> 
> Thank you, Bernhard
> 
> [me @dom0 ]
> 
>   systemd-modules-load.service - Load Kernel Modules
>Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service;
> static; vendor preset: disabled)
>Active: active (exited) since Wed 2017-11-22 10:30:29 EST; 2min 35s ago
>  Docs: man:systemd-modules-load.service(8)
>man:modules-load.d(5)
>   Process: 1299 ExecStart=/usr/lib/systemd/systemd-modules-load
> (code=exited, status=0/SUCCESS)
>  Main PID: 1299 (code=exited, status=0/SUCCESS)
> Tasks: 0 (limit: 4915)
>CGroup: /system.slice/systemd-modules-load.service
> 
> Nov 22 10:30:29 dom0 systemd-modules-load[1299]: Inserted module 'uinput'
> Nov 22 10:30:29 dom0 systemd-modules-load[1299]: Module 'xen_evtchn' is
> builtin
> Nov 22 10:30:29 dom0 systemd[1]: Started Load Kernel Modules.

I get failed to load kernels on boot of every qubes version.  I just ignore 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/9291ff24-ad75-4d1c-9ce7-ab8e75ff9a37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Move homedir to second drive

['Tom Zander' via qubes-users]

On Tuesday, 28 November 2017 03:07:02 CET Andrew David Wong wrote:
> On 2017-11-27 16:03, 'Tom Zander' via qubes-users wrote:
> > I have a ‘work’ VM which holds a significant amount of user-data
> > and as such I want my homedir to be hosted on my spinning-disk
> > drive.
[snip]
> This option works well for me on 3.2 (doesn't require auto-bind):
> 
> https://www.qubes-os.org/doc/secondary-storage/

Thanks for your answer,

it seems like this is no longer an option in 4.0 because VMs are no longer 
directories on the dom0 filesystem.
I may be wrong, but I understand they are actually partitions now.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

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

Re: [qubes-users] Random sudden reboots

[cooloutac]

On Monday, November 27, 2017 at 2:09:12 PM UTC-5, David Hobach wrote:
> On 11/27/2017 07:57 PM, David Hobach wrote:
> > On 11/27/2017 07:47 AM, Wael Nasreddine wrote:
> >> I'm running 4.0-RC2 on Asrock Z170 pro4/i7-6700k and I got two hard 
> >> reboots in the last few hours, often around the time I start a VM. I 
> >> do not see anything in the log.
> >>
> >> P.S: I've been running Citrix XenServer for two years on this machine 
> >> with no issues.
> >>
> >> Nov 26 22:36:38 dom0 sudo[911]: pam_unix(sudo:session): session closed 
> >> for user root
> >> Nov 26 22:36:38 dom0 audit[911]: USER_END pid=911 uid=0 auid=1000 
> >> ses=2 msg='op=PAM:session_close 
> >> grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_
> >> Nov 26 22:36:38 dom0 audit[911]: CRED_DISP pid=911 uid=0 auid=1000 
> >> ses=2 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" 
> >> exe="/usr/bin/sudo" hostname=? addr=?
> >> Nov 26 22:36:38 dom0 kernel: audit: type=1106 
> >> audit(1511764598.490:447): pid=911 uid=0 auid=1000 ses=2 
> >> msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyi
> >> Nov 26 22:36:38 dom0 kernel: audit: type=1104 
> >> audit(1511764598.490:448): pid=911 uid=0 auid=1000 ses=2 
> >> msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" exe="/us
> >> Nov 26 22:36:38 dom0 qmemman.daemon.algo[2304]: 
> >> balance_when_enough_memory(xen_free_memory=97794733, 
> >> total_mem_pref=5101760998.4, total_available_memory=60546306417.6)
> >> Nov 26 22:36:38 dom0 qmemman.daemon.algo[2304]: 
> >> left_memory=24233992215 acceptors_count=1
> >> -- Reboot --
> >> Nov 26 22:38:00 dom0 systemd-journald[240]: Runtime journal 
> >> (/run/log/journal/) is 8.0M, max 196.7M, 188.7M free.
> >> Nov 26 22:38:00 dom0 kernel: Linux version 
> >> 4.9.56-21.pvops.qubes.x86_64 (user@build-fedora4) (gcc version 6.4.1 
> >> 20170727 (Red Hat 6.4.1-1) (GCC) ) #1 SMP Wed Oct 18 00:2
> >> Nov 26 22:38:00 dom0 kernel: Command line: placeholder 
> >> root=UUID=9b846465-f59a-4f83-adfa-5468c915defd ro 
> >> rootflags=subvol=root rd.luks.uuid=luks-1b3c3eda-7836-443a-bc07-
> >> Nov 26 22:38:00 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x001: 
> >> 'x87 floating point registers'
> >> Nov 26 22:38:00 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x002: 
> >> 'SSE registers'
> >> Nov 26 22:38:00 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x004: 
> >> 'AVX registers'
> >> Nov 26 22:38:00 dom0 kernel: x86/fpu: xstate_offset[2]:  576, 
> >> xstate_sizes[2]:  256
> >> Nov 26 22:38:00 dom0 kernel: x86/fpu: Enabled xstate features 0x7, 
> >> context size is 832 bytes, using 'standard' format.
> >> Nov 26 22:38:00 dom0 kernel: x86/fpu: Using 'eager' FPU context switches.
> >> Nov 26 22:38:00 dom0 kernel: Released 0 page(s)
> >> Nov 26 22:38:00 dom0 kernel: e820: BIOS-provided physical RAM map:
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x-0x0009bfff] usable
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x0009c800-0x000f] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x0010-0x67e1] usable
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x67e2-0x67e20fff] ACPI NVS
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x67e21000-0x67e6afff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x67e6b000-0x67ebcfff] usable
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x67ebd000-0x68bedfff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x68bee000-0x6ee48fff] usable
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x6ee49000-0x6f7adfff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x6f7ae000-0x6ff99fff] ACPI NVS
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x6ff9a000-0x6fffefff] ACPI data
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x6000-0x6fff] usable
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x7000-0x77ff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0xe000-0xefff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0xfe00-0xfe010fff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0xfec0-0xfec00fff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0xfed9-0xfed91fff] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0xfee0-0xfeef] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0xff00-0x] reserved
> >> Nov 26 22:38:00 dom0 kernel: Xen: [mem 
> >> 0x0001-0x000191f95fff] usable
> > 
> > 
> > Yes, I can confirm that issue (except for the "around the time I start a 
> > VM"). Didn't find anything yet neither, my log looks similar. Some 
> > memory balancing tends to be the last entry.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[fepitre]

Le mardi 28 novembre 2017 18:33:38 UTC+1, Foppe de Haan a écrit :
> guest-wd.log from a (fedora) VM that won't boot with kernel-qubes-vm-4.14.2:

I confirm your log and the behavior. Few days ago, I tried to look on the xen 
and kernel list to see if there were something bug we need to dig into the 
problem...need time...

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

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Foppe de Haan]

On Tuesday, November 28, 2017 at 6:41:02 PM UTC+1, Frédéric Pierret (fepitre) 
wrote:
> Le mardi 28 novembre 2017 18:33:38 UTC+1, Foppe de Haan a écrit :
> > guest-wd.log from a (fedora) VM that won't boot with kernel-qubes-vm-4.14.2:
> 
> I confirm your log and the behavior. Few days ago, I tried to look on the xen 
> and kernel list to see if there were something bug we need to dig into the 
> problem...need time...

Understood; not trying to rush, of course, just thought to supply a log for a 
change. :p

-- 
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/f4106425-6f6d-463a-8e05-202d0939df85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Foppe de Haan]

guest-wd.log from a (fedora) VM that won't boot with kernel-qubes-vm-4.14.2: 

-- 
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/1336cccf-318c-4058-91b7-31e9fb22a7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[0.00] Linux version 4.14.2-1.pvops.qubes.x86_64 (user@kd) (gcc version 
6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 SMP Tue Nov 28 17:57:25 CET 2017
[0.00] Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 
rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 nopat
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'compacted' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9b3fefff] usable
[0.00] BIOS-e820: [mem 0x9b3ff000-0x9b3f] reserved
[0.00] BIOS-e820: [mem 0xfc00-0x] reserved
[0.00] x86/PAT: PAT support disabled.
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Xen HVM domU, BIOS 4.8.2 11/28/2017
[0.00] Hypervisor detected: Xen HVM
[0.00] Xen version 4.8.
[0.00] Netfront and the Xen platform PCI driver have been compiled for 
this kernel: unplug emulated NICs.
[0.00] Blkfront and the Xen platform PCI driver have been compiled for 
this kernel: unplug emulated disks.
[0.00] You might have to change the root device
[0.00] from /dev/hd[a-d] to /dev/xvd[a-d]
[0.00] in your root= kernel command line option
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: last_pfn = 0x9b3ff max_arch_pfn = 0x4
[0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.00] found SMP MP-table at [mem 0x000f6a40-0x000f6a4f] mapped at 
[ff240a40]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Using GB pages for direct mapping
[0.00] RAMDISK: [mem 0x7fa7a000-0x7fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F6990 24 (v02 Xen   )
[0.00] ACPI: XSDT 0xFC00A7B0 54 (v01 XenHVM  
 HVML )
[0.00] ACPI: FACP 0xFC00A490 F4 (v04 XenHVM  
 HVML )
[0.00] ACPI: DSDT 0xFC001460 008FAC (v02 XenHVM  
 INTL 20160831)
[0.00] ACPI: FACS 0xFC001420 40
[0.00] ACPI: FACS 0xFC001420 40
[0.00] ACPI: APIC 0xFC00A590 B0 (v02 XenHVM  
 HVML )
[0.00] ACPI: HPET 0xFC00A6C0 38 (v01 XenHVM  
 HVML )
[0.00] ACPI: WAET 0xFC00A700 28 (v01 XenHVM  
 HVML )
[0.00] ACPI: SSDT 0xFC00A730 31 (v02 XenHVM  
 INTL 20160831)
[0.00] ACPI: SSDT 0xFC00A770 31 (v02 XenHVM  
 INTL 20160831)
[0.00] No NUMA configuration found
[0.00] Faking a node at [mem 0x-0x9b3fefff]
[0.00] NODE_DATA(0) allocated [mem 0x9b3ed000-0x9b3fefff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x9b3fefff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x9b3fefff]
[0.00] Initmem setup node 0 [mem 0x1000-0x9b3fefff]
[0.00] ACPI: PM-Timer IO Port: 0xb008
[0.00] IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-47
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 

Re: [qubes-users] Qubes for "dummies"

['Tom Zander' via qubes-users]

On Tuesday, 28 November 2017 18:33:37 CET Foppe de Haan wrote:
> Bottom line IMO these days security can't be done by a layman,

Security as a concept is not that black / white, there is no 100% security 
and likewise I fail to see how "laymen" can't increase their security.
As a quick example, in Windows you can download an exe and start it with 
zero technical knowledge.
In Linux a downloaded executable can't be started without the user 
explicitly marking it "executable".

Guiding people into doing the right thing can be done.
As long as you don't aim for perfect security (which honestly doesn't exist 
anyway), you can help people increase their security significantly.

In my humble opinion, this is already happening in Qubes. The NetVM is a 
good example of a standard setup that has become completely transparant to 
users while isolating them from bad drivers causing security issues for many 
other linux users.

The people that need this most are those that don't have the technical know-
how, exactly because they don't understand how opening an executable or PDF 
from the net can cause any harm.
The point I'm trying to make is that those people can already use this 
software today, but many of the more fun features are impossible to them 
because they have not been made easy.


I'd also like to mention that all things require time to learn, I'd like to 
set up some firewall rules to let different VMs communicate between 
themselves.  But lacking a nice GUI I have to figure out how to do this at 
the command line, and I honestly just don't have the time to learn that 
right now.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

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

[qubes-users] Re: Eve V - nice QubesOS platform?

[cooloutac]

I'd want something with more ram for Qubes.  I'd say 8 is minimum, 32gb 
recommended.  I had 8 on a desktop and was hitting limit sometimes so I added 
another 8.  A laptop would probably use more.

 And most importantly to know if iommu protections work on it.  You would 
either have to look at the bios manual,  or load a qubes live usb on it to 
check.

-- 
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/4a497588-62b6-477b-962b-13d6d0efae19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Failed to load Kernel Modules

['Tom Zander' via qubes-users]

On Tuesday, 28 November 2017 14:18:44 CET cooloutac wrote:
> Of course many feel Qubes is for more advanced users,  and apparently that
> will become a self fulfilling prophecy in version 4.

Looking at the (lack of) UI tools at this time, you can be excused thinking 
this. I personally think its a focus issue. The core devs are good at 
security, and that is where their focus is.
The people behind Qubes don't have to focus on usability, though. They can 
focus on an awesome core while others focus on tooling.

I'd love to help write some great user interfaces that improve upon the 
Qubes supplied ones (which is a low bar), and do that in an open source 
manner which help improve the usability for everyone.
As long as I don't have to use python, so the only thing we really need is a 
good interface which is language-agnostic.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

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

Re: [qubes-users] Qubes for "dummies"

['Tom Zander' via qubes-users]

On Tuesday, 28 November 2017 03:38:02 CET Andrew David Wong wrote:
> Our position is that reasonable security
> via compartmentalization (of which Qubes is an implementation) requires
> the user to make informed decisions about how to compartmentalize
> various parts of their digital life into separate domains.

I fully agree with genevieve on all he said, and I'm not sure if the answer 
I quoted above is a good answer to his worries.
Lets avoid making conclusions about "dummies", I personally would say a lot 
of people can make a much more secure setup using Qubes even if they are 
completely inable to use a command line.

The trick is to not treat your users like morons but at the same time create 
usable and well designed (graphical) tools.

What is missing currently is support for anything that is not xfce and while 
genevieve prefers Gnome, I perfer KDE.

The GUI tools that Qubes came with in 3.2 are hardly done (many missing 
features) in 4.0, and thats Ok because they can be done at a later time.
Writing usability centric tools is hard.

What would be ideal is the opening of the APIs for 3rd party implementation. 
Naturally, there is an API, but its a python API, which is not exactly the 
most used API for graphical tools.
I would argue that opening up the qubesd interface to users using other 
languages will open up the playing field to many GUI developers.
Maybe even get some KDE / Gnome native integration.
I won't speak for the core Qubes devs, but I would not be surprised if they 
would welcome others helping out with GUI tools because if you are good at 
security and Xen and stuff, that doesn't mean you enjoy doing GUIs.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

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

Re: [qubes-users] Qubes for "dummies"

[taii...@gmx.com]

On 11/28/2017 11:30 AM, 'Tom Zander' via qubes-users wrote:


On Tuesday, 28 November 2017 03:38:02 CET Andrew David Wong wrote:

Our position is that reasonable security
via compartmentalization (of which Qubes is an implementation) requires
the user to make informed decisions about how to compartmentalize
various parts of their digital life into separate domains.

I fully agree with genevieve on all he said, and I'm not sure if the answer
I quoted above is a good answer to his worries.
Lets avoid making conclusions about "dummies", I personally would say a lot
of people can make a much more secure setup using Qubes even if they are
completely inable to use a command line.
Bottom line IMO these days security can't be done by a layman, you NEED 
to be at least a power-user to avoid pain of "it is broken and I can't 
fix it".


I believe a computer user from 30 years ago would have an easier time 
than today's user simply due to them being used to using a CLI.


--
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/d6cd0da1-3162-a73f-a2ec-bcf7e9a15731%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Foppe de Haan]

On Tuesday, November 28, 2017 at 6:41:02 PM UTC+1, Frédéric Pierret (fepitre) 
wrote:
> Le mardi 28 novembre 2017 18:33:38 UTC+1, Foppe de Haan a écrit :
> > guest-wd.log from a (fedora) VM that won't boot with kernel-qubes-vm-4.14.2:
> 
> I confirm your log and the behavior. Few days ago, I tried to look on the xen 
> and kernel list to see if there were something bug we need to dig into the 
> problem...need time...

could also be feature changes, I guess, given that 4.14 received some xen 
'love' as well (to p2m, among other things): https://lkml.org/lkml/2017/9/6/487

-- 
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/e94197a2-ce11-4f25-88c5-4fa5f93cf89d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Printer working with Debian DVMs but not when opening up a doc in a DVM from e.g. Work VM?

[velcro]

I am using Qubes 3.2, I have a dedicated Debian Template for my more trusted 
VMs and a separate dedicated Debian Template for my DVMs with printer drivers 
installed.

This is tricky but I will try to explain:

I managed to get my printer set up using a Debian Template(printed Test Page 
fine from template).

Changed my DVM to Debian, I can print a web page and document using a Dedicated 
Debian based DVM i.e. Q(Top left Q menu icon) -> DisposableVM...no issues with 
printing web pages and transfered docs from here!

When I use a trusted VM(lets say my Work VM), I open a document using "Open in 
DisposableVM", I see the printer I set up, try to print and I get an 
error(something like "printer not connected")?

What might cause this? Any thoughts on a fix?

Thanks in advance...



-- 
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/ebb48684-2e63-4797-9189-b3cce4768e90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes support Secure Boot

[cooloutac]

On Thursday, November 23, 2017 at 7:55:21 AM UTC-5, Leo Gaspard wrote:
> On 11/23/2017 03:35 AM, taii...@gmx.com wrote:
> > On 11/22/2017 07:25 PM, xeph...@gmail.com wrote:
> >> This is quite late, but now that UEFI is supported...is secure boot? 
> >> Wasn't quite sure what key or signature to import.
> > Why are all the newbies here so obsessed with a microsoft technology?
> > 
> > Just shut it off, it provides no benefit to you. If their code is so
> > great and beneficial to you why not simply install windows 10? they say
> > it is safe and secure just like SB 2.0...
> > 
> > [... more of the same]
> 
> Can you please avoid ranting against secure boot once again?
> 
> Secure boot is *not* useless. It *does* bring security benefits,
> although not as good as measured boot with a TPM: it requires an
> additional flaw somewhere in the {BIOS, bootloader} to bypass, instead
> of just coming in and replacing a non-encrypted element of the bootchain
> by taking the hard disk out of its case without ever being noticed. So
> if you have no TPM, using secure boot is a definitive security enhancement.
> 
> That said, to answer the original question, Qubes doesn't support secure
> boot out of the box yet as far as I can tell.

My vote is to use both.  Or as Intel puts it to use all three of trusted, 
measured, and secured boot. Enterprise systems also throw malware scanners 
somewhere in there during the mix.

Richard Stallman predicted secureboot would lock out software, but he was 
wrong. He half heartedly says "Microsoft failed their intended purpose",  and 
Even He suggests using secure boot as a security feature now.  Which is all it 
ever really was.  MS even has option to turn off driver signing in the 
software.  Some people, especially computer guys,  have trouble admitting when 
they are wrong.

Nothing is 100% secured,  but secure boot stopped hacking teams famous bios 
attack, and i'm sure theres more like it out there.  And in this world where 
remote bios attacks are possible,  thats enough for me to not call any system 
even reasonably secure if it doesn't have secure boot enabled.

And i've said before,  Security mostly depends on the USER more then the 
hardware and operating system.  Some user tasks are inherently unsafe no matter 
what and you would have to limit yourself using your own volition, regardless 
or hardware or software.  And imo,  A hardened windows system, especially if 
enterprise, is much safer for the AVG user then a similarly hardened linux 
system.  (I just saw Tai's head explode) 

Of course many feel Qubes is for more advanced users,  and apparently that will 
become a self fulfilling prophecy in version 4.

-- 
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/5029c6af-b7fa-4b91-837e-9809254e2acb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] QSB #36: Xen hypervisor issue in populate-on-demand code (XSA-247)

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #36:
Xen hypervisor issue in populate-on-demand code (XSA-247).
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 #36 in the qubes-secpack:



Learn about the qubes-secpack, including how to obtain, verify, and read it:



View all past QSBs:



View XSA-247 in the XSA Tracker:



```
 ---===[ Qubes Security Bulletin #36 ]===---

  November 28, 2017


  Xen hypervisor issue in populate-on-demand code (XSA-247)

Summary


The Xen Security Team has published Xen Security Advisory 247, which
concerns an issue with the populate-on-demand mechanism used to overbook
memory. We believe it would be very difficult, in practice, to exploit
this issue for privilege escalation.

Additionally, the Xen Security Team has published Xen Security
Advisory 246 (x86: infinite loop due to missing PoD error checking),
with the impact being denial of service only.

Technical details
==

Xen Security Advisory 247 [1]:

| Certain actions require modification of entries in a guest's P2M
| (Physical-to-Machine) table.  When large pages are in use for this
| table, such an operation may incur a memory allocation (to replace a
| large mapping with individual smaller ones).  If this allocation
| fails, the p2m_set_entry() function will return an error.
| 
| Unfortunately, several places in the populate-on-demand code don't
| check the return value of p2m_set_entry() to see if it succeeded.
| 
| In some cases, the operation was meant to remove an entry from the p2m
| table.  If this removal fails, a malicious guest may engineer that the
| page be returned to the Xen free list, making it available to be
| allocated to another domain, while it retains a writable mapping to
| the page.
| 
| In other cases, the operation was meant to remove special
| populate-on-demand entries; if this removal fails, the internal
| accounting becomes inconsistent and may eventually hit a BUG().
| 
| The allocation involved comes from a separate pool of memory created
| when the domain is created; under normal operating conditions it never
| fails, but a malicious guest may be able to engineer situations where
| this pool is exhausted.
| 
| An unprivileged guest can retain a writable mapping of freed memory.
| Depending on how this page is used, it could result in either an
| information leak, or full privilege escalation.
| 
| Alternatively, an unprivileged guest can cause Xen to hit a BUG(),
| causing a clean crash - ie, host-wide denial-of-service (DoS).

Xen Security Advisory 246 [2]:

| Failure to recognize errors being returned from low level functions in
| Populate on Demand (PoD) code may result in higher level code entering
| an infinite loop.
| 
| A malicious HVM guest can cause one pcpu to permanently hang.  This
| normally cascades into the whole system freezing, resulting in a a
| host Denial of Service (DoS).

Compromise Recovery


Beginning with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a potentially
compromised Qubes OS system. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please read and follow the procedure described here:

https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/

Patching
=

The specific packages that resolve the problem discussed in this
bulletin are as follows:

  For Qubes 3.2:
  - Xen packages, version 4.6.6-35

  For Qubes 4.0:
  - Xen packages, version 4.8.2-11

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-247.html
[2] https://xenbits.xen.org/xsa/advisory-246.html

- --
The Qubes Security Team
https://www.qubes-os.org/security/
```

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS

Re: [qubes-users] Re: Qubes support Secure Boot

[cooloutac]

> 
> > This is quite late, but now that UEFI is supported...is secure boot?  
> > Wasn't quite sure what key or signature to import.
> Why are all the newbies here so obsessed with a microsoft technology?
> 
> Just shut it off, it provides no benefit to you. If their code is so 
> great and beneficial to you why not simply install windows 10? they say 
> it is safe and secure just like SB 2.0...
> 
> "Secure" boot isn't secure, it is an anti-feature designed to eventually 
> remove the ability for average joes to install and boot linux - while SB 
> 1.0 included a owner control mandate this was conveniently left out of 
> SB 2.0 after the SB 1.0 media circus died down with the goal being the 
> eventual blocking of linux via attrition of board makers no longer 
> wanting to take the extra effort to allow for owner control or even add 
> the second SB key which allows people to boot the red hat signed version 
> of grub2.
> 
> If you have to ask for permission to run code it isn't your computer and 
> you do not own it you are simply purchasing a lease on it.
> I for one would never buy such a thing and neither should you (I have 
> re-programmed the firmware on all my workstations/servers - they are 
> owner controlled and are truly mine with no hardware code signing 
> enforcement anti-features - doesn't that sound better?)
> 
> Tell me, how does it prevent a rootkit? why couldn't that hypothetical 
> rootkit simply modify another critical system file instead of the 
> bootloader or kernel? or disable SB? (already root, hence rootkit - if 
> you have a zero day for windows you certainly have one for SB as well)

why are you so obsessed with microsoft.  Once again,  it would have nothing to 
do with them.   Richard Stallman admitted he was wrong.  Why can't you?

-- 
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/8322bb66-1dcf-49fc-99e1-ccbb2ce5978f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Bug in libxenlight

[Wael Nasreddine]

On Tuesday, November 28, 2017 at 10:28:38 AM UTC-8, 
bm-2ctrx1tl5lg8cfa...@bitmessage.ch wrote:
> When I tried create new VM based on Fedora I saw something strange because
> it don't want run even if I created VM based on Debian. And when I open
> terminal and for test run this commands I see this.

I had this issue installing 4-RC2, not sure what it is due. First, check that 
your system is capable of VT-d and VT-x. If both your CPU and your chipset 
supports it, make sure it is enabled in the bios. Check `sudo xl dmesg | grep 
VT` for hints. If VT-x and VT-d are enabled and you still get this error, try 
this workaround:

- Make sure it's a fresh install (revert your progress so far)
- When you are greeted with the setup after install, hit Ctrl-Alt-F3 to go to 
the console. If you got a black screen, try a few times Alt-F1 and Alt-F3 until 
you can loging
- Start the following bash loop (what's inside the back ticks) ` while true; do 
qvm-ls | grep -v NAME | awk '{print $1}' | xargs -I{} sudo qvm-prefs {} 
virt_mode pv; sleep 0.5; done`. This will continuously change the virt_mode to 
PV for all VMs
- Switch back to the setup with Alt-F2
- Continue setup, but do not login or reboot
- Switch back to Ctrl-Alt-F3
- Kill the loop and run `sudo qubes-dom0-update 
--enablerepo=qubes-dom0-current-testing`
- Switch all VMs back to HVM: `qvm-ls | grep -v NAME | awk '{print $1}' | xargs 
-I{} sudo qvm-prefs {} virt_mode hvm`
- Reboot

Sources:
- https://groups.google.com/forum/#!topic/qubes-users/Go04b5VsYfw
- https://groups.google.com/forum/#!topic/qubes-users/VD_U4k8qrbs

-- 
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/9b01ce82-0d64-48d1-a17b-28b09906cead%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AW: Re: [qubes-users] sys-usb won't start under Qubes 4.0rc2 / pci strict reset for RC2

['[799]' via qubes-users]

Hello David,

 Original-Nachricht 
An 27. Nov. 2017, 21:32, David Hobach schrieb:

>> Search for the related doc bug @qubes-issues.
>> It gives you the command, but I don't have it
>> at hand right now.

as Qubes 4rc3 has been released I've reinstalled RC3 and got rid of the problem 
with the sys-usb VM.

[799]

-- 
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/iF0M5SkBsNdEKQ_dhdx3OdTruQIpmpAmmfTkd_VtCouzrqWsECv4L_RRcq81MzYvt4b-H-KlJFOHluud5XEfGWMCaF7ljsmpD70CU9k2x_4%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

['[799]' via qubes-users]

Hello Unman,

>> It's perfectly possible that the installer (not principally written by
>> Qubes) could mistakenly include a passphrase string.

As far as I have understand, the problem is not that the password is shown, but 
that the report with this error mistake and the password could get transferred. 
I don't want that my password gets transferred in some part of an error report.

>> I've seen similar stuff included in all sorts of error reports in the past.

This might be true, but this doesn't make this less harmless, if the password 
is really bundled in an error report that gets transferered somewhere.

>> It doesn't mean that Qubes "can't be trusted"

Wait, it's not (!) about blaming the Qubes team.
If my understanding is correct, and the password is included in an error report 
that gets transferred to a 3rd party, this is a really bad thing as something 
like this should not happen from my understanding.

[799]

>> Also, since this is an installation error, let's not over egg the problem

-- 
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/2vKwbiORCF0Y-jH7FmGByGR2KjUE_uWWB7aM37w1BGKIBhobDyrJ99ult90ahUXjt0CrPMr0WDuOBIHTPwB7XlTjkwSqE5RmPisTB3A5Ycw%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[Genevieve Gauthier]

I do not know how to help you.  I have taken a picture without removing the
geotag (authentic picture /w geotag in my own living room.  the picture
(one of many) is in my iphone but my own finger is hiding MY OWN
PASSPHRASE... I could see it 20/20..  I still have everything I used (my
own laptop), my 8gb usbstick (installer) & a 32gb usbstick.  I have removed
the tag with exiftool -gps:all -xmp:all crazy.JPG ... as I intended to
provide proof without everyone seeing where I am living .. but it shows my
finger on my passphrase... :(

1)Now my laptop (the one I have used to copy from one usb with installer to
the other) is still there "intact" ..
2) The usb installer I used I have reformated it to reinstall (because of
this bug) .. but it tested fine.  (so any media that tested fine should be
ok)
3) The usbstick that I intended to install it on (the 32gb) is still there
...

What do you need me to do ? I do not expect my authentic/original (with my
finger) in front of my password would convince you ...
Should I need to focus on recreating the same condition that produce the
bug (my own) in the first place and take an original picture without my
finger to hide this problem (using another password like what?
Than I am sure with all you superior computer skills you could authenticate
my picture as unaltered ... However, are you able to create ANY
installation ERROR ?? This would validate with your OWN EYES what I have
seen! (100% to authenticate for you)

2nd option :  I believe someone with any strong programming skills should
look carefully at the part in Qubes 4.0 rc3 where ANY ERROR in the
installation of Qubes 4.0 rc3 and the lines that created this splash screen
('report bug').  This would in my opinion be a far more SUPERIOR way to
confirm what I have seen ... (unless you are able to create your own
installation error and see it 1ST OPTION)

I could be lying as anyone could be lying. The only way for you to know for
sure is to investigate this! I cannot do this myself because I have stopped
programming a couple of years ago and my skills are too "limited" to review
the code...


3rd option : (try recreating my bug on your/any system to see it for
yourself)
As far as my intuition goes.. the bug happened several times (still the
same report to Qubes where I could see my drive PASSWORD ) .. my 8gb tested
100%
my system is a dell laptop (but that should not have created the problem)
I try to install from my 8gb 100%tested media to my 32gb usbstick (sandisk
32gb).  My 32gb sandisk was full.  I have numerous pictures because I
intended to create a step by step guide to help my friend install Qubes.

3rd option (my technical date) I can see on another picture Local Standard
Data : 28.64gb SanDisk Ultra Fit sdb / 0 B free
I have another picture with the content of this usb stick (partition) :
Unknown Iso9660 sdb

I tried to automatically configure partitioning.
I do not have a picture of this but I remember there was a problem.  So, I
switched to "I will configure partitioning" (this is where I have a picture
of this Iso9660 which I do not even know what it is .. :(

Then I remember and have a picture of trying to press the "-" button after
clicking on this strange partition on my Sandisk 32gb usbstick

I know I had problem because I have a picture of showing "Click here to
create them automatically"  but it never worked
then this splash screen appeared to report this unknown error.  ( I have a
picture but my finger is hiding the proof itself!)

I do not know a lot about computer but I have a 20/20 vision.  I tried to
read everything so I could understand howto fix it ... then I saw my own
PASSWORD after the autopart --encrypted --passphrase (as described)

You would need to provide me guidance .. however, this is the best I can
do.  Are you able to create a "full usbstick" like mine with this type of
partition (Iso9660) ?? Perhaps if you try to do as I did, you will have the
same result and this would be 100% proof.

Sorry, my computer skills themselves are too low to be able to know where
in the code is hidden the report bug of the install in the code itself..
However, with the information I have provided .. I can tell you that I do
not have the skills to even know how the programmers themselves programmed
this report !

If you provide me with simple step and simple questions to try to recreate
what I did, I will answer them as well as I can but there is no way to
check the code for myself because even if I were to see it I would not know
what I would be looking at .. Sorry :(

I hope this is enough so you can try to "FORCE" a error and see this
MEGA-HUGE flaw with your own eyes.  This way, you would believe it without
having to rely on "untrusted" data on a qubes-users google group.

Have a nice day.  I need to get some sleep but I try to answer you if you
have any question (please explain everything if you need something too
technical from me to make your own experiment!)

p-s my sata was disabled on my 

Re: [qubes-users] Qubes OS 4.0-rc3 has been released!

[haaber]

> Current users of Qubes 4.0-rc2 can upgrade in-place by downloading the
> latest updates from the testing repositories in both
> [dom0][dom0-testing] and [TemplateVMs][domU-testing].  Further details,
> including full installation instructions, are available in the [Qubes
> 4.0 release notes][release-notes]. The new installation image is
> available on the [Downloads] page.

I read this instructions as
1) sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
   Here I can confirm the gpg-key errors Chris posted already.
2) sudo qubes-dom0-update --enablerepo=qubes-vm-fc25-current-testing  or
   sudo qubes-dom0-update --enablerepo=qubes-vm-fc26-current-testing

   these commands fail each time, for debian-8 as well. What happens?

Cheers, Bernhard

-- 
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/f0b8ea4d-edbb-7bb1-59d5-6ef1e963a713%40web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[genevieve . c . gauthier]

Sorry but I almost fainted ! (I even took a picture ! I could not believe this 
MEGA-HUGE security flaw right in front of my eyes ) 

An installation error prompt this screen : 

An unknown error has occurred
This program has encountered an unknown error. You may report the bug below or 
quit the program.  (2 buttons:1st 'Report Bug' 2nd 'Quit')

More info ...
The output below may help determine the cause of the error :
[...]
#System timezone
timezone America/New_York --isUtc
#System bootloader configuration
bootloader --location=mbr
autopart --encrypted --passphrase=X!! 
type=lvm
#Root password
rootpw --lock
#Partition clearing information
[...]

//
WHAT IS THIS ! I could SEE with my own little EYES my OWN "SECURE" PASSPHRASE 
as a STRING!!! (translated to you as XXX!) 

Do I need to repeat this?? (sorry but I even took the picture with my finger in 
front of it so I would not to store my OWN SECURE PASSPHRASE in a picture!!!

I am a dummy but not that dumb... what is this ? Is it a mistake ? Is it 
supposed to be Qubes OS Untrustable OS or ?? ... Sorry, you are supposed to be 
good and security expert but you are asking me (THE dumb USER) to report MY OWN 
PASSPHRASE AS A STRING to help you??   (Such any easy way to get access to my 
drive! & perhaps use my passphrase to guess other passwords as well...)

I believe, without being on the "receiving" side of this report bug 
process(would need this to be 100% sure) that your OWN reporting bug system is 
giving you Qubes Users PASSPHRASE as (clear)STRING in the report ... 

Your Report bug => The needed stuff &&& MY DRIVE SECURE PASSPHRASE so everyone 
can see it!?

This does not look very "secure" too me ... (sorry but lmao)

P-S there is also 'Debug' may take you to tty1 & Button "Debug" (lower right 
corner of my screen)

Have a nice day 
N.B. I will not report this bug "computer" to "computer" as my own Qubes OS 
drive would not be encrypted at all if everyone at "Qubes OS" has MY own drive 
password to (de)crypt it.  I am very glad your are an opensource software ... 
If this would have been "Windows" I might not have fainted but I might have an 
heart attack after reviewing this truly UNSECURED "Report" 

 

-- 
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/d18652f0-d300-4b92-99c0-a0ecedd93d11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Printer working with Debian DVMs but not when opening up a doc in a DVM from e.g. Work VM?

[Unman]

On Tue, Nov 28, 2017 at 09:26:04AM -0800, vel...@tutamail.com wrote:
> I am using Qubes 3.2, I have a dedicated Debian Template for my more trusted 
> VMs and a separate dedicated Debian Template for my DVMs with printer drivers 
> installed.
> 
> This is tricky but I will try to explain:
> 
> I managed to get my printer set up using a Debian Template(printed Test Page 
> fine from template).
> 
> Changed my DVM to Debian, I can print a web page and document using a 
> Dedicated Debian based DVM i.e. Q(Top left Q menu icon) -> DisposableVM...no 
> issues with printing web pages and transfered docs from here!
> 
> When I use a trusted VM(lets say my Work VM), I open a document using "Open 
> in DisposableVM", I see the printer I set up, try to print and I get an 
> error(something like "printer not connected")?
> 
> What might cause this? Any thoughts on a fix?
> 
> Thanks in advance...
> 

Can you give a little more information?
I'm assuming that this is a network printer? Please correct me if
wrong.
When you spawn a disposableVM from "work" what is that connected
to?(Check the value for dispvm_netvm from qvm-prefs)

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

AW: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

['[799]' via qubes-users]

Hello,

 Original-Nachricht 
An 29. Nov. 2017, 00:48, schrieb:
Sorry but I almost fainted ! (I even took a picture ! I could not believe this 
MEGA-HUGE security flaw right in front of my eyes )
(...)
Sorry, you are supposed to be good and security expert but you are asking me 
(THE dumb USER) to report MY OWN PASSPHRASE AS A STRING to help you??
(...)
--

Honestly I can't believe that this is true, until you prove this, which might 
be hard, as even a picture can be simple "ASCII Art".

If you are correct, this would of course mean that Qubes OS can't be trusted.
There should never be the option that a passphrase will be shown unencrypted.

Even worse including this passphrase in an error report which gets saved or 
transferred to a 3rd party (even if it the Qubes Team) is an absolute no-go.

As mentioned, I don't believe this.

Can you provide more guidance what you have done and what hardware you are 
using, so that someone can verify this problem, if it is reproducable?

Please also include all hardware specs, so that can also take this in account.

If you are right and if Qubes is Open Source the source code should be analyzed 
to find this "hidden feature".

But as mentioned, I think this is BS.

[799]

-- 
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/UhGsICECEp38obsnohZcvD2OCQ0R5-cRIk0f4GwjenEgvkHBUE5bA4HRQtXNvFNIbC5qI7p1cERgfNNAta7GYMsPZRd3K-2pcoaY5sPPZ2o%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)

[Unman]

On Tue, Nov 28, 2017 at 07:48:49PM -0500, '[799]' via qubes-users wrote:
> Hello,
> 
>  Original-Nachricht 
> An 29. Nov. 2017, 00:48, schrieb:
> Sorry but I almost fainted ! (I even took a picture ! I could not believe 
> this MEGA-HUGE security flaw right in front of my eyes )
> (...)
> Sorry, you are supposed to be good and security expert but you are asking me 
> (THE dumb USER) to report MY OWN PASSPHRASE AS A STRING to help you??
> (...)
> --
> 
> Honestly I can't believe that this is true, until you prove this, which might 
> be hard, as even a picture can be simple "ASCII Art".
> 
> If you are correct, this would of course mean that Qubes OS can't be trusted.
> There should never be the option that a passphrase will be shown unencrypted.
> 
> Even worse including this passphrase in an error report which gets saved or 
> transferred to a 3rd party (even if it the Qubes Team) is an absolute no-go.
> 
> As mentioned, I don't believe this.
> 
> Can you provide more guidance what you have done and what hardware you are 
> using, so that someone can verify this problem, if it is reproducable?
> 
> Please also include all hardware specs, so that can also take this in account.
> 
> If you are right and if Qubes is Open Source the source code should be 
> analyzed to find this "hidden feature".
> 
> But as mentioned, I think this is BS.
> 
> [799]

I don't see any grounds for this response.
It's perfectly possible that the installer (not principally written by
Qubes) could mistakenly include a passphrase string. I've seen similar
stuff included in all sorts of error reports in the past.
It doesn't mean that Qubes "can't be trusted"

Also, since this is an installation error, let's not over egg the problem
- it's not as if you're using that password anywhere else, or that you
will use the same password the next time you try to install, is 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/20171129011055.hbv4csobzomxbdxb%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: off topic - invite codes to 'riseup'

[hvotril]

Could you send me one, for privacy concerns, literature, and art things, and 
staying as much as possible gosthy? Thanks in advance, this would be great from 
you. 

-- 
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/efdca607-3065-41ad-ad9e-7009ff73a814%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS over TLS

[Unman]

On Mon, Nov 27, 2017 at 09:27:16PM +0100, CF wrote:
> Dear Users,
> 
> A few (simple) questions as I was reading about DNS servers:
> 
> 1 - Any feedback on using your own DNS server directly on your Qubes
> machine (using unbound for instance)? Is it straightforward to have your
> DNS cache persistent across reboots?
> 
> 2 - Any feedback on the DNS over TLS provided by quad 9?
> https://www.quad9.net/
> https://labs.ripe.net/Members/stephane_bortzmeyer/quad9-a-public-dns-resolver-with-security/
> 
> 3 - Are you aware of any other similar public server available? (IPV4 /
> IPV6 + DNS over TLS)
> 
> 4 - Last but not least, it is not very clear how to set up Qubes to use
> a given DNS server. Should we modify each VM? Or only the net VM? Or the
> firewall VM?
> 
> Thanks

You can, if you wish, set up a qube to provide DNS - you can either set
this on one of the proxyVMs or use a dedicated qube (in which case you
will need to manipulate iptables to allow inter-qube traffic). 
Look at https://www.qubes-os.org/doc/firewall to help with this.

To make the cache persistent, either store it in /usr/local or use the
bind-dirs facility:
https://www.qubes-os.org/doc/bind-dirs/

To understand the standard Qubes DNS in 3.2, note that each qube has in
/etc/resolv.conf nameserver entries for the network segment relating to
the network relating to the  proxy to which it is connected.
If you examine the iptables rules in the proxy you will see that the NAT
table contains a chain which effectively redirects DNS traffic upstream,
using the same .1 and .254 addresses.
At sys-net, the iptables rules redirect to the external DNS server(s)

If you want to use a particular server, change the iptables DNAT rules in
sys-net - you can do this from /rw/config/rc.local - again look at the
docs of the firewall.
OR if you want just SOME qubes to use a different DNS server, make
changes to the PR-QBS chain in the proxy to redirect DNS traffic to the chosen
server.
You can see that ALL of the methods proposed in your final question will
work: which you choose will depend on how many qubes you want to use
the given DNS server.

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