[qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115, XSA-325, XSA-350)
On 12/17/20 12:13 AM, donoban wrote: > After upgrading I get an unbooteable system. Using a rescue pen I saw > that xen.cfg has a wrong initramfs for 5.4.832 (4.4.83 instead 5.4.83). > wOps, here is a typo. Just for clarify I mean that kernel '5.4.83-1' had initramfs '4.4.83-1'. -- 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/f72533cd-6932-a31c-909e-33350b926b39%40riseup.net. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115, XSA-325, XSA-350)
On 12/16/20 10:25 AM, Andrew David Wong wrote: > Dear Qubes Community, > > User action required > = > > Users must install the following specific packages in order to address > the issues discussed in this bulletin: > > For Qubes 4.0: > - Xen packages, version 4.8.5-28 > - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 > > For Qubes 4.1: > - Xen packages, version 4.14.0-9 > - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 > Hi, After upgrading I get an unbooteable system. Using a rescue pen I saw that xen.cfg has a wrong initramfs for 5.4.832 (4.4.83 instead 5.4.83). Could anyone check it? I saw (and maybe modified) it before rebooting but it is very rare that I introduced accidentally that change. -- 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/8188b9c0-5f68-dbe7-647f-e87fd45011ff%40riseup.net. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] VM displaying statusbar?
I'm running i3. I'd like to have in a statusbar (can be a separate one) displayed some information coming from network queries. It's generally advised against doing that in dom0, but I haven't found a way to make a VM be able to display a status bar. Is it possible? Or any other suggested ways to achieve that? -- viq -- 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/38755306306b9933efc7f50d4e37a1fcc657293c.camel%40gmail.com.
Re: [qubes-users] Installing Rofi on dom0 via contributed packages?
Le 12/16/20 à 7:42 PM, Stumpy a écrit : On 12/16/20 1:26 PM, Rusty Bird wrote: Stumpy: [bob@dom0 ~]$ sudo qubes-dom0-update qubes-rofi [...] No Match for argument qubes-rofi The package is called just "rofi": https://contrib.qubes-os.org/yum/r4.0/current/dom0/fc25/rpm/ which seems to be similar to an error i get when i try to install qubes-tunnel in a fed32 minimal template? Looks like qubes-tunnel is in Fedora 32 current-testing, but hasn't been uploaded to current yet: https://contrib.qubes-os.org/yum/r4.0/current-testing/vm/fc32/rpm/ https://contrib.qubes-os.org/yum/r4.0/current/vm/fc32/rpm/ https://github.com/QubesOS-contrib/updates-status/issues?q=tunnel+r4.0+fc32 Rusty > > Oi. That was too simple, can't belive I didnt try just "rofi" thanks for that. As for fed32/tunnel, thanks I will follow those git status for it. Much appreciated!! Fedora 32 version for qubes-tunnel is currently uploading to stable. Sorry for the delay :) Best, Frédéric -- 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/807ce67b-3459-7b8f-0a81-3189a63204ee%40qubes-os.org. OpenPGP_0x484010B5CDC576E2.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-users] Using Qubes base Salt pillar in user_salt?
Hi David, David Hobach: On 12/16/20 9:41 AM, Vasilis wrote: When using the Salt user configuration located in '/srv/user_salt' what is the best way to use the Qubes specific pillars located (for this example) in '/srv/salt/_pillar'? The below script should give you the idea how to do it: [..] Thank you very much for sharing this script. I would prefer very much to do it in a Salt way rather than symlinking directories. It seems that this is possible in Saltstack and it's mentioned in the Management stack documentation of Qubes here: https://www.qubes-os.org/doc/salt/#top-files "For each target you can write a list of state files. Each line is a path to a state file (without the .sls extension) relative to the main directory. Each / is exchanged with a ., so you can’t reference files or directories with a . in their name." Any directions on how can I include the base PATH of the pillars '/srv/salt' to the top or sls file? /srv/user_salt/custom-qubes.top: ``` user: qubes:type:template: - match: pillar - .template-prefs ``` Cheers, ~Vasilis -- PGP Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 PGP Public Key: https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF70B1D1260162 -- 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/09a304fd-5127-5167-7b53-6fc6b7c957ac%40torproject.org.
Re: [qubes-users] Installing Rofi on dom0 via contributed packages?
On 12/16/20 1:26 PM, Rusty Bird wrote: Stumpy: [bob@dom0 ~]$ sudo qubes-dom0-update qubes-rofi [...] No Match for argument qubes-rofi The package is called just "rofi": https://contrib.qubes-os.org/yum/r4.0/current/dom0/fc25/rpm/ which seems to be similar to an error i get when i try to install qubes-tunnel in a fed32 minimal template? Looks like qubes-tunnel is in Fedora 32 current-testing, but hasn't been uploaded to current yet: https://contrib.qubes-os.org/yum/r4.0/current-testing/vm/fc32/rpm/ https://contrib.qubes-os.org/yum/r4.0/current/vm/fc32/rpm/ https://github.com/QubesOS-contrib/updates-status/issues?q=tunnel+r4.0+fc32 Rusty > > Oi. That was too simple, can't belive I didnt try just "rofi" thanks for that. As for fed32/tunnel, thanks I will follow those git status for it. Much appreciated!! -- 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/4d49c381-27d4-8e30-9807-069d2e9516b3%40posteo.co.
Re: [qubes-users] Installing Rofi on dom0 via contributed packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Stumpy: > [bob@dom0 ~]$ sudo qubes-dom0-update qubes-rofi [...] > No Match for argument qubes-rofi The package is called just "rofi": https://contrib.qubes-os.org/yum/r4.0/current/dom0/fc25/rpm/ > which seems to be similar to an error i get when i try to > install qubes-tunnel in a fed32 minimal template? Looks like qubes-tunnel is in Fedora 32 current-testing, but hasn't been uploaded to current yet: https://contrib.qubes-os.org/yum/r4.0/current-testing/vm/fc32/rpm/ https://contrib.qubes-os.org/yum/r4.0/current/vm/fc32/rpm/ https://github.com/QubesOS-contrib/updates-status/issues?q=tunnel+r4.0+fc32 Rusty -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl/aUVRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0 QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv Kt/lJRAAjKIvIu+NMgL490ovupq4K4jVyluKBDBG/F+a8bUoNS85KclpJIr5fjGu kc30I95JoA8ZsziQHVVSMGNe1ByM8L2SF8kP2Sb5Oa6bY7+s+dJs1QC+ewbenbOJ ncyK5dOLdGHYX7fRPypUp3t44zOR5nGWVtVHstu6F4IrJfWzECj03gVTqQyedwiW i7xKmWx7C7/4QbL7wsgFqZ8DVX9rQ+77ms+Cp++jqEWJbomQd2DyhG6k/ihJRcl2 tJ2Qj+yLDAi8992/bxvk4GZcD+lMbKlzHu5m8vmFmvvbriTQO6OU603GAaB9sDes DHVOah51ASlezuyvWgIu53RCUTdb22gEnJyo2OjIauYo29yvGQ+9v5thYLAVqRMh Euw6miLABXxJDWQ8wESiCk0wPnfP7Fr1YKH/mt9xNxPyMGLJgJIdBWYhUF9stMYY 8dzwYsc9ZOR4lfwTecqeRZmCj1JpW3xYMqr/fkB2kiPgFixbO2sq2TgnwQl379Bv amTNXz2jlhYmXQZ7JwZMMXzmQaiaVMBeNr3mqHuUKIoQRvrErxT3LKqjJeeumr0T qTawrAKI0S6HjDT8h8yB3Q6hQkJ/eb7NCybJvSPHXlku+AzSWOGPNXCwYdx3x0ut /HCRb8S6Mw3cJ2hIGm4nw4VeRCe+F/b+eRcjgzGN1lTGC+rNNo4= =H2I9 -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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20201216182628.GA1183%40mutt.
Re: [qubes-users] lag causes dropped or repeated keys
On 12/16/20 4:07 AM, 'keyandthegate' via qubes-users wrote: When my computer is laggy key sometimes the UI will freeze for a second, and then the last key i pressed before it froze will be repeated as if it was held down the entire time (I like setting my key repeat rather low). Does this happen when a qube shuts down (e.g. a disposable qube)? I too observe sometimes a few seconds of freeze while a qube shuts down (mostly very large ones, so I think it's related to SSD and trim). Sometimes key presses are also dropped. I had a similar issue but it only happened with my USB connected keyboard and not the build-in one. It turned out that a specific USB hub created the issue and when I moved the USB keyboard to a port directly at the computer the issue went away. Yours might be a different problem, but I thought I'll mention just in case. /Sven -- public key: https://www.svensemmler.org/0x8F541FB6.asc fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6 -- 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/aa73c9f6-2770-0a28-d616-ad44298fb649%40SvenSemmler.org. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] Installing Rofi on dom0 via contributed packages?
So i tried, and think I suceeded in installing qubes-repo-contrib on dom0: [bob@dom0 ~]$ sudo qubes-dom0-update qubes-repo-contrib Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time... fedora/metalink | 6.4 kB 00:00 fedora | 4.3 kB 00:00 fedora/primary_db | 26 MB 01:41 qubes-contrib-dom0-r4.0-current | 3.0 kB 00:00 qubes-contrib-dom0-r4.0-current/primary_db | 16 kB 00:00 qubes-dom0-current/metalink | 2.7 kB 00:00 https://mirrors.phx.ms/qubes/repo/yum/r4.0/current/dom0/fc25/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: mirrors.phx.ms" Trying other mirror. qubes-dom0-current | 3.8 kB 00:00 qubes-dom0-current/primary_db | 352 kB 00:01 qubes-templates-itl/metalink| 2.7 kB 00:00 qubes-templates-itl | 3.0 kB 00:00 qubes-repo-contrib https://mirror.hackingand.coffee/qubes/repo/yum/r4.0/templates-itl/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for qubes-templates-itl Trying other mirror. qubes-templates-itl | 3.0 kB 00:00 qubes-templates-itl/primary_db | 6.9 kB 00:00 updates/metalink| 5.5 kB 00:00 updates | 4.7 kB 00:00 updates/primary_db | 12 MB 00:46 --> Running transaction check ---> Package qubes-repo-contrib.noarch 0:4.0.6-1.fc25 will be reinstalled --> Finished Dependency Resolution qubes-repo-contrib-4.0.6-1.fc25.noarch.rpm | 11 kB 00:00 Successfully verified /var/lib/qubes/dom0-updates/packages/qubes-repo-contrib-4.0.6-1.fc25.noarch.rpm Qubes OS Repository for Dom0 25 MB/s | 26 kB 00:00 Package qubes-repo-contrib-4.0.6-1.fc25.noarch is already installed, skipping. Dependencies resolved. Nothing to do. Complete! But when I then try to install rofi I get: [bob@dom0 ~]$ sudo qubes-dom0-update qubes-rofi Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time... No Match for argument qubes-rofi Nothing to download so, assuming I was typing the correct thing in dom0, I am not sure what to make of the error (which seems to be similar to an error i get when i try to install qubes-tunnel in a fed32 minimal template? Thoughts? btw, I am getting pretty much the same when i try from scratch in a dispVM [user@disp3219 ~]$ sudo dnf install qubes-repo-contrib Fedora Modular 32 - x86_64 - Updates 10 kB/s | 14 kB 00:01 Fedora 32 - x86_64 - Updates 17 kB/s | 13 kB 00:00 Fedora 32 - x86_64 - Updates1.5 MB/s | 7.4 MB 00:05 Dependencies resolved. PackageArchitecture Version Repository Size Installing: qubes-repo-contrib noarch 4.0.7-1.fc32 qubes-vm-r4.0-current 10 k Transaction Summary Install 1 Package Total download size: 10 k Installed size: 2.2 k Is this ok [y/N]: y Downloading Packages: qubes-repo-contrib-4.0.7-1.fc32.noarch.rpm 9.4 kB/s | 10 kB 00:01 Total 9.4 kB/s | 10 kB 00:01 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing: 1/1 Installing : qubes-repo-contrib-4.0.7-1.fc32.noarch
[qubes-users] Installing qubes-tunnel on fedora-32-minimal?
Firstly, I was able to get the user contrib qubes tunnel going on a fedora-32-minmal template and it was great! (great meaning so much easier than the more manual methods; though its still not clear to me if it includes a kill switch) The problem is fed31 has reached EOL so I wanted to install it on a fed32 template so I started with (actually I installed it earlier but wanted to show that it is indeed installed): bash-5.0# sudo dnf install qubes-repo-contrib Last metadata expiration check: 0:45:12 ago on Wed Dec 16 11:23:25 2020. Package qubes-repo-contrib-4.0.7-1.fc32.noarch is already installed. Dependencies resolved. Nothing to do. Complete! Then I tried to install the qubes-tunnel: bash-5.0# sudo dnf install qubes-tunnel Last metadata expiration check: 0:45:27 ago on Wed Dec 16 11:23:25 2020. No match for argument: qubes-tunnel Error: Unable to find a match: qubes-tunnel I also tried to install qubes-tunnel on the proxyvm for sh*t and giggles but that didnt work either (same error). I looked in the /user/lib/qubes dir and qubes-tunnel wasnt there which explains why I get the error: bash-5.0# sudo /usr/lib/qubes/qtunnel-setup --config sudo: /usr/lib/qubes/qtunnel-setup: command not found when i try to run it. Thoughts? -- 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/c17d34fa-40fb-92ff-2da9-e1f4719ca64c%40posteo.co.
Re: [qubes-users] Using Qubes base Salt pillar in user_salt?
On 12/16/20 9:41 AM, Vasilis wrote:
When using the Salt user configuration located in '/srv/user_salt' what is the
best way to use the Qubes specific pillars located (for this example) in
'/srv/salt/_pillar'?
The below script should give you the idea how to do it:
#!/bin/bash
#
# Run the salt configuration of _this_ folder in dom0.
#
# Assumes that you have `user_[formulas|pillar|salt]` directories in _this_
folder.
#
# NOTE: If even `sudo qubesctl top.enabled` failed for you, you can try
re-installing `qubes-mgmt-salt-* salt salt-minion`
# (first via `sudo qubes-dom0-update`, then via `sudo dnf reinstall`.
#
# Useful info:
# - initially sync all modules etc: sudo qubesctl saltutil.sync_all saltenv=user
# - to enable a state (only needed for everything not in top.sls): sudo
qubesctl top.enable tripleh.vms saltenv=user
# - to apply a state (set test=true for testing): sudo qubesctl --show-output
state.apply saltenv=user
# - list enabled states: sudo qubesctl top.enabled saltenv=user
# - local salt doc: qubesctl sys.doc | less (details for e.g. archive: qubesctl
sys.doc archive)
# - all available grains: sudo qubesctl --targets dom0 grains.items
# - show sls output after jinja: sudo qubesctl --show-output state.show_sls
vm-install.vim saltenv=user
# - Logs: /var/log/qubes/mgmt-[target-vm].log
# - Further doc:
# - https://github.com/unman/notes/tree/master/salt (also locally saved here;
he always refers to the examples/ dir)
# - https://www.qubes-os.org/doc/salt/
# - The qvm.[module] doc can be found in dom0 inside
`/srv/salt/_modules/ext_module_qvm.py`.
# (_Warning_: The `README.rst` appears outdated. --> Only the code has
current information.)
set -e -o pipefail
#error [msg]
function error {
local msg="$1"
>&2 echo "ERROR: $msg"
exit 1
}
[[ "$(whoami)" != "root" ]] && error "This script must be run as root."
#path of this directory (hopefully...)
SCRIPT_DIR="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"
#saltModSymlink [target]
function saltModSymlink {
local target="$1"
local tpath="/srv/user_salt/$target"
rm -f "$tpath"
ln -s "/srv/salt/$target" "$tpath"
}
#create user_ symlinks @/srv/ for the saltenv=user (explicitly configured by
Qubes OS)
echo "Creating user_ symlinks in /srv/..."
for file in "$SCRIPT_DIR"/* ; do
if [ -d "$file" ] && [[ "$file" == *"user_"* ]] ; then
target="/srv/${file##*/}"
#remove previous instances & update new
rm -f "$target"
ln -s "$file" "$target"
fi
done
#create module symlinks
echo "Creating Qubes module symlinks..."
saltModSymlink "_grains"
saltModSymlink "_modules"
saltModSymlink "_pillar"
saltModSymlink "_states"
saltModSymlink "_utils"
#sync modules (we just added some via the symlinks above)
#echo "Syncing modules..."
#qubesctl saltutil.sync_all saltenv=user
#call
ret=0
if [ $# -gt 0 ] ; then
echo "Calling qubesctl saltenv=user with your arguments..."$'\n'
#e.g. state.show_top is quite useful to see what state is applied where
(doesn't seem to work for anything != dom0)
qubesctl --show-output "$@" saltenv=user || ret=$?
else
echo "Using qubesctl to apply the top.sls state..."$'\n'
#state.highstate respects the top file, state.sls ignores it (just targets
anything mentioned as target)
qubesctl --show-output --all state.highstate saltenv=user || ret=$?
fi
echo ""
echo "All done."
exit $ret
--
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/ae2e7903-1219-4dfb-335c-bd59c14c010a%40hackingthe.net.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [qubes-users] ftp'ing to a computer on my LAN from an AppVM that is using a VPN proxyVM?
On 12/12/20 9:17 PM, unman wrote: On Sat, Dec 12, 2020 at 02:47:49PM -0500, Stumpy wrote: On 12/11/20 9:22 AM, unman wrote: On Fri, Dec 11, 2020 at 08:56:20AM -0500, Stumpy wrote: Is there a way to ftp to another computer on my LAN from a appvm that is using a proxyvm? I am able to ftp to other computers when I set this appvm to just use the default firewall, but sometimes I forget to set it back to use a vpn vm; but if I have the appvm using the vpn/proxy vm then I am unable to reach any of the other computers on my LAN? Please advise Yes - you need to adjust the firewall rules on the vpn qube to direct (ftp) traffic from the source ip to the local network - you could make this *highly* specific by specifying the destination in the new rule. pardon my ignorance but how would I do that? I know it would be in settings -> firewall settings but after that it gets a bit fuzzy? Well, you cant do it there, because you need to adjust the firewall rules implemented ON the vpn qube. What method are you using to set up the vpn? I used the new community vpn setup Right - but there are 2 methods outlined on that github page (if that's what you mean by community vpn) - 3 if you include "vpn on sys-net". Did you follow the "iptables and CLI scripts" section? There's an added issue that you will have to consider and that is the nature of FTP connections - when a client connects to a server, the server may create a link back to a port specified in the original connection: this is non-passive(active) ftp. If your FTP server does this then you will have to enable a route through to the client qube. The client may instead send a PASV command - then the server *may* send back a listening port number, and the client will create a link to that port. So there are 4 possibilities, and the firewall rules you need will depend on what are the capabilities of the server. Best check on that. Thanks unman, I used the Qubes OS contributed package "qubes tunnel". I am not sure about my server, is there a "standard" way to check that? (the server is running unraid, which is/was based on slackware so am hoping there might be a way to check that would work on most distros?). For the iptables and cli scripts part, would that still apply to using the "qubes tunnel" setup option? -- 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/f227bb4d-f576-8155-2683-90c1e0692b0d%40posteo.co.
Re: [qubes-users] How to login in tty
I wasn't even aware that I had an username there :D In Qubes it's always just "user" and when I log in after restarting the machine I can't remember to ever need to enter a username, just the password. User is probably already autofilled from previous logins. But it worked. I tried with the username I usually use and I could log in. Thanks! On Wednesday, December 16, 2020 at 1:28:39 PM UTC+1 Mike Keehan wrote: > On 12/16/20 12:14 PM, Günter Zöchbauer wrote: > > > > Sometimes my KDE freezes but I can switch to TTY using Ctrl-Alt-F2 > > but I wasn't able to login with user "root" and password. > > Should this be possible? > > > > No. > > The login is for your username and password that you use when logging > in to Qubes. Once logged in as your username, you can use sudo to > do root operations. > > Mike. > > -- 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/2da39a14-c88a-499b-b243-bea4316b9657n%40googlegroups.com.
Re: [qubes-users] How to login in tty
On 12/16/20 12:14 PM, Günter Zöchbauer wrote: Sometimes my KDE freezes but I can switch to TTY using Ctrl-Alt-F2 but I wasn't able to login with user "root" and password. Should this be possible? No. The login is for your username and password that you use when logging in to Qubes. Once logged in as your username, you can use sudo to do root operations. Mike. -- 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/108d67a5-dc34-b7c5-6ace-059a7ca2bfcb%40keehan.net.
[qubes-users] How to login in tty
Sometimes my KDE freezes but I can switch to TTY using Ctrl-Alt-F2 but I wasn't able to login with user "root" and password. Should this be possible? -- 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/c174bd26-a1cf-4522-8453-1ad7ddb87ba8n%40googlegroups.com.
[qubes-users] lag causes dropped or repeated keys
When my computer is laggy key sometimes the UI will freeze for a second, and then the last key i pressed before it froze will be repeated as if it was held down the entire time (I like setting my key repeat rather low). Sometimes key presses are also dropped. This is really frustrating is there any way to fix this? I haven't had this problem on other operating systems. -- 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/1E1JCLZdKZdB_YsW373JhW9tJ8ATpi4j77mosVblxPoFTv1lD386Y3uS6FuGs3FQcuZUpu33jqTmuukbEmyOncDx39RRYPzx4IMmJzmw3to%3D%40protonmail.com.
Re: [qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115,XSA-325,XSA-350)
On Wed, 16 Dec 2020, haaber wrote: > On 12/16/20 10:55 AM, 'Ilpo Järvinen' via qubes-users wrote: > > On Wed, 16 Dec 2020, haaber wrote: > > > > > Dear Andrew, > > > > > > > For Qubes 4.0: > > > > - Xen packages, version 4.8.5-28 > > > > - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 > > > > > > how do I fetch 4.19.163-1 for example? I tried > > > > > > sudo dnf install kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > > > > > but this gives "no package available". Same happens for 5.9.14-1. Also > > > > > > sudo qubes-dom0-update --action=install > > > kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > > > > > fails. What am I missing?? Thank you. > > > > The packages are likely still in security testing, not in the stable repo. > > You need the enablerepo parameter. From the original announcement: > > > > > > For updates from the security-testing repository: > > > > $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing > > right! Thank you. That brought indeed 4.19.163. But still > > sudo qubes-dom0-update --action=install > kernel-1000:5.9.14-1.qubes.x86_64 --enablerepo=qubes-dom0-security-testing > > does not work. The main question seems: how do you get the correct > package name? Since a simple "update" does not install 5.9.14 but only > 5.4.83 I have to ask for it "by hand", it seems. I think the package is called kernel-latest- not just kernel- for 5.9 kernels. -- i. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.2012161202090.10884%40whs-18.cs.helsinki.fi.
[qubes-users] Re: Qubes Canary 025
On 12/14/20 5:58 AM, Andrew David Wong wrote: Dear Qubes Community, Several users have pointed out a mistake in the canary below. "March 2020" should instead be "March 2021". This was just a typographical error. We will be fixing this and updating the signatures on the canary. Thank you. "March 2020" has now been corrected to "March 2021" in statement 5. The original canary, the website announcement, and the signatures on the canary have all been updated. Thank you. On 12/12/20 6:22 AM, Andrew David Wong wrote: Dear Qubes Community, We have published Qubes Canary 025. The text of this canary is reproduced below. Note: We have decided to make some minor formatting changes to the way Qubes Canary and Qubes Security Bulletin (QSB) numbers are printed, such as dropping the '#' symbol and using hyphens instead of spaces. This canary and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View Qubes Canary 025 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-025-2020.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past canaries: https://www.qubes-os.org/security/canaries/ ``` ---===[ Qubes Canary 025 ]===--- Statements --- The Qubes core developers who have digitally signed this file [1] state the following: 1. The date of issue of this canary is December 8, 2020. 2. There have been 62 Qubes Security Bulletins published so far. 3. The Qubes Master Signing Key fingerprint is: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494 4. No warrants have ever been served to us with regard to the Qubes OS Project (e.g. to hand out the private signing keys or to introduce backdoors). 5. We plan to publish the next of these canary statements in the first two weeks of March 2020. Special note should be taken if no new canary is published by that time or if the list of statements changes without plausible explanation. Special announcements -- None. Disclaimers and notes -- We would like to remind you that Qubes OS has been designed under the assumption that all relevant infrastructure is permanently compromised. This means that we assume NO trust in any of the servers or services which host or provide any Qubes-related data, in particular, software updates, source code repositories, and Qubes ISO downloads. This canary scheme is not infallible. Although signing the declaration makes it very difficult for a third party to produce arbitrary declarations, it does not prevent them from using force or other means, like blackmail or compromising the signers' laptops, to coerce us to produce false declarations. The news feeds quoted below (Proof of freshness) serves to demonstrate that this canary could not have been created prior to the date stated. It shows that a series of canaries was not created in advance. This declaration is merely a best effort and is provided without any guarantee or warranty. It is not legally binding in any way to anybody. None of the signers should be ever held legally responsible for any of the statements made here. Proof of freshness --- Tue, 08 Dec 2020 16:46:42 + Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss) Dangerous Accusations: German Tennis Star Alexander Zverev Faces Career Turning Point Skiing in the Pandemic: Alpine Rivalries Flare amid Resort Closures Biden's Goal of Saving the Iran Deal Just Got Harder - A Murder and an Ultimatum Heiko Maas: Germany's Foreign Minister on the Future of Trans-Atlantic Relations Generation Corona: The Pandemic Is Changing Our Children's Lives for the Worse Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml) Covid-19 Live Updates: Britain Begins Vaccinating Citizens U.K. Covid Vaccine: Side Effects, Safety, and Who Gets It First U.S. Leaves Behind Afghan Bases and a Legacy of Land Disputes Covid Infections, and Blame, Rise Along Southeast Asian Borders U.S. Imposes Sanctions on Chinese Officials Over Hong Kong Crackdown Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml) Safety data on Pfizer jab released by US Lloyd Austin: Biden picks ex-general as defence secretary The man saving monkeys in the Colombian Amazon Charlie Hebdo attack: France seeks long jail terms in Paris trial Christchurch massacre: Inquiry finds failures ahead of attack Source: Blockchain.info 000c6550025327ca735099e0c621a9ad4599a49dab41f573 Footnotes -- [1] This file should be signed in two ways: (1) via detached PGP signatures by each of the signers, distributed together with this canary in the qubes-secpack.git repo, and (2) via digital signatures on the corresponding qubes-secpack.git repo tags. [2] [2] Don't just trust the contents of this file blindly!
Re: [qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115, XSA-325,XSA-350)
On 12/16/20 10:55 AM, 'Ilpo Järvinen' via qubes-users wrote: On Wed, 16 Dec 2020, haaber wrote: Dear Andrew, For Qubes 4.0: - Xen packages, version 4.8.5-28 - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 how do I fetch 4.19.163-1 for example? I tried sudo dnf install kernel-1000:4.19.163-1.pvops.qubes.x86_64 but this gives "no package available". Same happens for 5.9.14-1. Also sudo qubes-dom0-update --action=install kernel-1000:4.19.163-1.pvops.qubes.x86_64 fails. What am I missing?? Thank you. The packages are likely still in security testing, not in the stable repo. You need the enablerepo parameter. From the original announcement: For updates from the security-testing repository: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing right! Thank you. That brought indeed 4.19.163. But still sudo qubes-dom0-update --action=install kernel-1000:5.9.14-1.qubes.x86_64 --enablerepo=qubes-dom0-security-testing does not work. The main question seems: how do you get the correct package name? Since a simple "update" does not install 5.9.14 but only 5.4.83 I have to ask for it "by hand", it seems. -- 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/3f2ce1f4-2ee9-35bc-428f-14877aba6617%40web.de.
Re: [qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115, XSA-325,XSA-350)
On Wed, 16 Dec 2020, haaber wrote: > Dera Andrew, > > > For Qubes 4.0: > > - Xen packages, version 4.8.5-28 > > - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 > > how do I fetch 4.19.163-1 for example? I tried > > sudo dnf install kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > but this gives "no package available". Same happens for 5.9.14-1. Also > > sudo qubes-dom0-update --action=install > kernel-1000:4.19.163-1.pvops.qubes.x86_64 > > fails. What am I missing?? Thank you. The packages are likely still in security testing, not in the stable repo. You need the enablerepo parameter. From the original announcement: > > For updates from the security-testing repository: > > $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing -- i. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.2012161154240.10884%40whs-18.cs.helsinki.fi.
[qubes-users] Re: QSB-063: Multiple Xen issues (XSA-115, XSA-325, XSA-350)
Dera Andrew, For Qubes 4.0: - Xen packages, version 4.8.5-28 - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 how do I fetch 4.19.163-1 for example? I tried sudo dnf install kernel-1000:4.19.163-1.pvops.qubes.x86_64 but this gives "no package available". Same happens for 5.9.14-1. Also sudo qubes-dom0-update --action=install kernel-1000:4.19.163-1.pvops.qubes.x86_64 fails. What am I missing?? Thank 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e3eec0af-ca6a-8e98-239f-857222e2a385%40web.de.
[qubes-users] XSAs released on 2020-12-15
Dear Qubes Community, The Xen Project released new Xen Security Advisories (XSAs) on 2020-12-15. The security of Qubes OS *is affected* by at least one of these XSAs. Therefore, *user action is required*. XSAs that affect the security of Qubes OS (user action required) The following XSAs *do affect* the security of Qubes OS: - XSA-115 - XSA-325 - XSA-350 Please see QSB-063 for the actions users must take in order to protect themselves, as well as further details about these XSAs: https://www.qubes-os.org/news/2020/12/16/qsb-063/ XSAs that do not affect the security of Qubes OS (no user action required) -- The following XSAs *do not affect* the security of Qubes OS, and no user action is necessary: - XSA-322 (domid reuse impractical in Qubes case) - XSA-323 (no oxenstored) - XSA-324 (DoS only) - XSA-330 (DoS only) - XSA-348 (DoS only) - XSA-349 (DoS only) - XSA-352 (no oxenstored) - XSA-353 (no oxenstored) - XSA-354 (DoS only) - XSA-356 (DoS only) - XSA-358 (DoS only) - XSA-359 (DoS only) Related links - - Qubes Security Pack (qubes-secpack): https://www.qubes-os.org/security/pack/ - Qubes Security Bulletins (QSBs): https://www.qubes-os.org/security/bulletins/ - XSA Tracker: https://www.qubes-os.org/security/xsa/ This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2020/12/16/xsas-released-on-2020-12-15/ -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -- 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/c57024df-a5fb-f4f9-1af7-b6f0105c5003%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] QSB-063: Multiple Xen issues (XSA-115, XSA-325, XSA-350)
Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) 063: Stack corruption from XSA-346 change (XSA-355). 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-063 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-063-2020.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ View the XSA Tracker: https://www.qubes-os.org/security/xsa/ ``` ---===[ Qubes Security Bulletin 063 ]===--- 2020-12-15 Multiple Xen issues (XSA-115, XSA-325, XSA-350) User action required = Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0: - Xen packages, version 4.8.5-28 - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 For Qubes 4.1: - Xen packages, version 4.14.0-9 - Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1 The packages are to be installed in dom0 via the Qube 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. Summary On 2020-12-15, the Xen Security Team published the following Xen Security Advisories (XSAs): XSA-115 [1] "xenstore watch notifications lacking permission checks" | Neither xenstore implementation does any permissions checks when | reporting a xenstore watch event. | | A guest administrator can watch the root xenstored node, which will | cause notifications for every created, modified and deleted key. | | A guest administrator can also use the special watches, which will | cause a notification every time a domain is created and destroyed. | | Data may include: | - number, type and domids of other VMs | - existence and domids of driver domains | - numbers of virtual interfaces, block devices, vcpus | - existence of virtual framebuffers and their backend style (eg, |existence of VNC service) | - Xen VM UUIDs for other domains | - timing information about domain creation and device setup | - some hints at the backend provisioning of VMs and their devices | | The watch events do not contain values stored in xenstore, only key | names. XSA-325 [2] "Xenstore: guests can disturb domain cleanup" | Xenstored and guests communicate via a shared memory page using a | specific protocol. When a guest violates this protocol, xenstored will | drop the connection to that guest. | | Unfortunately this is done by just removing the guest from xenstored's | internal management, resulting in the same actions as if the guest had | been destroyed, including sending an @releaseDomain event. | | @releaseDomain events do not say guest has been removed. All watchers | of this event must look at the states of all guests to find the guest | which has been removed. When an @releaseDomain is generated due to | domain xenstored protocol violation, As the guest is still running, so | the watchers will not react. | | Later, when the guest is actually destroyed, xenstored will no longer | have it stored in its internal data base, so no further @releaseDomain | event will be sent. This can lead to a zombie domain; memory mappings | of that guest's memory will not be removed, due to the missing | event. This zombie domain will be cleaned up only after another domain | is destroyed, as that will trigger another @releaseDomain event. | | If the device model of the guest which violated the Xenstore protocol | is running in a stub-domain, a use-after-free case could happen in | xenstored, after having removed the guest from its internal data base, | possibly resulting in a crash of xenstored. XSA-350 [3] "Use after free triggered by block frontend in Linux blkback" | The Linux kernel PV block backend expects the kernel thread handler | to reset ring->xenblkd to NULL when stopped. However, the handler may | not have time to run if the frontend quickly toggle between the states | connect and disconnect. | | As a consequence, the block backend may re-use a pointer after it was | freed. Impact === XSA-115, as described by Xen Security Team: | A guest administrator can observe non-sensitive domain and device | lifecycle events relating to other
[qubes-users] Using Qubes base Salt pillar in user_salt?
Hi, When using the Salt user configuration located in '/srv/user_salt' what is the best way to use the Qubes specific pillars located (for this example) in '/srv/salt/_pillar'? Step to reproduce my test: - Install qubes.user-dirs `qubesctl state.apply qubes.user-dirs` - Enable custom-qubes.top `qubesctl top.enable custom-qubes` - File contents /srv/user_salt/custom-qubes.top: ``` user: qubes:type:template: - match: pillar - template-prefs ``` /srv/user_salt/template-prefs.sls: ``` # -*- coding: utf-8 -*- # vim: set syntax=yaml ts=2 sw=2 sts=2 et : template-vm-preferences: qvm.prefs: - include_in_backups: False - label: black - maxmem: 1000 - netvm: sys-firewall - vcpus: 1 ``` I get the following obvious error: fedora-32: -- ID: template-vm-preferences Function: qvm.prefs Result: False Comment: State 'qvm.prefs' was not found in SLS 'template-prefs' Reason: 'qvm.prefs' is not available. Changes: Cheers, ~Vasilis -- PGP Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 PGP Public Key: https://keys.openpgp.org/vks/v1/by-fingerprint/8FD5CF5F39FC03EBB38274705FBF70B1D1260162 -- 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/795a3f4f-139b-6f48-bd4d-9e8e278dec00%40torproject.org.
[qubes-users] new xen kernel 5.xx
I have still instabilities with the xen kernels 5.x (sudden system freeze). I also have a small /boot and hold only the last 3 kernels. They are right now: vmlinuz-4.19.155-1.pvops.qubes.x86_64 vmlinuz-5.4.78-1.qubes.x86_64 vmlinuz-5.4.83-1.qubes.x86_64 I would like to mark the (for me very stable) kernel 4.19.155 as "do not erase while updating" and remove the (for me) useless kernel vmlinuz-5.4.78-1.qubes.x86_64. How can I do that, please? I fear to make a mess when just "playing around". I also want to keep 5.x kernels for appVM's (they work well). Thank 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c453cf15-c69f-8b5f-f7c6-64ce6742e588%40web.de.
