Signing key apt package not accepted and instructions unclear
einwickler opened this issue · 2 comments
TL;DR:
The information regarding the signing key for the apt package is inconsistent/incorrect/outdated (and there is a key mismatch too?).
DISCLAIMER:
Please excuse me if any of what I'm stating is incorrect and due to user error. This is definitely not an area I have too much knowledge of. In fact the last hour was the first time actually trying to get some understanding how the signing mechanism in debian packages is working (thanks for the lesson lol), so please excuse me if I state obvious things like a know-it-all. And lastly I hope collecting these things in one issue is okay.
Problems:
The installation instructions for Debian/Ubuntu in the README differ from the instructions in the main documentation
The instructions in README.md tell you to use apt-key but apt screams at you that it's deprecated if you still use it.
I guess the instructions from the main documentation is more up-to-date here?
The installation instructions in the documentation uses the wrong format
The documentation tells you to import the key from the debian keyring with gpg -a --export --keyring /usr/share/keyrings/debian-maintainers.gpg kpcyrd@archlinux.org | sudo tee /etc/apt/trusted.gpg.d/apt-vulns-sexy.gpg The -a tells gpg to create ASCII armored output but it's getting redirected to a file with .gpg extension. The DEPRECATION section of the apt-key manpage finally gave the hint here:
Make sure to use the "asc" extension for ASCII armored keys and the "gpg" extension for the binary OpenPGP format (also known as "GPG key public ring"). The binary OpenPGP format works for all apt versions, while the ASCII armored format works for apt version >= 1.4."
If you use the correct format, you still get an invalid signature
If you import the key from the debian keyring as stated above an apt update gets you:
W: Failed to fetch http://apt.vulns.sexy/dists/stable/InRelease The following signatures were invalid: EXPKEYSIG 45A650E2638C536D kpcyrd <git@rxv.cc>
further investigation shows that a gpg -k --keyring /usr/share/keyrings/debian-maintainers.gpg git@rxv.cc gives you:
pub rsa4096 2018-10-16 [SC] [expired: 2022-10-14]
64B13F7117D6E07D661BBCE0FE763A64F5E54FD6
uid [ expired] kpcyrd <git@rxv.cc>
uid [ expired] kpcyrd <kpcyrd@archlinux.org>
so I assume this is just an old key and the debian-keyring package needs to be updated?
I was able to update from the repository after I got the new key with gpg --keyserver keyring.debian.org --recv-keys 0x45A650E2638C536D and exported it with gpg -a --export 0x45A650E2638C536D | sudo tee /etc/apt/trusted.gpg.d/apt-vulns-sexy.asc. Of course gpg --export 0x45A650E2638C536D | sudo tee /etc/apt/trusted.gpg.d/apt-vulns-sexy.gpg works too, but the binary output from tee messes with your terminal yada yada...
I hope this mess helps you in any way. Cheers!
Versions
- rustc --version: -
- cargo --version: -
- sn0int --version: v0.25.0 (or rather commit 844a40e as this is more a documentation problem?)
- uname -a: Linux XXXX 4.4.0-19041-Microsoft #2311-Microsoft Tue Nov 08 17:09:00 PST 2022 x86_64 x86_64 x86_64 GNU/Linux
Environment
- Operating System/Distro: Ubuntu 22.04.1 LTS running on WSL 1
- Installed from (source/apt/pacman/brew/docker): apt
Tbanks (and sorry for the confusing docs), I've pushed a new commit to update the install instructions: ed55944
Distributing the signing key through debian was a fun flex but ultimately not worth it. I don't think distributing keys like this was intended by debian.
If I recall correctly WSL1 has compatibility issues with seccomp so sn0int might not run correctly on your system.
Nice, thanks for the quick reply/fix!
Can be closed I guess 👍
and
Yes, it's crashing in WSL1 with:
...Error: Failed to init sandbox
Because: seccomp_load returned error