[qubes-users] HCL Dell Latitude 7400 (Core i5-8365U Whiskey Lake)
I recently got a Latitude 7400 from my employer, a perfect replacement for my 3rd gen X1 Carbon which died four days before the end of 2019. Looking forward to finally using Qubes with more than 8 GB of RAM. It works pretty flawlessly with Qubes R4.0.2 after making three changes: (Still have a lot of fan usage with a pretty loud fan, but that's Qubes for you.) 1. To boot the installer, you need to remove mapbs=1 and noexitboot=1 (https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-displaying-installer). 2. To get suspend to work, you need to add mem_sleep_default=deep to the kernel= line in /boot/efi/EFI/qubes/xen.cfg. Otherwise it tries to use s2idle which does not work with Xen. (cf. https://groups.google.com/forum/#!topic/qubes-users/w6Jq4j79Eeo) 3. With the 4.19 kernel, it would not complete shutdown without holding down the power button, and I also didn't get a bootsplash for the encrypted hard drive. Both of these are fixed with the 5.3.11 kernel in kernel-latest. Remember that for a machine like this there's some sort of Intel RAID thing you need to disable in the BIOS for Qubes to find the NVMe disk. Best, Daniel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPSgt5n2j6RxiZnfi%2BRWX-3Ffy86v8Sm%2ByBc3opoka-VmAkpEA%40mail.gmail.com. Qubes-HCL-Dell_Inc_-Latitude_7400-20200104-170122.yml Description: application/yaml
Re: [qubes-users] KDE problems
On 8/20/19 9:57 AM, Chris Laprise wrote: >> I'm told that the "Settings" icon in qui-domains menu is oversized. > I don't see any icons at all in qui-domains; just text. I think this has something to do with how python gets the default Gtk icon set for use in Gtk.IconTheme.get_default().load_icon(). I haven't tested this on kde but I've noticed on i3 and awesome that running "xfsettingsd && pkill xfsettingsd" is sufficient to get the icons to show in qui-domains. But I haven't dug into it to figure out what xfsettingsd is doing that sets this, and how it sets it to be persistent after killing it. I haven't been able to set anything in ~/.config/gtk-3.0/settings.ini that will get the icons to show up automatically. This also affects the icons in qui-devices for me. Best, Daniel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a690d46a-171a-f993-94b2-a697e3f4606b%40gmail.com.
Re: [qubes-users] request : add to dom0 FFmpeg libraries and codecs h264/h265/libavcodec/libfdk_aac/libmp3lame/libopus/libvpx
On Sunday, August 11, 2019 at 7:14:12 AM UTC-4, john due wrote: > How can multimedia libraries affect security? There was a much-discussed exploit a few years ago, and there are several similar ones: https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3f067002-2773-4362-bf19-0d4ed0f76446%40googlegroups.com.
[qubes-users] Re: Qubes i3 Tips & Tricks
A quick follow-up on this: First, I have a branch with i3 updated to 4.16.1 for testing: https://github.com/dmoerner/qubes-desktop-linux-i3/tree/4.16.1-colors. I believe it is now stable. (cf. https://github.com/QubesOS/qubes-issues/issues/5168) Second, a nice, lightweight redshift program for dom0 is sct: https://www.umaxx.net/dl/sct-0.4.tar.gz. This is written by a few OpenBSD developers and is so simple you can audit the C code yourself before installing it in dom0. It isn't in Fedora yet, although I will get around to pushing it eventually (https://copr.fedorainfracloud.org/coprs/dmoerner/sct/). Third, a question: Some of the icons in the domains.py and devices.py tray icons don't appear by default. They do appear if you run "xfce4-settingsd". It has something to do with populating the default icons. I haven't been able to figure out how to get it to show icons without running xfce4-settingsd. I tried some basic settings in ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini, without any luck. If anyone knows how to do this, that would be nice to hear. I prefer not to use "xfce4-settingsd" since it seems to mess up some of the i3 hotkeys. By the way, if anyone is using awesome: You might want to install i3-settings-qubes. qubes-i3-xdg-autostart is a simpler alternative to dex-autostart, and qubes-i3-sensible-terminal works great with awesome. Best, Daniel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/45e964a4-091f-4ea9-a01e-98c2cd74bbca%40googlegroups.com.
[qubes-users] Enabling a VM to move the cursor
On other distributions I enjoy using the Acme text editor (http://acme.cat-v.org/). Part of using Acme efficiently involves allowing it to move the mouse for you, e.g., to search for a term you right-click on a word, and the cursor jumps to the next instance of the word in the open file. Obviously this doesn't work on Qubes, since the gui agent doesn't let programs in VMs move the cursor. I was thinking about the best way to selectively allow a VM to move the cursor, and I thought that the easiest and most secure way to do it would probably be to wrap Acme's cursor movements up into a dummy device, and use qubes-app-linux-input-proxy to treat the VM running Acme as if it has an input device attached. Has anyone tried something like this before? Daniel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e181ea30-25d6-46a9-81dc-1e3a4205f40d%40googlegroups.com.
Re: [qubes-users] The PGP Encryption Problem
I agree with everything that Chris said. A few more thoughts: First, I think the article is probably right that PGP is not the right solution for most problems for most users, mainly because of inertia against integrating subkeys into your workflow. But qubes-gpg-split makes many features of PGP work very well for Qubes users. Second, the issue of complexity. The "Answers" section seems to suggest using seven different tools to replace PGP. And consider some of the complaints about complexity in PGP: The actual system doesn’t get simpler. There are keys and subkeys. Key IDs > and key servers and key signatures. Sign-only and encrypt-only. Multiple > “key rings”. Revocation certificates. Three different compression formats. > This is all before we get to smartcard support. > This is complexity, but complexity I use. I use keys, subkeys, sign-only and encrypt-only keys, revocation certificates, etc. In fact, it is the very complexity that lets PGP get around some of the complaints in the article. Third, the recommendation to use Signal. One complaint about encrypted PGP email is that the recipient can forward your unencrypted message to someone else. Exactly the same thing is possible in Signal! In fact, it's not trivial to construct a protocol that avoids this problem while still allowing ease of use. Fourth, the recommendation to use signify. It's definitely a well-implemented tool. But I do miss the web of trust when it comes to verifying keys. Consider this quote from the original paper: (http://www.openbsd.org/papers/bsdcan-signify.html) There are no key servers for signify. No web of trust. Just keys. The good > news is the keys are pretty small. As demonstrated. We can stick them just > about everywhere, and we do. They're on the web site, they're on twitter, > they're on the top side of CD. 56 base64 characters. You can read it out > loud over the phone in under a minute. > The newest keys are not on Twitter, as far as I can see. OpenBSD doesn't sell CDs anymore. I'd much rather read a fingerprint over the phone than 56 base64 characters. The main keys are hosted on all the mirrors, but the firmware keys are, to my knowledge, only verifiable by going to the release page: https://www.openbsd.org/65.html, or by downloading base.tgz and extracting it yourself. Of course, you can use signify and provide more ways to verify keys. But note that the simplicity of signify means this requires each user to set up their own infrastructure to do so, rather than relying on the (admittedly flawed) way that PGP provides. By the way, if people want to play with signify in Qubes, I've refreshed my copr packages of a Linux port: https://copr.fedorainfracloud.org/coprs/dmoerner/outils/ Best, Daniel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c7aa95de-8cf1-4241-ba25-6e6b30dc7965%40googlegroups.com.
Re: [qubes-users] Re: ANN: Qubes-VM-hardening v0.8.5 released
On Fri, Jul 19, 2019 at 1:21 PM Chris Laprise wrote: > > On 7/19/19 10:13 AM, Daniel Moerner wrote: > > Thank you, this is a great tool. Everything is working perfectly as far > > as I can tell. It also works with fish shell by adding .config/fish to > > $chdirs. > > > > I was thinking about what kinds of files, not present in the default > > installation but possibly added to a user's system, might need to be > > added to $chdirs and $chfiles manually. Perhaps such a list could go in > > the documentation. Some examples: > > > > 1. Any files sourced by your shell startup scripts that are in the > > persistent private volume, e.g., files that provide completion > > information for your shell but that aren't in the template. > > If you could provide a specific example, that would be great. The usual > shell sources are already included, at least the ones that get executed. An example is the popular fuzzy finder fzf. Although this is packaged in Fedora, I had a test VM where I followed the instructions to install it as a vim plugin (https://github.com/junegunn/fzf#as-vim-plugin), which creates $HOME/.fzf.bash and appends [ -f ~/.fzf.bash ] && source ~/.fzf.bash to your bashrc. If you then enable qubes-vm-hardening, although your bashrc is protected with chattr, it is sourcing another file that might be overwritten by a malicious user. (The contrast I'm drawing is that the Fedora package's completion files in /usr/share/fzf/shell are not user-writable.) I don't think this is a case that you should expect to be able to handle automatically, given that it relies on the user adding something to their own bashrc. Once qubes-vm-hardening is installed, the user will be forced to perform extra actions to edit bashrc and so hopefully will think to also chattr +i ~/.fzf.bash, etc., if needed. It would probably only be an issue when first enabling qubes-vm-hardening in an older VM, which might have some of this stuff left over. > > > > > 2. Executables installed by other package managers that don't use the > > normal paths. For example, go uses $HOME/go/bin by default; cabal uses > > $HOME/.cabal/bin. Probably not worth trying to list all of these, but > > rather just noting the risk. Of courses, users that make regular use of > > these package managers might not want to enable this kind of hardening > > for convenience reasons. > > That is interesting about language-specific environments; these appear > to be examples that don't play nicely with the host OS or shell. My > initial advice here would be to add protection for $PATH (such as > Qubes-VM-hardening) to your template early, then add these other > components afterward. In future, it may be possible to parse the $PATH > for anything > that references the private volume, then then automatically lock those > paths down. No, they really don't play nicely, and there are real worries here, as with that recent issue with rubygems and strong_password a few weeks ago. I think the user will have to handle it themselves by editing the /usr/lib/qubes/init/vm-boot-protect.sh script, depending on their workflow. (For example, go uses $GOPATH/bin, and I believe some people keep a startup file in each project directory with a custom $GOPATH for that project which they source when working on it, leading to bin directories scattered all over and a constantly changing GOPATH and PATH. I wouldn't expect any of that to be handled automatically.) > > BTW, thank you for the bug fix! I've already posted it with a note in > the Readme. The current version is now 0.8.5. No problem! Daniel -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPSgt5%3DsQZo9k4iJpTtJqbTNbrx5kNtA1EXFNwr3q1i6HMJgHQ%40mail.gmail.com.
[qubes-users] Re: ANN: Qubes-VM-hardening v0.8.4 released
Thank you, this is a great tool. Everything is working perfectly as far as I can tell. It also works with fish shell by adding .config/fish to $chdirs. I was thinking about what kinds of files, not present in the default installation but possibly added to a user's system, might need to be added to $chdirs and $chfiles manually. Perhaps such a list could go in the documentation. Some examples: 1. Any files sourced by your shell startup scripts that are in the persistent private volume, e.g., files that provide completion information for your shell but that aren't in the template. 2. Executables installed by other package managers that don't use the normal paths. For example, go uses $HOME/go/bin by default; cabal uses $HOME/.cabal/bin. Probably not worth trying to list all of these, but rather just noting the risk. Of courses, users that make regular use of these package managers might not want to enable this kind of hardening for convenience reasons. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/746d4255-ab3d-4a70-847b-690700bcbff3%40googlegroups.com.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On Wednesday, June 12, 2019 at 2:29:12 PM UTC-4, Jon deps wrote: > Hello, using the suspend function, when I awake the desktop, the usb > mouse non longer functions. > > have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start > sys-usb but it complained couldn't connect to qrexec or so and failed. > > so qvm-start sys-usb a 2nd time and then the mouse functions again This is a long-standing issue for some, resolved for some but not for others at different times. See https://github.com/QubesOS/qubes-issues/issues/4042 The situation has improved for me by getting kernel 4.19.43-1 from qubes-dom0-security-testing. You could try the new kernel. (But note that our problems might be a bit different, I never had a qrexec problem when restarting sys-usb after resume.) If you need to automate restarting of sys-usb because you can't avoid this problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to qvm-kill sys-usb before suspend to get this to work reliably. Daniel -- 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/9e6909ec-4055-416b-9db6-720f6c1363dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes4.0 on gen3 X1 looses disk on resume from suspend
Hi Jon, This is very strange. Not very helpful for you, I just want to confirm that I have run Qubes 4.0 on a gen 3 X1 without having ever run into this bug. The ACPI errors are present on almost all these Lenovo machines and don't mean anything. Daniel -- 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/dbc171d4-6ca1-4318-9489-179109803e6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installing Win7 on a Dell
On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote: > Hi, > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. I > have a Dell e7440 and it doesn't come with a Windows .iso. Before I > installed Qubes I used the Dell recovery tool to create a recovery usb disk > for Win7 to re-install the OS but I'm not sure if this is usable to install > with Qubes. > > I tried following the instructions on the Qubes website by creating a new > Qube without a template but I could not change it from PVM to HVM. Then when > I tried booting from the USB recovery disk it would load up a terminal and > then exit after 10 seconds. > > When I try to boot the recovery USB disk from the main BIOS it boots up fine. > Does anyone have any tips for installing Win7 in Qubes 4? > > Thanks, > > Glen Hi, Check out these two issues: Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592 Installing Qubes Windows Tools: https://github.com/QubesOS/qubes-issues/issues/3585 The two problems you describe in the post seem to be the following: 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work. 2. Make sure you set the video-model to cirrus for install. Best, Daniel -- 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/d9826928-1733-4ac4-ac8a-fdb6ab5fe490%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 rc4: Devices and VM tray icons disappeared
On Friday, February 16, 2018 at 6:48:22 PM UTC-5, Daniel Moerner wrote: > Hi all, > > After a recent reboot, the devices and VM tray icons no longer are appearing > on boot in Xfce. I have no idea what might have caused this. There were no > dom0 updates in the meantime. If I try to manually run them, e.g., python3 > -mqui.tray.devices, I get the following: > > ERROR:dbus.proxies.Introspect error on > org.qubes.DomainManager1:/org/qubes/DomainManager1: > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message > recipient disconnected from message bus without replying > > Followed by a backtrace, the relevant part appears to be: > File "/usr/lib/python3.5/site-packages/qui/tray/devices.py", line 22, in > >DOMAINS = qui.models.qubes.DomainManager() > > Any advice would be appreciated, since with no icons, I'm also not appearing > to get notifications for devices and VM actions. > > Best, > Daniel Interesting discovery: this problem arose as a result of setting qrexec_timeout on an arbitrary VM to a value larger than an INT32. So the moral of the story: Don't try to set qrexec_timeout too high! Daniel -- 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/1f5e2f2a-3c6f-4798-beb5-21e1d7e596d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0 rc4: Devices and VM tray icons disappeared
Hi all, After a recent reboot, the devices and VM tray icons no longer are appearing on boot in Xfce. I have no idea what might have caused this. There were no dom0 updates in the meantime. If I try to manually run them, e.g., python3 -mqui.tray.devices, I get the following: ERROR:dbus.proxies.Introspect error on org.qubes.DomainManager1:/org/qubes/DomainManager1: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying Followed by a backtrace, the relevant part appears to be: File "/usr/lib/python3.5/site-packages/qui/tray/devices.py", line 22, in DOMAINS = qui.models.qubes.DomainManager() Any advice would be appreciated, since with no icons, I'm also not appearing to get notifications for devices and VM actions. Best, Daniel -- 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/309f6c30-7df8-4065-be50-60aa36ee79ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.
On Tuesday, February 13, 2018 at 4:51:12 PM UTC-5, QUBE-A-LICIOUS wrote: > Hi there, > > I have a fresh install of Qubes 4r4. However, when I reboot and or login I > have to manually change dom0 time to UTC. > > Impact: Whonix/Tor does not work because of the incorrect time. > > Manual workaround: > 1. Get the correct UTC from a browser. > 2. Open Dom0 Terminal and update to UTC such as the following: > > sudo date --set "2018-02-13 21:30" > > 3. Shutdown Service:sys-whonix > 4. Restart a whonix domain such as Domain:anon-whonix(this restarts the > sys-whonix service that was just shutdown. > 5. Then run WhonixCheck to make sure it works. It usually does and > Whonix/Tor is functional. > > = > Qubes cannot be this bad, really. > > How can I have this Date and time correctly updated on boot up? Like it > should. > > Thanks for all your help. > NSJ Try adding the following flags to date: -s -u Best, Daniel -- 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/48e76268-ea52-445d-9d65-9598fd78dfe5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 rc4 Back-up Bug
On Thursday, February 15, 2018 at 2:46:24 AM UTC-5, sebuq wrote: > Backups via the Control Panel fail with the message unable to find the > directory. However using qvm-backup via Dom0 CLI works fine. > > Is it me, or is this bug on a list to be fixed at some point in the future? https://github.com/QubesOS/qubes-issues/issues/3594 -- 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/17cf4ddb-6cef-4d86-bec9-503cc7591d2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Can't login to VM after upgrade to fedora 26
Hi, qubes-gui-vm needs to be rebuilt against the newer version of pulseaudio. This should be fixed as of commit 4cf2d11 in qubes-gui-agent-linux, but it looks like it still needs to be built and pushed to the repositories. Fixing this is important because --allowerasing is needed for some updates from Fedora 25 to Fedora 26 because of this upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1467060. Best, Daniel -- 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/2c624deb-e849-42ef-99c3-33139f42cf86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to attach a Yubikey as a normal, extra usb keyboard only to specific AppVMs?
On Monday, August 7, 2017 at 1:06:27 PM UTC-4, miguel wrote: > Did you manage to find a solution? I have the same exact problem. USBVM sees > usb fine and pass it to AppVM without a problem but the yubikey simply doesnt > do anything inside the Appvm even the yubico personalization tool does not > detect a yubikey connected even though qvm-usb shows that the Yubikey is > properly connected and lsusb inside the VM also shows Yubico connected. Hi, I have a Yubikey 4, and I have no problems using the Yubikey with appVMs on a fresh install of Qubes R3.2, no extra configuration required. I use the following script to attach it to specific VMs, and then it works perfectly with Google Chrome: #!/bin/bash # Usage: yubi USB_DEVICE="$(qvm-usb | grep Yubikey | cut -f1)" # If no device, just exit if [ -z "$USB_DEVICE" ]; then echo "No device attached" exit fi # If no argument, then just detach. if [ $# -eq 0 ]; then echo "No argument, detaching device" qvm-usb -d "$USB_DEVICE" exit fi # If we have an argument, detach first as a precaution. qvm-usb | grep "$USB_DEVICE" | grep -q "(attached to" if [ $? -eq 0 ]; then echo "Device already attached, detaching first" qvm-usb -d "$USB_DEVICE" sleep 1 fi echo "Attaching device to $1" qvm-usb -a "$1" "$USB_DEVICE" -- 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/84e8c214-5e11-459f-a555-78e803beb470%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kicking the sudoers dead horse
On Friday, March 10, 2017 at 9:55:08 PM UTC-5, Unman wrote: > So yes, in a very real sense, it doesn't matter > to me if the qube where I collect mail, (which isn't the qube where I > read it) is compromised in some way. Hi Unman, Could you explain your setup for collecting mail in one Qube and reading it in another? I currently use Qubes for each mail account, running mutt and offlineimap, and opening links in disposable VMs. But collecting mail in one Qube and reading it in another is interesting to me. Daniel -- 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/21ad2eab-051e-43b2-afd6-5c3c0edcc34a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: SystemD sucks - qubes shouldn't use it
On Wednesday, March 8, 2017 at 8:51:06 AM UTC-5, tai...@gmx.com wrote: > I realize that it is an integral part of fedora and debian (gross), but > it is a serious security hole and qubes should consider migrating away > from it by maybe choosing another orgin distro. It would be helpful for you to make clear what exactly in that pile of links is a threat to Qubes. More generally, I think you significantly underestimate the benefits Qubes receives from integration with established distributions. These distributions have more users, more developers, better infrastructure, etc. All of this contributes to security, and the infrastructure is particularly important when it comes to trusting the distributions you use for your templates. The alternative distributions have much smaller userbases. The same holds true for systemd alternatives. How long will OpenRC, or sinit, or uinit, or the latest new proposed replacement be supported? Even if systemd has some problems, I think the benefits we get from Fedora and Debian outweigh the costs. Daniel -- 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/5dcbbd15-2974-4500-9c92-4997d9367d0d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes i3 Tips & Tricks
On Mon, Mar 6, 2017 at 11:02 PM, sm8ax1 wrote: > Thanks for this. I've used i3 on other OSes and I like it a lot. I > probably won't use it on Qubes however because of an issue that I'll > note here since it may or may not affect other users. > > In i3 it is rather difficult to control the size of a window with fine > granularity, and in particular it is very difficult to restore the exact > size a window would have been created with. This is a problem for users > of Tor Browser, because websites and exit nodes can query the browser > window's size even when you have JavaScript disabled. This makes you an > easy fingerprinting target. > > If anyone knows of any workarounds for this, perhaps forcing certain > kinds of windows to be created in floating mode and keep their original > size, please share them. You'd have to experiment with whether it keeps the windows their original size, but you can force windows to start in floating mode in .i3/config: https://faq.i3wm.org/question/61/forcing-windows-as-always-floating.1.html A line similar to: for_window [class="anon-whonix:[.]*"] floating enable Should make all windows from the anon-whonix VM float by default, although I haven't tested this. Daniel -- 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/CAPSgt5nbAWaR0EXRQvNG_Z_4tDx4ULfifZHYyNzRzgMUeQn3VA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes i3 Tips & Tricks
I've been using i3 in dom0 for about a month now, and I wanted to share a few tips and tricks (partly so I can have them in a centralized place for reference): 1. To lock the screen on suspend and resume, you need to add a systemd target in /etc/systemd/system. This has to use your username (or supposedly xss-lock, which I haven't bothered figuring out how to use). I use the following content, substituting for $USER: [Unit] Description=Lock screen on suspend [Service] User=$USER Type=forking Environment=DISPLAY=:0 ExecStart=/usr/bin/i3lock -d -c 00 [Install] WantedBy=suspend.target 2. Volume keys: Install pulseaudio-utils. Then put the following in .i3/config: bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 1 +5% bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 1 -5% bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute 1 toggle I then customize the qubes-i3status command by adding: (I know this awk/sed mixture is awful, and it's hard-coded for my system, which has two pulseaudio sinks) status_volume() { local muted=$(pactl list sinks | awk -F ' ' '/Mute/ {print $2}' | sed -s 's/ //g' -e '2q;d') if [[ $muted == 'yes' ]]; then json volume "Volume: 0%" else local volume=$(pactl list sinks | awk -F ' ' '/Volume/ {print $2}' | sed -s 's/ //g' -e '3q;d') json volume "Volume: $volume" fi } And then add a local volume variable to the main() call. I update every second. 3. A few minor tweaks to the config file: See this pull request, which has already been merged: https://github.com/QubesOS/qubes-desktop-linux-i3/pull/5 A few more personal thoughts: Personally, I change the navigation to use vim keys, and then remap horizontal split to 'b'. I also remap 'focus child' to 'c', since I find it to be a useful shortcut. Originally I disabled fullscreen, on the model of Xfce4, but I had to reenable it as part of a workaround for https://github.com/QubesOS/qubes-issues/issues/1502 I'm sure I'm missing a few things, but I wanted to share this, since I sometimes see people asking about i3, especially on IRC. Best, Daniel -- 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/33922074-d6a3-46cb-b450-2b094122d53a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Unsolicited feedback on qubes-issue #2455
On Sunday, November 27, 2016 at 10:33:05 AM UTC-5, Alex wrote: > On 11/26/2016 11:59 PM, Marek Marczykowski-Górecki wrote: > >> - Qubes-GUID crashed in one AppVM as soon as I started monodevelop > >> the first time. Cannot reproduce this problem either. Error in guid > >> log was: > > > >> ErrorHandler: BadAccess (attempt to access private resource > >> denied) Major opcode: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) > >> ResourceID: 0x254 Failed serial number: 3670 Current serial > >> number: 3671 > > > >> may be related to the fact that monodevelop shows and hides many > >> windows in rapid sequence when starting? > > > > Yes, it may be. Very similar error (#2171) was already fixed some > > time ago, but apparently not all the cases. Anyway it's rather > > problem in gui-daemon, independent of Fedora version. > Ok, this problem happened again, and always when starting monodevelop. > Now I collected more logs, and tried to fiddle a bit with qubes-guid. > > In dmesg there's nothing interesting apart from 238 repetitions of this > line just before the crash manifested with all windows from that VM > disappearing: > [ 77.469369] U2MFN_GET_MFN_FOR_PAGE: get_user_pages failed, > ret=0xfff2 I just hit this bug in sys-net using a F25 template. nm-applet silently crashed, the VM state turned yellow in Qubes VM Manager, and the log was filled with this error. -- 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/2f6d47d7-7af2-4720-9781-41f3e7cd8906%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: debian-8 template problem
On Monday, January 9, 2017 at 4:33:08 PM UTC-5, haaber wrote: > Hello, > I come back to my video-player problem. While I understand that qubes > won't ship fedora software that fedore accepts only in rpmfusion, there > seems an easy solution to my concrete problem: use the debian8 template > since they ship mplayer2 for example without trouble ... > > However, when I shut down the appVM and change its template to debian8, > I can not even open a terminal. The appvm seems to run, qubes vm manager > says, but no application is visible. When I revert it back all is > normal. Since this is a fresh install (5 days old), I probably do some > newbe error; so I appreciate some hint of yours. Thank you, Bernhard Hi, This is something that confused me at first too. When you switch the template of an appVM, the menus can't automatically update. Although Debian and Fedora both have gnome-terminal, they are actually invoked slightly differently from the menu (as you can see in ~/.local/share/applications in dom0). What you need to do is open "Add more shortcuts" for the appVM after changing the template. It will then show the new applications, including the terminal, and let you add them. Daniel -- 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/834a78c3-bbdf-4d76-91cc-64d1f8f57ef1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: compose key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/08/2017 04:14 PM, haaber wrote: > Thank you. Doing this, I have compose key in dom0, but not in any > other domain. Do I miss something? Bernhard Hi, Please remember to reply to the list as well. For me, using Left Win, this setting sets the compose key for all VMs and dom0. I'm confused that you're seeing different behavior, and not sure why that would be the case. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIwBAEBCAAaBQJYcsLBExxkbW9lcm5lckBnbWFpbC5jb20ACgkQyz0BTtfxsyqO KhAAnAic/kT/cYiXoyPhPuNX7gBdYizElx7fKabax4SlcB1nr5ASBO8EheBz7ThM AoSOYgQgbfgtJQsMfd44/b3NiI0PO8lWPKwLWEFvoU5osbPhg0EFvmqW+EAsZ/yz aeWzbzpwovAj39bicUWa1XLyaZ2bEOY5MykzULJ2P9BVNq4C25ScKmJ5BfxGc+r5 noNTeVO8+xm4KSde3GghJPmkNSygmzgX6lqk97dZcJR/kjAd6vLiEiTWClr6jehQ WvQw/7scDlJWefAEG8Hf29krxPb+Ckgy7C3uqI2igBxURWeXt4cU47Of0P6SgYGx +iR1te3teDGeDEJTXU+/wq1v/x4ioXjSi6YIpQ3Paxs0BYLmnq8eagwh7AbLrrdU iwo+L3p8QjRUjvPf9VyIGsnEdCCU+4y4Dql8WSeQbBF6xI2MxUJcI/ivHs8x+96t reL6MKbpsW9ihkmUbbT1ZIMEPBfsHwuM2gdyBibr8xzwUySKqA3qzOPDAouFxo50 8cQcK3U5e+0zIZ+VpeqZWEQvbZL8enCaJZY0SUjEJbCm6ccpMAiesRd0Y0I6Vg7C UMOix7QSENwKVpcFpY0g7GKFcCscU9TvViUvGOY1xdVgYa8yVDLqISyXCu1+rxOL uYDKNNZJzYkYGXMpUBNxRnhLKLwBgn8YThPkdOrfAJV0z84= =sUES -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/900ba17c-892f-e355-72af-63d25abba231%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: compose key
On Sunday, January 8, 2017 at 12:49:33 PM UTC-5, haaber wrote: > Hello, > > for foreign languages (accents, etc) I used to have a compose key > configured. I have no idea how to do this within qubes. Has anyone > had/solven this problem already? Thank you! Bernhard You just use the normal XFCE tools: Menu -> System Tools -> Keyboard. Then under "Layout" you can pick the compose key. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/769e6fad-9e6f-4741-b9ee-08ac6ec7f613%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 3.2 Dom0 no longer updating.
On Friday, January 6, 2017 at 7:15:14 AM UTC-5, Opal Raava wrote: > Hi all, > > Since about a week or so, I'm unable to update dom0 the way I used to. The VM > Manager will tell me there are updates available for Dom0, and when I click > 'Update VM' I see the familiar 'downloading updates' but after that the > window with the updates never appears. > > If I run qubes-dom0-update it tells me 'No updates available' > > Does this perhaps have to do with fedora23/fedora24 issues? I asked on IRC > and one person is having this issue as well. Is anybody else having this > issue? Hi, See https://github.com/QubesOS/qubes-issues/issues/2086. The packages in the testing repo fix this problem for me. Note that now that F23 EOL has occurred, updates will be much less common. Daniel -- 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/07e9e1e6-35c4-4c23-b28e-7272a36cd9f2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Fedora 23 EOL December 20; Update Your Templates!
Hi all, Just a friendly reminder that Fedora 23 End of Life is December 20.[1] You may want to make sure you've updated your templates; there is a guide in the Qubes Documentation.[2] I know I don't get to decide what people talk about, but I'd like to ask that people NOT use this thread to rehash the debate about the dom0 distribution. :) Best, Daniel [1] https://fedoramagazine.org/fedora-23-end-of-life/ [2] https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/ -- 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/ac8cfe18-866d-4611-9b75-bd038b671e20%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: TemplateVM Best-Practices?
On Wednesday, November 30, 2016 at 8:59:58 AM UTC-5, Loren Rogers wrote: > Hi all, > > Are there any recommended strategies for creating and managing > TemplateVMs for regular users? Speaking personally, I use four templates: (based on Debian 9) base: For sys-*, vault, gpg, shopping, banking, etc. office: Libreoffice, thunderbird extensions, latex. For work and personal VMs. dev: Developer tools, compilers, etc. For dev VMs. untrusted: Media software (vlc, etc.) as well as Chrome. This lets me keep the individual templates to a more manageable size and prevents me from accidentally mixing up my workflow across VMs. I would be open to using a more stripped-down base template but I'm not convinced it's worth 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/0e38e8cb-2595-4eee-9222-2990c8b8aecd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Enigmial and Splig GPG2 (previously Re: [qubes-users] Upgrading from Split GPG1 to Split GPG2?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/19/2016 06:43 AM, Andrew David Wong wrote: > Sorry, this is a known issue. Enigmail 1.9 is incompatible with > Split GPG on Debian 8: > > https://github.com/QubesOS/qubes-issues/issues/2170 > > Until this is resolved, I recommend using the Fedora template > instead. I added some comments to the issue tracker: https://github.com/QubesOS/qubes-issues/issues/2170#issuecomment-2617233 58 I can confirm that this is fixed in Debian 9. I was unable to fix it in Debian 8. It must be the case that gnome-keyring is hijacking gpg-agent independently of the contents of /etc/xdg/autostart/gnome-keyring-gpg.desktop. Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIwBAEBCAAaBQJYMIZNExxkbW9lcm5lckBnbWFpbC5jb20ACgkQyz0BTtfxsyoU yRAAi4wWlOuvW4YYQYgKe5PWhgm/66Lgc9sAnzdf57QHdKUMyLMNWEjZnWuuOsr2 LMYmd/xNtUv4+B8LZJLF0SCPNYNrFuX6utFJF/rIs7hf7mNb06P9XP4PCjpBcurh 7IH+083aVylapADJ5q8JegXullDH2tN2yKhXFKjPMGkBz/+V9T0Kg2kuVcvradf5 3VQ1jpOYnYnJfWeY74xvDTOrS/hT2zPbZma+i7vqmcL6+JHlHQny5HLqw0+a9duQ dlrLoVwSe6zx6leqUo+3IewZmd9s+uSZfl5UrUh0UDysVewvQx9qlA/UvePtLD2p ktDcmeNHyoGfW0FOXfkIwTgxiRPBYrGT3n6vpe1KDP1fp3C6ETzLseco3EidjHWh itDCMrjFYmw2Z+xOyh17pmIJZuxrwmLiP8xd8Y65zgfcCWMKzkZ45AAl9TIGPvut TJ4Fz3xZ2E5n1GxUMLal7ADgGsgDxvYaNzlKMpfVsk8ikd9+EQpUIAOrejFjyuE6 J1e0cv8Gu1QuW7/88gLt0YhdOymrgJE7L9ty8lDbgZqz7+SwRyZtCc6Vau1FmYrm RKPf6m8MwImB34xyL6EX5Ocums/+IWZVmVBPPqYApCKx4UVuikNQMQC+CRqZrtz2 jz/AVeH+3YiVHssdddjQoXdB6FojbQZ6XaTNpMIsK8acJJ0= =+FX1 -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/54d3813f-647b-8f23-b44c-2e71059e03f1%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fresh R3.2 install, no /etc/default/grub
On Tue, Nov 15, 2016 at 3:48 PM, Marek Marczykowski-Górecki < marma...@invisiblethingslab.com> wrote: > I guess you have installed the system in UEFI mode. In that case, kernel > parameters are in /boot/efi/EFI/qubes/xen.cfg. Hi Marek, Thank you for the quick response. That hint and a bit more searching helped me find this earlier discussion on the mailing list: https://groups.google.com/forum/#!msg/qubes-users/KTRlrc9vC1U/ajxXQtBPBAAJ Editing xen.cfg and then relocating the initramfs produced by dracut solved the problem. Perhaps someone with permission could add a link to that discussion to the wiki page. Thanks! Daniel -- 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/CAPSgt5n7GNcAC7-1LDWaJGVwtyhOL_zYxzNntvXmTFP%3D4Goxpg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.