I maintain an automated system-building process based upon the Gentoo release files. There are a few issues: (1) I would really like a solution that doesn't require manual intervention every time one of the Gentoo Release Engineering keys expires. (2) The HTML list of keys available at http://www.gentoo.org/proj/en/releng/#doc_chap5 is not really parseable, particularly when metadata is taken in to account (purpose of key, supersede-related notes, etc.). This sux because we want to use the various keys (and ONLY those various keys) to validate certain DIGESTS.asc file signatures. Unfortunately there's no easy way to script this right now since there's no way to easily extract both the key IDs (doing this with a perl regex, straightforward) and the associated metadata (have to get in to HTML parsing, PITA...). Probably others have had or will have this issue. (3) Signing the list of keys with another key (perhaps longer term?) might also be useful. Basically users requiring automation of release related cryptographic validation steps need some form of viable trust anchor from which to get the latest list of keys, knowing which is to be used for what purpose. Searching the bugs database I found the somewhat related #443880. Reproducible: Always Steps to Reproduce: 1. Get media 2. Want to figure out if it is cryptographically valid or not. Actual Results: Manual process required. (Search for key IDs, parsing of metadata, download of keys, validation of various files using specific key IDs.) Expected Results: Viable automated process available. This process MUST include 'different key for different use' support. For maximal compartmentalization (usually a good thing to be paranoid about when it comes to such areas), ideally segregating those keys on the basis of "one usage scenario per keyring". ie. Bad scenario: 0. Bad actor compromises one Gentoo release engineering key for 'usage-A'. 1. A file for 'usage-B' is signed by a bad actor with the compromised key for usage-A. 2. End user wants to verify the file, and uses something like: gpg --keyring /all-gentoo-release-engineering-keys --verify bad-actors-usage-b-file 3. User gets a positive result, even though they shouldn't have, becauase GPG by default searches the whole keyring, and it is not feasible or desirable to make scripts reference specific key IDs (for maintenance purposes) to construct a tighter validation command line. Better scenario: 0. Bad actor compromises one Gentoo release engineering key for 'usage-A'. 1. A file for 'usage-B' is signed by a bad actor using the compromised key. 2. End user wants to verify the file, and uses something like: gpg --keyring /usage-b-gentoo-release-engineering-keys --verify some-usage-b-file-signed-with-compromised-usage-a-key 3. User gets a fail result, since the keychain only includes usage b keys. FWIW, Debian-based distributions use a package-based approach to distribute their keys. See http://packages.debian.org/search?keywords=debian-archive-keyring (actually in use) and http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s7.5.3.6 (some old info). The idea, basically, is that a key signs the next key before being revoked. I am somewhat skeptical that process is as secure as having a higher-level key (separate) sign the next key and/or sign a revocation, since unless I am mistaken a compromised key at some point within the temporal chain of next-key-signing keys could provide a viable means to produce an alternate, self-replicating, compromised keychain *forever*. I guess I should raise this query with the debian people (I am not sure if the docs are even accurate vs. their current process).
(Raised with debian people via email, even though behaviour vs. docs-claimed "the key is signed with the previous archive key, so theoretically you can just build on your previous trust" or potential viability of such an attack remains uncertain.)
I's already being worked on, but I've been sidetracked to fix some other issues for some other upcoming changes in gentoo. The project git repo: http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary and https://github.com/dol-sen/pyGPG Project wiki page: http://wiki.gentoo.org/wiki/Project:Gentoo-keys pyGPG I started because I didn't like the existing python interfaces to gnupg and were limited as to what they could do. Also they were a bit dated (some old, in need of updating. Yes it is related to bug 443880. It is what started this whole secondary gentoo-keys project. I have layman in git able do gpg verification with just pyGPG. But there are other projects and tasks that also need proper gpg key management. Key management is something that layman does not do yet. That is why I am working to create gentoo-keys and the gkey lib and cli app. Along with the seed files, it will be able to keep your system updated with the correct keys. At this point, I have not come up with a firm update plan, but likely, for you a simple cron job would take care of it, or perhaps a post-sync hook to check and perform key updates.
Thanks for the detailed response and good luck with your solution, which we are waiting for at https://github.com/globalcitizen/lxc-gentoo/issues/38 and elsewhere (private company codebase). Please bear in mind that our use case (generation of an LXC guest on a third party distribution) will require a viable mechanism to obtain keys on such platforms. (Note that this means that assumptions regarding the availability of the proposed python-based gkeys utility should not be made; rather, it could be the preferred mechanism on Gentoo, and another mechanism for trusted key ID acquisition (eg. via a signed file on the Gentoo mirrors) could be provided for users on foreign distributions.) Thanks again, very glad to see this being resolved.
Quick nudge and a note to let you know that in addition to our LXC-based use case, this is also affecting the secure instantiation of Gentoo systems on Amazon EC2 cloud services, the main route for which at present is https://bitbucket.org/edowd/gentoo_bootstrap This is really somewhat urgent for anyone wanting a proper solution for both cryptographic protection and automation; increasingly required for running secure services on modern infrastructure.
Any status updates?
Sorry, I missed getting cc'd on this one. I have made some progress. but not nearly as much as I had hoped. I had a work injury that had me off with a concussion/injuries for 3 months. We also moved house after 20 years in the same place. So have been busy with all of that plus the lack of concentration for several months... The gentoo council is deliberating on a new minimum spec for developer and other gentoo keys. I have the seed file generation code nearly ready. It is working but will need some adapting for some changes that will be coming in the ldap info. I'm working on a template system for generating new keys. The git/cvs validation hooks need to be coded. I have enough verification code ready to begin setting it up for the hooks and general cli use. Any help is appreciated :) If your interested I've started a #gentoo-keys irc channel. I hope to get a bunch more done over the next few weeks.
I note this has sat for another 6 months ... can we just can the LDAP integration and keep the key generation question separate? Would would solve this bug is changing the web-presence of the Gentoo Release Engineering GPG keys to a normalized list of keys at a fixed URL. Key revocations could just be published at a second URL or lower down the same page.
The gentoo-keys project has been making significant progress, thanks to being a GSOC project this year. The LDAP integration is crucial, as it's a single source of truth for Gentoo infrastructure, and simplifies management immensely. Please have patience, the project will get done, at which point all signing information will be available via normalized means.
Thanks for the update. Actually as an LDAP single source of truth project pontificator myself, I know where you're coming from. (PS. I did learn from the #OpenLDAP people that its replication is finicky and therefore it's best to be absolutely sure your master/failover nodes are perfectly equivalent, eg. by using identical containers, otherwise use a non-builtin failover implementation such as via Corosync/Pacemaker.)
(In reply to dwfreed from comment #8) > The gentoo-keys project has been making significant progress, thanks to > being a GSOC project this year. What are the results from the GSoC project? I assume you refer to the one from 2013 [1]? Or do you refer to the proposal by Pavlos Ratis for 2014 [2], which I cannot find among the proposals for 2014 [3]? (The 2013 idea [1] links to a non-existing 2014 wiki page.) It seems this project was even accepted by Google [4], but the "weekly updates" Pavlos Ratis promised in that post were not done… [1] http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2013/Ideas/identity.gentoo.org [2] https://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/dastergon/5662278724616192 [3] http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2014/Ideas [4] http://blog.dastergon.gr/2014/06/google-summer-of-code-2014/
First, weekly updates have been done for both projects. They are mandatory to the gentoo-soc mail list, only encouraged for blog posts. You can find mails from both the 2013 and 2014 GSOC projects at gmane and other mail list archive sites. Additionally, you can find mails in the gentoo-keys mail list. And the project he was referring to was gentoo-keys from 2014. Yes, we made significant progress on it this year. We have a lot of basic functionality in the code now and are almost ready for an alpha release for some testing, feedback. We just need to finish some automation scripts and get a number of files gpg signed. Once we have a team account on a server, we will begin signing and automating the seed file generation and binary keyring, sign those and layman's repositories.xml list. With those in place we can complete, debug the code in gkeys and make the release. I am hoping to have that release out in October. And if things go well, it will get a permanent install on gentoo infra servers and become standard to have signed media, stage3's, etc.. Hopefully that will be done by years end with a regular release version of gentoo-keys. http://news.gmane.org/gmane.linux.gentoo.summer-of-code http://news.gmane.org/gmane.linux.gentoo.keys
(In reply to Brian Dolbec from comment #11) Thank you a lot for that comprehensive update!
Three more months have passed.
And app-crypt/geys-0.1 and app-crypt/gkeys-gen-0.1 and app-crypy/gentoo-keys (release media keys) are in the tree for a week now. We are experiencing numerous unicode decode errors that are almost random on some systems. It seems to be a flaw in python-2.7's handling of file object and pipes. Apparently upstream python is not going to fix. So we may have to drop py-2 support. But that comes with another problem in that python-ldap is a py-2 only lib. There are some alternatives now, so we are looking into them. We have a few more small bugs to work out and we should have -0.2 out in a week or two. (I would like it done by the weekend, but may not have the time) Developers have begun fixing and/or generating new keys, but We are going to wait for -0.2 before we push them harder. So check out -0.1, keep in mind we had to disable a few sub-commands that weren't ready and/or updated to recent changes (more minor ones anyway). There is even a wiki page to getting started with it.
Cool, thanks again for your efforts and thanks for the update!
The keys are now all in sec-keys/openpgp-keys-gentoo-release
