Change key install method #1
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
anonymousmaybe on IRC has mentioned a couple times that the way we're installing the repo public key is now deprecated.
He's provided a couple links on why and what the improved method is, need to find them again. Any help appreciated.
Unclear how urgent this is and what the timeline should be for fixing this.
This i think can be considered fully implemented, Thanks guys
Fixed the MR so it handles <buster,bionic using
trusted.gpg.dinstead by checking /etc/debian_version numerically and for codenames. Everything gets created successfully and the symlink works, but I'm on sid. Going to try it on a Bionic VM.Edit: Seems to be working in the VM too.
I test Current and LTS Ubuntu's and Debian Stable and Sid, where I'm using [signed-by=] for everything now and it's been working perfectly so far. But that conveniently draws the line exactly where signed-by= is supported, so older ones will still need to use trusted.gpg.d, I can add a check in the script to handle that, no biggie.
There doesn't appear to be an "official" naming sheme for /usr/share/keyrings I could find, at least not one that anyone is using. Right now I have keys for a couple repositories in there and some of them are
.ascand some of them are.gpg. There seems to be a sort of fuzzy, broad convention that you are supposed to name it$software-$tagorqualifier-$keyring.gpglikei2p-archive-keyring.gpg. Element(the Matrix chat client), for instance, usesriot-im-archive-keyring.gpg. When we update the keyring package to use an updated key, all we have to do is replace this file, no grepping or anything.Security theater? Maybe. It doesn't change the fact that the package manager runs as ~root and the maintainer has permission to run scripts as the package manager at many phases while the package is being managed. There are many opportunities for a malicious maintainer that this doesn't fix. I could just move the keys I control as an attacker into trusted.gpg.d. So it definitely doesn't protect against a malicious maintainer. But, in a situation where the attacker can sign packages, but cannot necessarily upload them to the server, which is conceivable in a PPA scenario for instance where additional authentication measures may be in place for uploaders, I think making a key valid only for a single source may be a meaningful way of making an attack more difficult. It's may also possibly be helpful for users who use many third-party repositories if a GPG key gets compromised from one repository at the same time as the server of another repository. Maybe the scenarios it will really help in are a little contrived, but A) I don't think that's a good reason not to do it and B) it may not be possible to change apt without changing the way that current users of apt use it. This is easy, and it might help, even if the scenarios it really stands a chance in on it's own are pretty narrow and contrived.
reminder @idk you promised to bring over the rest of the mtn history into github
As you noted in the i2p.www MR, our package (maint-script) already creates the files:
KEYRING=/usr/share/keyrings/i2p-archive-keyring.gpg
REMOVED_KEYS=/usr/share/keyrings/i2p-archive-removed-keys.gpg
Nobody's really made a list of what we have to do here. All we have is pointers to forums and blog posts. This seems to be the best guide:
https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/
So this is for bionic and newer, bullseye and newer.
Todo list:
@idk claims "very straightforward" above and "pretty much ready to go" in the i2p.www MR but I don't agree. At least I don't know enough to agree yet.
If it's only since bullseye that's going to make it more complicated
https://forums.whonix.org/t/apt-repository-signing-keys-per-apt-sources-list-signed-by/12302
This hopefully can be added as well for the more understanding of the advantage for doing this step.
Set due date as a reminder, not a real due date, remains low priority
Yup, fixing it is very straightforward, it's just a matter of implementing a few tiny new recommendations. I've got the required changes as an MR over here: http://7qeve4v2chmjdqlwpa3vl7aojf3nodbku7vepnjwrsxljzqipz6a.b32.i2p/i2p-hackers/i2p.www/-/merge_requests/15 ready to merge, I was just waiting to go over it once with @anonymousmaybe.
Urgency is probably low, apt-key does continue to work as does
/etc/apt/trusted.gpg.dand a number of other old apt key management procedures.The advantage of the method prescribed by @anonymousmaybe, as far as I can tell, is that the key listed in the
/etc/apt/sources.list.d/i2p.listfiledeb [signed-by=/usr/share/keyrings/i2p-archive-keyring.asc] https://deb.i2p2.de/ sid mainsigned-by=entry is only trusted to sign packages that come fromhttps://deb.i2p2.de/which ought to be a security improvement fin some setups.CC @idk