But this thing needs to be installed in dom0–the steps given explain that–and of course that’s Fedora.
It appears that some step was missed in the original explanation, about having to install the key in sys-firewall (which for me is a debian-minimal based qube) as well as in dom0. Unfortunately, without that explanation, I’m pretty well hosed; it’s behaving erratically as I described above.
Note about the new thread Sven created and then merged back into this one.
(For anyone coming into this new thread, it resulted from my attempts to install the new salt-based qube generator, here: [note: I can’t find the original post now, but it was the one unman wrote detailing his first cut at automatically installing and configuring certain VMs.)
Hi @SteveC, sorry for not getting the whole context. This happens a lot lately. I too use a debian-based sys-firewall (sys-pi-hole actually, but that should be irrelevant in this context – important is that qubes-core-agent-dom0-updates is installed).
imported and moved unman’s signing key to /etc/pki/rpm-gpg/RPM-GPG-KEY-unman (I had his key already in my keyring and previously verified, so I just exported that key and moved it into dom0 – you should make sure that the key you use has the fingerprint 4B1F 400D F256 51B5 3C41 41B3 8B3F 30F9 C8C0 C2EF)
[dom0] sudo qubes-dom0-update
[dom0] qubes-task list
[dom0] qubes-task info mutt
[dom0] qubes-task install mutt
… this is where I see the same ‘NOKEY’ error you do in the terminal window of my sys-pi-hole:
Output
Unable to detect release version (use '--releasever' to specify release version)
3isec Qubes Dom0 Repository (updates) 3.3 kB/s | 2.4 kB 00:00
Fedora 32 - x86_64 - Updates 2.4 kB/s | 4.4 kB 00:01
Fedora 32 - x86_64 10 kB/s | 5.0 kB 00:00
Qubes Dom0 Repository (updates) 3.2 kB/s | 2.7 kB 00:00
Dependencies resolved.
===================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================
Installing:
3isec-qubes-mutt x86_64 1.0-1.fc32 3isec-dom0-current 11 k
Transaction Summary
===================================================================================================================
Install 1 Package
Total size: 11 k
Installed size: 8.3 k
DNF will only download packages for the transaction.
Downloading Packages:
[SKIPPED] 3isec-qubes-mutt-1.0-1.fc32.x86_64.rpm: Already downloaded
warning: /var/lib/qubes/dom0-updates/var/cache/dnf/3isec-dom0-current-42d3c1bc016485fd/packages/3isec-qubes-mutt-1.0-1.fc32.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 4731b36c: NOKEY
3isec Qubes Dom0 Repository (updates) 3.7 MB/s | 3.8 kB 00:00
Importing GPG key 0xC8C0C2EF:
Userid : "unman (Qubes OS signing key) <unman@thirdeyesecurity.org>"
Fingerprint: 4B1F 400D F256 51B5 3C41 41B3 8B3F 30F9 C8C0 C2EF
From : /var/lib/qubes/dom0-updates/etc/pki/rpm-gpg/RPM-GPG-KEY-unman
Key imported successfully
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
'/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm' failed with exit code 1!
Fetching updates failed with code 1; press Enter to exit
@unman the way I understand this error message is that the package 3isec-qubes-mutt-1.0-1.fc32.x86_64.rpm is signed with key 4731b36c which is different from your signing key ending in c8c0c2ef. Correct?
Note about the undone split
I see now that @SteveC’s post and this follow-up do belong into the original thread so I will undo the split.
Thanks for re-merging; I felt a lot of context got lost in the split.
Actually what I need are instructions for installing unman’s key in sys-firewall. The other part seems to work, but sys-firewall goes psychotic and loses its key directory when dom0 uses it to try to install one of the packages (which in my case is the cacher; I have no idea what “mutt” is even for).
The key get’s imported from /var/lib/qubes/dom0-updates/etc/pki/rpm-gpg/RPM-GPG-KEY-unman … Key imported successfully. The same issue is also observed by @renehojhere.
But then I searched for key 0x4731b36c using keyserver.ubuntu.com and it returns key 0xC8C0C2EF! Then I checked with my local GPG instance:
user@vault:~$ gpg --edit-key 0x4731b36c
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/8B3F30F9C8C0C2EF
created: 2016-06-25 expires: never usage: SC
trust: marginal validity: unknown
sub rsa4096/6233CD8FA59A87A8
created: 2016-06-25 expires: never usage: E
sub rsa4096/FDD1B8244731B36C
created: 2016-06-27 expired: 2022-06-30 usage: S
[ unknown] (1). unman (Qubes OS signing key) <unman@thirdeyesecurity.org
…turns out FDD1B8244731B36C is the signing key that corresponds to unman’s public key 8B3F30F9C8C0C2EF and IT IS EXPIRED! So this is my new theory: the check fails because the key is expired.
Also: a quick laugh at stuff one finds searching the web for NOKEY. …they are delicious by the way!
Calling @Demi since she has commented on this issue and is therefore likely knowledgeable on how to resolve this.
All good…but when I try to install the cacher via the fugly gui (unman’s description), a sys-firewall window pops up to display the process and it fails to install because it cannot find his key file on sys-firewall
It’s not complaining the key is expired. It’s complaining that there IS NO KEY FILE.
My attempts to install the file failed, as described in Post #19; the file disappears just as sys-firewall tries to reference it.
HOW DO I PUT HIS KEY FILE ON SYS FIREWALL???
This is the third time I’ve asked this, and I’m starting to feel like people are ignoring the important part of my issue. The expired key throws warning messages, THIS causes total failure of the install.
Well, I at least got a NEW error message. Not sure why, but here’s what I did:
I did a straight copy-paste of the file given here: https://qubes.3isec.org/tasks.html and also of the file given here: https://github.com/unman/unman (they are slightly different in whitespace and the order of the last two lines). I pasted into text files, copied to dom0, moved them into that directory, and tried the import. I also verified by eye they are the same key. (4B1F … C2EF)
Either version of it gives me the following message when I attempt the import:
error: /etc/pki/rpm-gpg/RPM-GPG-KEY-unman: key 1 not an armored public key.
At this point I realized that the files at /etc/pki/rpm-gpg are all 1-2K in size…except for yours, and that these things I copied and pasted are not the actual keys.
OK,so after all that, I finally went to keyserver.ubuntu.com, which shows me nine links (with no clue which is the right one) plus one green thing that looks like a link but isnt.
Trying the top one I get sent to a page with a “Public Key Block” which I then have to copy-paste (it doesn’t just “download”), then send to dom0, copy to that directory, and import…and IT imported without complaint.
Talk about a totally anti-intuitive process.
Anyhow, it’s now installing the cacher…and the scriptlet is still running after about 5 minutes. I hope that’s normal. (It appears to be starting and stopping all of my templates.)
unman, this is such a great idea! I was planning to write a big post about how to set up split-gpg, Mullvad Qubes, passing Signal Messenger through the firewall (aforementioned Mullvad VM), and a NAS-syncing qube, because these things have taken me untold hours to figure out already to finally achieve, and I know other new users will have the same trials. In fact, I still am in the process of figuring out how to set up the local NAS rsync VM and making that accessible from other qubes…so that, I suppose, is my suggestion for your script list!
I know from seeing who has replied to this post (names I see pop up all over the forums like moderators and a core team member) that some of these things may not sound difficult to many of you, but to someone who quite new to Linux and is slowly getting their computer to fully work correctly in Qubes (still can’t get my darn wifi card to work) whilst simultaneously figuring out how to appropriately use the OS itself in my spare time, this is really encouraging to see. Thanks for your insight and willingness to help everyone get through some of the tough stuff.
No. The cacher presents as a proxy on port 8082. Your apt or dnf clients in your linux templates are preconfigured (by the Qubes OS project) to use those proxies. That’s why they work even if there is no netvm assigned to the template (which is the default). Windows is oblivious to this.
That alone doesn’t fix it for me. Still getting the NOKEY error. I am now downloading stock fedora-36 and debian-11 and will create ‘sys-firewalls’ from them and set them as updatevm to see if that makes a difference.
Well, it DID try to connect itself to windows templates.
I had a string of them, that I had kept as intermediate steps during install. It was on my “to do” list to back them up and delete them, except for the last one on which the actual AppVM is based…but I forgot. So it installed itself on about ten templates, two of which wouldn’t shut down again even after several hours. I had to kill them to let the script finish.
I asked, because I figured it was probably a bug. Now I’m sure it is; the installer shouldn’t try to do that.
Unfortunately, I don’t know how, from the command line, to tell a template is a windows template (there’s no tag or pref or feature I am aware of); so it’s possible the install script can’t, either.
That’s interesting…it actually DID finally work for me…once I fixed a typo in a file name and downloaded the KEY, not the little text file with the key’s hash. (And of course, minus it installling itself uselessly on windows templates.)
However, I was installing the cacher proxy and you were installing mutt, so that could make a huge difference.
@unman You asked for requests and since the thread is actually called “Simple set-up of new qubes and software”, then I’d like to have a qube (app-vm) with android in it. specifically, I’m looking for an isolated Android environment to run inside it apps I need but don’t want on my phone".
Also, there’s a thread called “Qubes OS Installer options wishlist” where you can find lots of ideas for things that can actually be done right after Qubes-OS is up and running and not necessarily as part of the actual installer. I remind you that even for installing a minimal-appvm the end-user need to “write things in Dom0” which for some is as scary as any other thing not involving a re-assuring GUI (fugly or not).
ps. I appreciate your intentions and results - looking promising
Thanks unman for this great contrib. Although I already manually created such qubes but based on Whonix (since somehow my videos are playing better there than in other flavor-based qubes), I tried your package and it turned out that media qube is based on debian 11, not debian-11-minimal, although I have both templates already installed prior to this. Is that intentional?
.
