[qubes-users] AW: Idea for (resonable secure) cloud-storage usage with Qubes

2017-10-15 Thread '[799]' via qubes-users
Hello,

I'd like to add, that I know that EncFS seems to have some issues, mentioned 
here for example:
https://defuse.ca/audits/encfs.htm
While this report is from 2014 and a new version has been issued it seems that 
encfs 2.x (which should provide better security) is still on its way - if it 
will come at all.

Unfortunately encfs is the only solution which is cross-platform, if someone is 
using a Linux only environment, the encryption layer could be replaced with 
other solutions:
https://www.cryfs.org/comparison

As such the subject should not be...

"Idea for (resonable secure) cloud-storage usage with Qubes"

... but ...

"Idea for (a slightly more secure) cloud-storage usage with Qubes"

[799]

PS: sorry for Top-Posting ;-)
I have a typo in my initial post, replace my-untrusted with my-work (where I 
unmount the encfs uencrypted directory)

 Original-Nachricht 
An 15. Okt. 2017, 01:54, [799] schrieb:

> Hello,
> I thought about how to work with cloud storage under Qubes OS and I'd like to 
> share my idea with you, to provide feedback.
> I have already build a prototype that works "reasonable" well, but I am far 
> away from being a security professional, as such I'd like to hear your opion 
> about it.
> Assumptions:
> You are using cloud storage like Microsoft OneDrive and you would like to do 
> so under Qubes in a more secure way.
> Goals:
> - all files within onedrive should be encrypted
> - files should still be accessible/decryption from other Operating systems
> - decrypted data storage and cloud storage access should be separated into 
> two AppVMs
> - different AppVMs should have access to data in the cloud storage, but it's 
> impossible for an AppVM to read the data which should be read by other AppVMs 
> (meaning you have the option to create individuall encrypted directories)
> - solution should be easy to use and relying on scripts to provide good 
> automation and a good tradeoff between security and user experience.
>
> Idea:
> In order to reach the goals, the idea is to work with two AppVMs:
> 1. "Access+Transfer AppVM" this VM will access the cloud storage provider, 
> provide synchronisation and will always see encrypted data
> 2. "Storage-AppVM" this VM will receive the encrypted files from the 
> Access+Transfer AppVM and store the files. It will also work as a data-hub to 
> provide access to data to your other AppVMs which you use to manipulate the 
> data within this VM.
>
> As such we have separated:
> - Access & Transfer of data from cloud storage provider
> - Local data storage
> - Data manipulation
>
> Solution Design:
> [Access+Transfer AppVM]
> Template: fedora-25-minimal
> Additional packages:
> - OneDrive Freeclient 
> ([https://github.com/skilion/onedrive)](https://github.com/skilion/onedrive)
> - sudo dnf -y install nfsutils
> Will be configured to mount a NFS-share from the Storage AppVM and to access 
> OneDrive to synchronize the files
> Data will be downloaded and storad in the mounted NFS-Share of the Storage 
> AppVM
>
> [Storage App-VM]
> Template: fedora-25-minimal
> Additional packages:
> - sudo dnf -y nfs-utils encfs
> This machine has been setup as a NFS Server.
> The /etc/exports file and also the iptables Firewall of this AppVM has been 
> setup, so that the [Access+Transfer AppVM] kann access a certain location.
> Within this location all files ENCFS-encrypted.
> As such the Access+Transfer AppVM but also the Cloud Storage provider will 
> only see encrypted files.
> Additional AppVMs can also mount the main NFS Share/directory.
> Those AppVMs can access certain subfolders and mount them via ENCFS to get 
> the unecrypted data.
> So the ENCFS decryption are done in those AppVMs.
> You could setup various subfolders within your Onedrive directory and each 
> folder could be encrypted within the different AppVMs.
> Example:
> onedrive\photos --> NFS Share to --> my-photo-appvm
> onedrive\work --> NFS Share to --> my-work-appvm
> onedrive\media --> NFS Share to --> my multimedia-appvm
>
> Let's look at one AppVM (example my-work-appvm = 10.137.2.25 // storage-appvm 
> = 10.137.2.20)
> On sys-firewall there is a rule, so that the work-appvm can access the 
> storage-appvm:
> [user@sys-firewall ~]$ sudo iptables -I FORWARD 2 -s 10.137.2.25 -d 
> 10.137.2.20 -j ACCEPT
>
> On the storage appvm:
> [user@my-storage ~]$ sudo iptables -I INPUT 5 -i eth0 -s 10.137.2.25 -d 
> 10.137.2.20 -j ACCEPT
> The NFS Exports file:
> [...]
> # 10.137.2.15 = Access+Transfer AppVM
> /var/nfs 10.137.2.15(rw,sync,no_subtree_check)
> # 10.137.2.25 = Work AppVM
> /var/nfs/work 10.137.2.25(rw,sync,no_subtree_check)
> [...]
>
> In the Work AppVM you are mounting the NFS Share from the Storage AppVM:
> sudo mount 10.137.2.20:/var/nfs/work /mnt/onedrive-work.encfs
>
> In Order to access the files, the NFS share is encfs-mounted:
> encfs /mnt/onedrive-work.encfs ~/work
>
> the unencrypted files can be accessed in ~/work.
> If saved they will be encfs-encrypted and 

[qubes-users] Reasonably secure laptop with touchscreen and enough ram for dictation in Windows App-VM?

2017-10-15 Thread Vít Šesták
Well, I am afraid this will be a bit hard:

Touchscreen. I've a laptop with touchscreen. I was a bit curious, but I don't 
feel much of need for touchscreen, it was simply not a reason to buy the 
laptop. When trying to use touchscreen with QubesOS, I've experienced several 
issues:

* The touchscreen is technically an USB device connected to the same USB 
controller as other USB devices. This implies any other USB device could spoof 
its touches. This issue is inherent to the hardware, i.e., not something 
QubesOS can resolve. Moreover, this is AFAIK a typical implementation of 
touchscreen.
* Qubes has input proxies for mouse and keyboard. You see, touchscreen is 
missing there. There are undocumented pieces of support and it should be 
reportedly easy to make it working, but it seems nobody takes it as a priority.
* Once you get touchscreen input working, it will probably work just like a 
mouse input. As far as I know, there is no support for passing touch events to 
VMs in other way than mouse movements and clicks.

Regards,
Vít Šesták 'v6ak'

-- 
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/29318c5e-19fe-4560-8756-3315fa8bc981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-10-15 Thread Foppe de Haan
I've just tried 4.13 again, still getting the same behavior, with the mouse 
cursor becoming progressively less responsive, and mouse and kb both becoming 
unresponsive, then X crashing/dying some time after that. Looking at the 
(kernel) logs for that boot, I don't really see anything obvious by way of 
errors, warnings, etc..
So I had a look at the announced changes for 4.13, and I do see that there have 
both been some 'performance fixes' for Xen -- 
http://lkml.iu.edu/hypermail/linux/kernel/1707.0/02950.html -- and general DMA 
mapping subsystem changes -- 
https://www.phoronix.com/scan.php?page=article=linux-413-features=1 -- 
the latter may be relevant because the way in which the system becomes 
unresponsive reminds me of the behavior I've seen on Windows when the system is 
having to deal with lots of interrupt calls.
That said, since I'm otherwise useless, I'll have to leave it there, and return 
to 4.12 for now. :)

-- 
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/b61008e5-9c8f-4aca-b35f-05a4f435a330%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HOWTO - Potential fix for GUI sluggishness

2017-10-15 Thread Yethal
I reported the issue yesterday but more people browse the mailing group than 
the qubes-issues repo so I'll repost this here. Hopefully it'll help someone.

(On my PC at least) the AppVMs internally use 24hz screen refresh rate instead 
of my monitor native 60hz which caused the GUI to be very unresponsive, 
sluggish and to tear like crazy. In order to fix that:

1. Launch terminal in TemplateVM on which your AppVMs depend
2. Open /etc/X11/xorg-qubes.conf in test editor
3. Scroll to the VertRefresh parameter
4. Change 23-24 to 59-60 (or higher if your display supports it)
5. Save changes
6. Shutdown TemplateVM
7. Restart AppVMs based on that TemplateVM
8. Repeat for all other TemaplteVMs
9. Enjoy buttersmooth GUI

Github issue:
https://github.com/QubesOS/qubes-issues/issues/3175

-- 
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/98cb9192-3a34-4b3e-b528-66984bf7a970%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Ubuntu Template

2017-10-15 Thread rysiek
Dnia Saturday, October 14, 2017 11:30:16 PM CEST Unman pisze:
> It's the same error resported by OP.
> Ubuntu template build hasnt yet been updated to 4.0

Ah, so it is. Any way I can help with debugging/testing/fixing this?

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147

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


signature.asc
Description: This is a digitally signed message part.


Re: [qubes-users] No space left on device

2017-10-15 Thread Franz
On Oct 13, 2017 22:19, "Franz" <169...@gmail.com> wrote:



On Oct 13, 2017 20:56, "Franz" <169...@gmail.com> wrote:



On Oct 13, 2017 19:32, "Marek Marczykowski-Górecki" <
marma...@invisiblethingslab.com> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Oct 13, 2017 at 06:27:31PM -0300, Franz wrote:
> whonix was not working so tried to reinstall it for 3.2Qubes with this
> command
>
> $ sudo qubes-dom0-update --enablerepo=qubes-templates-community
> --action=reinstall qubes-template-whonix-ws
>
> However while it worked for whonix-gw I am getting the following error
> for whonix-ws after the long download:
>
>  qfile-agent: Fatal error: File copy: No space left on device; Last
> file: qubes-template-whonix-ws-3.0.6-201608050146.noarch.rpm (error
> type: No space left on device)
> '/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates
> /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm'
> failed with exit code 1!
>
>
> No space left on device? Running df -h on dom0 the most used item is:
>
> /dev/dm-1  82%, used 189G available 43G which should be more than
> enough for a less than 700MB download
>
> So where should I look for?

Template (and generally packages) is downloaded to
/var/lib/qubes/updates in dom0. Maybe you have something smaller mounted
there?


There I found only the following: /var/lib/qubes/updates/rpm/qub
es-template-whonix-ws-3.0.6-201...noarch.rpm

Doing
du -h
There gives 191M which is very smaller than the 43G I expected.

But the fact that some space is still available suggests that the template
was fully downloaded and I do not have to download it again. Correct?

You

may want to try --clean option, to clean cache first.


It seems --clean is an option for a command. Which command?


I understood, it is the same update command. But running it, it replies 0
files removed. So it may not help.

Is there a easy way to increase space?



I updated the template again using the --clean option, but I get the same
"no space left" error.

But the situation is even worse. Now df -h shows that even the last 43G
disappeared from /dev/dm-1. So zero available space left.

Hope there is a solution
Best
Fran


Many thanks


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZ362XAAoJENuP0xzK19csSFoH/2+mrNpp/Wkq6YprpNvPZVD2
sRmkDaVqCgFDET+ZvoUQV96W3oojZIsBm7l6jT8HLKHuVu2lwQ/KaRyF9ITMU0zt
17uzZTYzIA0Mhh16A3G4xAsX/y/VZw3jU9RWi0hfVIX6BR1da75M8Ey8g7wqAJ12
dflzBdehM4jnBC1X0HTC+EUKuPJ9xSvkbtYXjwGUTMFyOzxZv9cKjSM+br1SuCej
893a3EnMUS0OKkFqg8EhzTy5vh1PrMpL7gjmTX+6H10UyrRNc0RUhsANLwb479T6
Ghct221AoauP5MdvCti3C9I6PO50kKFdISGXtNeXcblQCq7+a8sQBigqqpkEaY8=
=4RQ9
-END PGP SIGNATURE-

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


[qubes-users] HCL - MSI C236A Workstation

2017-10-15 Thread kaken moms
Everything seems to work. Network, Display, Sleeping ++


The card has 1 TPM module, but it wasn't found (maybe I need to set it up, 
haven't tried yet).


SSD disk is Samsung EVO 960 250GB disk with M.2 interface. Blazingly fast!

-- 
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/DB5PR07MB1080A3F7A3F949DC043D5999EE4E0%40DB5PR07MB1080.eurprd07.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-MSI-MS_7998-20171015-172319.yml
Description: Qubes-HCL-MSI-MS_7998-20171015-172319.yml


Re: [qubes-users] AW: Idea for (resonable secure) cloud-storage usage with Qubes

2017-10-15 Thread David Hobach

Hi,

I think you have some misconceptions here - the main one being why 
people tend to use Qubes OS:
Segregation of data to application-specific domains, i.e. impact of a 
domain compromise is limited.


Your idea however makes your Qubes installation vulnerable to:
- Any attacks originating from that OS ("files should still be 
accessible/decryption from other Operating systems").
- Nfs-based attacks (basically all your AppVMs using nfs will be 
vulnerable to all nfs vulnerabilities - and there have been quite a few 
in the past).

- encfs based attacks which people can even find on wikipedia.

If you don't want to add another idea to the security circus, I'd 
reconsider either using Qubes OS, your other OS or your architecture. 
The invisible things blog articles should be a good point to start with.


KR
David

On 10/15/2017 11:01 AM, '[799]' via qubes-users wrote:

Hello,

I'd like to add, that I know that EncFS seems to have some issues, mentioned 
here for example:
https://defuse.ca/audits/encfs.htm
While this report is from 2014 and a new version has been issued it seems that 
encfs 2.x (which should provide better security) is still on its way - if it 
will come at all.

Unfortunately encfs is the only solution which is cross-platform, if someone is 
using a Linux only environment, the encryption layer could be replaced with 
other solutions:
https://www.cryfs.org/comparison

As such the subject should not be...

"Idea for (resonable secure) cloud-storage usage with Qubes"

... but ...

"Idea for (a slightly more secure) cloud-storage usage with Qubes"

[799]

PS: sorry for Top-Posting ;-)
I have a typo in my initial post, replace my-untrusted with my-work (where I 
unmount the encfs uencrypted directory)

 Original-Nachricht 
An 15. Okt. 2017, 01:54, [799] schrieb:


Hello,
I thought about how to work with cloud storage under Qubes OS and I'd like to 
share my idea with you, to provide feedback.
I have already build a prototype that works "reasonable" well, but I am far 
away from being a security professional, as such I'd like to hear your opion about it.
Assumptions:
You are using cloud storage like Microsoft OneDrive and you would like to do so 
under Qubes in a more secure way.
Goals:
- all files within onedrive should be encrypted
- files should still be accessible/decryption from other Operating systems
- decrypted data storage and cloud storage access should be separated into two 
AppVMs
- different AppVMs should have access to data in the cloud storage, but it's 
impossible for an AppVM to read the data which should be read by other AppVMs 
(meaning you have the option to create individuall encrypted directories)
- solution should be easy to use and relying on scripts to provide good 
automation and a good tradeoff between security and user experience.

Idea:
In order to reach the goals, the idea is to work with two AppVMs:
1. "Access+Transfer AppVM" this VM will access the cloud storage provider, 
provide synchronisation and will always see encrypted data
2. "Storage-AppVM" this VM will receive the encrypted files from the 
Access+Transfer AppVM and store the files. It will also work as a data-hub to provide 
access to data to your other AppVMs which you use to manipulate the data within this VM.

As such we have separated:
- Access & Transfer of data from cloud storage provider
- Local data storage
- Data manipulation

Solution Design:
[Access+Transfer AppVM]
Template: fedora-25-minimal
Additional packages:
- OneDrive Freeclient 
([https://github.com/skilion/onedrive)](https://github.com/skilion/onedrive)
- sudo dnf -y install nfsutils
Will be configured to mount a NFS-share from the Storage AppVM and to access 
OneDrive to synchronize the files
Data will be downloaded and storad in the mounted NFS-Share of the Storage AppVM

[Storage App-VM]
Template: fedora-25-minimal
Additional packages:
- sudo dnf -y nfs-utils encfs
This machine has been setup as a NFS Server.
The /etc/exports file and also the iptables Firewall of this AppVM has been 
setup, so that the [Access+Transfer AppVM] kann access a certain location.
Within this location all files ENCFS-encrypted.
As such the Access+Transfer AppVM but also the Cloud Storage provider will only 
see encrypted files.
Additional AppVMs can also mount the main NFS Share/directory.
Those AppVMs can access certain subfolders and mount them via ENCFS to get the 
unecrypted data.
So the ENCFS decryption are done in those AppVMs.
You could setup various subfolders within your Onedrive directory and each 
folder could be encrypted within the different AppVMs.
Example:
onedrive\photos --> NFS Share to --> my-photo-appvm
onedrive\work --> NFS Share to --> my-work-appvm
onedrive\media --> NFS Share to --> my multimedia-appvm

Let's look at one AppVM (example my-work-appvm = 10.137.2.25 // storage-appvm = 
10.137.2.20)
On sys-firewall there is a rule, so that the work-appvm can access the 
storage-appvm:
[user@sys-firewall ~]$ sudo 

AW: Re: [qubes-users] AW: Idea for (resonable secure) cloud-storage usage with Qubes

2017-10-15 Thread '[799]' via qubes-users
Hello David,

Thank you for the open feedback.

> I think you have some misconceptions here
> - the main one being why people tend to use
> Qubes OS: Segregation of data to application-
> specific domains, i.e. impact of a domain
> compromise is limited.

You are right, regarding why people use Qubes.
But depending on specific workflows there is a need to either work with cloud 
storage for collaboration or to switch the OS completely for this use case.
Think about a (cloud based or on premise) storage service which is used by 
several people.
My goal is to work 100% in Qubes and I think that splitting access of data and 
local storage offers a better security than having the data synced and stored 
in one AppVM.
And I tried to build something that makes it easier to access data from various 
VMs in an easy way (knowing that it is less secure than using qvm-copy-to-vm).
But using some scripts we can reduce the attack surface on nfs in such a way, 
that we only enable NFS/open ports when access is needed.
I can't see how this approach is less secure than using one VM for 
syncing/storing/accessing the data?

> Your idea however makes your Qubes
> installation vulnerable to: - Any attacks
> originating from that OS ("files should still be
> accessible/decryption from other Operating
> systems")

True, but wouldn't this mean that the AppVM which is working as NFS Client must 
be compromised before NFS is attacked?

> Nfs-based attacks (basically all your AppVMs
> using nfs will be vulnerable to all nfs
> vulnerabilities

NFS access to the server is allowed on a per VM basis (firewall allow per IP), 
shouldn't this be enough to reduce NFS attack surface?

> encfs based attacks which people can even
> find on wikipedia.

Yes true, it is a shame, that we still don't have a multiplatform open source 
encryption standard that could maybe also be adapted by cloud storage providers.
But as mentioned the idea could also be implemented with other encryption 
solutions like CryFS, ...

> if you don't want to add
> another idea to the security circus
> I'd reconsider either using Qubes OS, your
> other OS or your architecture.

Hmm ..., why should I abandon Qubes and use a much more less secure OS just 
because working with cloud/external storage is part of some (!) of my workflows?

Even if all VMs which I use in the described solution are compromised, I can 
still have other VMs which are fine.
So basically it's one more reason to use Qubes ;-)

[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/oZiNcfSwB33LIJmkEc-H483lwPzzbGTv-Wbwrq9BnvNnuyLKXbc1yshBcPkBf5MeimHjaCULUTr-XgLh70ZV_tMW4IJ68RG220hccF2Pqso%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: How to export (H)VMs from Qubes/Xen to VMware vSphere

2017-10-15 Thread pixel fairy
On Thursday, October 12, 2017 at 10:20:30 PM UTC-7, [799] wrote:
> Hello,
> 
> Currently I still need to run a 2nd OS to use VMware Workstation to 
> prepare/test VMs/Setup for customers.
> 
> I'd like to prepare VMs in Qubes and then migrate/export them to the 
> customers environment which are mostly based on VMware vSphere/ESXi.

have you tried running vmware on a dedicated machine and using the vmware 
workstation binary as a remote interface?

I also need nested virtualization for developing hypervisor management 
software. this is how i get around it, only with virt-manager instead of vmware.

-- 
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/7840a16f-dc56-4d96-9b04-ccec41872022%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Audio in Debian VMs just disappeared?

2017-10-15 Thread Stumpy

No one?
I still haven't figured this one out

in case the private/paste bin was causing no responses here is the 
output from VLC:

from the vlc window:
"Audio output failed:
The audio device "default" could not be used:
No such file or directory."

and from the term that I started vlc from:
VLC media player 2.2.6 Umbrella (revision 2.2.6-0-g1aae78981c)
[5e890a526938] pulse audio output error: PulseAudio server 
connection failure: Connection refused
[5e890a4410e8] core libvlc: Running vlc with the default interface. 
Use 'cvlc' to use vlc without interface.

ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4528:(_snd_config_evaluate) function 
snd_func_card_driver returned error: No such file or directory
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared 
object file: No such file or directory

ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat 
returned error: No such file or directory

ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer 
returned error: No such file or directory
ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file or 
directory

ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default
[5e890a526938] alsa audio output error: cannot open ALSA device 
"default": No such file or directory

[5e890a526938] core audio output error: module not functional
[76de94d7eaa8] core decoder error: failed to create audio output
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared 
object file: No such file or directory
[76de74001268] xcb_xv vout display error: no available XVideo 
adaptor


anyone?


On 07.10.2017 23:12, Stumpy wrote:

For some reason the audio in all my Debian VMs has stopped working?
AFAIK I haven't done anything other than regular updates. I didn't
notice until recently so I am not sure about exactly when it started.

In the audio mixer window none of the debian vms are showing up. I
tried plaing something in VLC and it gave the follwoing errors:

https://privatebin.net/?f36509f33694a053#821JIyu4z/YqpQ61qGRYFP9Bspo7DAP8HmkPJCAk9Q8=

Also,  another strange, maybe unrelated thing happened, I don' thave
nautilus in my debian VMs any more and I tried to reinstall then but
error saying I had some missing dependencies?


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


[qubes-users] Re: Qubes Network Manager "add connection" creates dialog box but all of the fields are "grayed out"

2017-10-15 Thread bdwomackgm
On Monday, October 9, 2017 at 11:32:22 PM UTC-7, bdwom...@gmail.com wrote:
> The only thing it will let me do is select headings like "General", "Wi-Fi" 
> etc but all of the fields are grayed out.  
> 
> I'm using the Qubes network manager and the default fedora VM will not start 
> so I don't know if a network manager in there will work.
> 
> The alternate linux hardware drivers were already installed.

Why make Network Manager available if it can't be configured in Dom0?  The good 
news is that you can install and run it ENTIRELY from a SD card. The bad news 
is that installation takes FOREVER and the UI looks like it "hung" and of 
course it is painfully slow.  Qubes needs A LOT of work but I think it will 
work for me, surprisingly, because I need a secure linux platform that doesn't 
REQUIRE TOR.  Tails is hard to beat and would be nice in a Qubes VM so I could 
use a Qubes browser for sites that refuse TOR but for now I can't even figure 
out how to make an ISO available to 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/deee4608-8ed9-46e0-8ddd-2352be70d635%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Signatures on the Qubes Master Signing Key

2017-10-15 Thread 'Archimedes Cohen' via qubes-users
Hi,

I was attempting to verify the Qubes iso image today, but was not
convinced of its trustworthiness, as the master signing key (or the
version I have obtained) does seem to be signed by surprisingly little
people I might trust.

In [1] it says:
"In addition, some operating systems have built-in keyrings containing
keys capable of validating the Qubes Master Signing Key. For example,
if you have a Debian system, then your debian-keyring may already
contain the necessary keys."

However, in my version of the debian keyring, there seems to be only
one key (Holger Levsen, 091AB856069AAA1C) that has signed the Qubes
Master Signing Key. This seems to be a suspiciously small number for
the claim above that the debian-keyring contains the "necessary keys"
to verify the Qubes Master Signing Key.

Also, I would expect the key to be signed by people such as Joanna,
which does not seem to be the case.

In [1] it also says:
"The point is, of course, that people must choose who they will trust
(e.g., Linus Torvalds, Microsoft, the Qubes Project, etc.) and assume
that if a given file was signed by a trusted party, then it should not
be malicious or buggy in some horrible way. But the decision of
whether to trust any given party is beyond the scope of digital
signatures. It’s more of a sociological and political decision."

In order to be able to trust the Qubes key, I would like to be able to
see signatures by people I am reasonably certain exist, are publicly
known under a certain name, and associated to certain projects, etc,
and then find paths from my key to theirs in order to verify that the
key is from who it claims. Unfortunately, I wasn't able to find such
signatures for the Qubes key. I hope there is a plausible explanation
for the lack of signatures from the debian keyring and the main Qubes
developers, or someone points out some silly mistake I made and these
signatures are in fact present (for now I am assuming that the sources
I obtained the iso and the key from are compromised). I am attaching
the list of signatures on my version of the key below [2].

Cheers

[1]: https://www.qubes-os.org/security/verifying-signatures/

[2]:
gpg --keyring /usr/share/keyrings/debian-keyring.gpg --list-sigs
DDFA1A3E36879494
pub   rsa4096 2010-04-01 [SC]
  427F11FD0FAA4B080123F01CDDFA1A3E36879494
uid   [ unknown] Qubes Master Signing Key
sig 3DDFA1A3E36879494 2010-04-01  Qubes Master Signing Key
sig  BAB94304346A5D14 2015-07-23  [User ID not found]
sig  A361949B65863FB6 2015-07-23  [User ID not found]
sig  18F4E359596BF4C5 2016-06-28  [User ID not found]
sig  98BA910BDC7CD1DE 2016-01-18  [User ID not found]
sig  E59015807B481F53 2016-10-05  [User ID not found]
sig  BEF78F80C54B1179 2016-11-09  [User ID not found]
sig  A157436DC3D9C2F5 2017-06-18  [User ID not found]
sig  96E9DEEBACA1EC6D 2017-07-08  [User ID not found]
sig  16DDD8FFAAB5B575 2016-04-07  [User ID not found]
sig  EEAC756152B70E0B 2014-05-30  [User ID not found]
sig  E2AE3676843538F4 2014-06-10  [User ID not found]
sig  2067001B1B678A63 2015-12-10  [User ID not found]
sig  8930975B0BA05E1B 2016-06-14  [User ID not found]
sig  DA4230CC10B0B381 2015-03-05  [User ID not found]
sig  77CC0BFDC4D68105 2015-10-12  [User ID not found]
sig  091AB856069AAA1C 2015-12-02  Holger Levsen 
sig  F8C0B051D67CF73E 2017-01-02  [User ID not found]
sig  84E3926ACE3A08AB 2017-02-23  [User ID not found]
sig  ACA61935CAA2A7B8 2017-04-03  [User ID not found]
sig  61D724CD1937CB57 2017-06-02  [User ID not found]
sig  5B062613F489F90F 2017-06-02  [User ID not found]
sig  1F6750FD3CBDCCE0 2012-12-08  [User ID not found]
sig  1620DC5AC6A07D9C 2014-05-24  [User ID not found]
sig  4EB460F79B747005 2016-01-30  [User ID not found]
sig  31407CC0ED45A9B5 2017-01-20  [User ID not found]
sig  29B7C7E57205BD8E 2017-04-10  [User ID not found]
sig 3295C746984AF7F0C 2015-12-11  [User ID not found]
sig 32F99F921BB77E554 2015-12-11  [User ID not found]
sig 30AF62DC0C9D6F090 2015-12-11  [User ID not found]
sig 2A876A8406F3C6AC7 2017-03-25  [User ID not found]
sig  D63F267FBD457A3B 2017-06-12  [User ID not found]
sig  626FDCC7264685B9 2017-06-12  [User ID not found]
sig 34BD7C4EEE2986940 2016-01-04  [User ID not found]
sig  2F6CDC9841891922 2017-09-20  [User ID not found]
sig  153FE398821C8394 2017-01-01  [User ID not found]

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 

Re: [qubes-users] Signatures on the Qubes Master Signing Key

2017-10-15 Thread Unman
On Mon, Oct 16, 2017 at 12:09:30AM +0200, 'Archimedes Cohen' via qubes-users 
wrote:
> Hi,
> 
> I was attempting to verify the Qubes iso image today, but was not
> convinced of its trustworthiness, as the master signing key (or the
> version I have obtained) does seem to be signed by surprisingly little
> people I might trust.
> 
> In [1] it says:
> "In addition, some operating systems have built-in keyrings containing
> keys capable of validating the Qubes Master Signing Key. For example,
> if you have a Debian system, then your debian-keyring may already
> contain the necessary keys."
> 
> However, in my version of the debian keyring, there seems to be only
> one key (Holger Levsen, 091AB856069AAA1C) that has signed the Qubes
> Master Signing Key. This seems to be a suspiciously small number for
> the claim above that the debian-keyring contains the "necessary keys"
> to verify the Qubes Master Signing Key.
> 
> Also, I would expect the key to be signed by people such as Joanna,
> which does not seem to be the case.
> 
> In [1] it also says:
> "The point is, of course, that people must choose who they will trust
> (e.g., Linus Torvalds, Microsoft, the Qubes Project, etc.) and assume
> that if a given file was signed by a trusted party, then it should not
> be malicious or buggy in some horrible way. But the decision of
> whether to trust any given party is beyond the scope of digital
> signatures. It’s more of a sociological and political decision."
> 
> In order to be able to trust the Qubes key, I would like to be able to
> see signatures by people I am reasonably certain exist, are publicly
> known under a certain name, and associated to certain projects, etc,
> and then find paths from my key to theirs in order to verify that the
> key is from who it claims. Unfortunately, I wasn't able to find such
> signatures for the Qubes key. I hope there is a plausible explanation
> for the lack of signatures from the debian keyring and the main Qubes
> developers, or someone points out some silly mistake I made and these
> signatures are in fact present (for now I am assuming that the sources
> I obtained the iso and the key from are compromised). I am attaching
> the list of signatures on my version of the key below [2].
> 
> Cheers
> 
> [1]: https://www.qubes-os.org/security/verifying-signatures/
> 

Hi Archimedes,

One reason why you wont find the key signed by "people like Joanna" is
that they are likely to be using split gpg.
It's one of the downsides of that implementation that one cant sign
other's keys without breaking the security model. (See
www.qubes-os.org/doc/split-gpg)

It isn't really clear to me why you have the constraint that you have in
order to trust the Qubes key. What do you think those people whose
signatures you would accept will have done that you aren't capable of
doing? I doubt that Holger has done anything more than run through the
processes in [1] above before signing the key. And those are processes
that you can do yourself - I'm tempted to say that you SHOULD do them
yourself. Using the WOT may be just part of that validation, and not a
necessary part.
If it helps you can see the key in the mailing list, and in various
youtube talks.

Cheers

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


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

2017-10-15 Thread Dave C
On Friday, July 28, 2017 at 7:16:36 AM UTC-7, little help wrote:
[snip...]
> 
> This also might also work: 
> 1.Go here: https://user.riseup.net/
> 
> 2.Make a "help ticket", and write "I need an invitation code because I 
> want to use(write your messages!!)".
> ^ Don't copy & paste my sentence! Use your words!
> 
> 3.Then, someone(Riseup user) will assist you.



Just FYI, I tried this and was declined with:

```
The following message has been posted in response to your question:

"Red Accounts" are needed for email, chat, VPN and the help desk. In order to 
create a Red Account you will need an invite: Find a friend that already has a 
riseup email account. After logging in to account.riseup.net your friend can 
create an invite code. You can use this invite on account.riseup.net to create 
your own account. 
Some remarks: 
- You only need one invite. 
- Newly created accounts can not be used to create invite codes. 
Due to the numerous requests by spammers and scammers that tried to get a 
riseup account we have to insist on invites for new accounts. We know that this 
sucks. We are sorry about it but it is the only thing that makes sense right 
now.
```


-- 
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/9e9d9e67-3809-47e4-b829-5fee2695f384%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.