On Sun, 13 Dec 2015 22:20:01 +0300 Andrew Savchenko wrote: > Hi, > > On Sun, 13 Dec 2015 18:36:51 +0100 Patrick Lauer wrote: > > Oh hey. We're in the future. Let's try to commit something to > > repo/gentoo.git! > > > > So apparently we're signing things with gpg now, so let's read the > > official documentation. > > The [1] wiki seems to be the canonical location for such things. ... > > Since signing is mandatory since the git migration, ahem, this means > > that no one in the last 5 months(!) actually followed the > > documentation (because that does NOT work!). I'm almost impressed, > > but, wow, this is enterprisey. > > It is absolutely possible to create correct gpg key, put it into > LDAP according to GLEP and to sign commits and pushes properly. > What is not currently possible is to verify all tree automatically. > > I agree that gkeys needs more work. But we are all volunteers here. > You may help them if you are that interested into this > functionality. > > What worries me more that we still have no way for rsync users to > verify the portage tree (or Gentoo tree in the newspeak someone > prefers here). And most users use rsync. > > > So, what can we do to make this whole story of 'commit (and push) to > > repo/gentoo.git' make sense? And why do I appear to be the only one > > to notice this chain of breakage?! > > We need to complete gkeys project, right? That's not all of the > story, but a start. So send patches :) As for the full story, we > still need to somehow verify rsync tree. For now only snapshots are > verified. > > Best regards, > Andrew Savchenko Thank you Andrew. Let me first say, that while I am leading the gentoo-keys project. I have not been doing much with making progress to get another release out. My time is mostly taken up by full time work, add some health issues (not serious), plus with coding full time now (it was just a hobby before). I am finding it difficult to switch codebases to keep development going in a non work project. There is a certain amount of time needed to get back into the code to make any significant progress. But, one of the biggest things keeping me from doing more work on it when I do have some time, is the fact that barely any of the devs seem to care (other than the OP, who just seems to bitch about everything not working for him). Since the GLEP 63 spec has been approved. Barely any of the gentoo developers have even tried to update their gpg key or generate a new one that does meet the spec. For that reason, I have not endeavored to get more done in it. I've been trying to keep the gentoo-devs seed file reasonably up to date, but since there are few devs actually fixing or generating new keys, it is not needed that often. In fact weeks go by before there is a change in LDAP in regards to gpg keys. As Andrew pointed out in another reply, there is a fairly decent document about generating new gpg keys either directly using gpg or using gkeys-gen (gkeys-gen-9999) has the most troublesome bugs fixed in it btw). But lets get back to the OP's gpg keys. dolsen@vulture /var/lib/gkeys $ gkeys spec-check -C gentoo-devs -n patrick Checking keys... patrick, Patrick Lauer: 0x10F17899A28441CC, 0xA8447784E52864CE ============================================== ---------- Fingerprint......: 0A0901B8F018D5D6A4A31A4410F17899A28441CC Key type ........: PUB Capabilities.: sc Algorithm........: Pass Bit Length...: Fail Create Date......: Pass Expire Date..: Pass Key Version......: Pass Validity.....: e, Expired Days till expiry.: 0 Capability.......: Pass Qualified ID.....: Fail <== '@gentoo.org' user id not found This primary key.: Fail ---------- Fingerprint......: 043F1AB5B35382E666BDBEA4058F9332F0BAE0B1 Key type ........: SUB Capabilities.: e Algorithm........: ---- Bit Length...: ---- Create Date......: Pass Expire Date..: Pass Key Version......: Pass Validity.....: e, Expired Days till expiry.: 0 Capability.......: Pass Qualified ID.....: Fail <== '@gentoo.org' user id not found This subkey......: Fail Key summary primary..........: Fail signing subkey: Fail encryption subkey: No authentication subkey: No SPEC requirements: Fail ---------- Fingerprint......: F941D86BAA0D851BFE411493A8447784E52864CE Key type ........: PUB Capabilities.: scaESCA Algorithm........: Pass Bit Length...: Fail Create Date......: Pass Expire Date..: Fail Key Version......: Pass Validity.....: -, Unknown Days till expiry.: infinite <== Exceeds specification Capability.......: Pass Qualified ID.....: Pass This primary key.: Fail ---------- Fingerprint......: 8FE9C051CD0859ED2E03274104711EEBFBF3D64A Key type ........: SUB Capabilities.: e encrypt Algorithm........: ---- Bit Length...: ---- Create Date......: Pass Expire Date..: Fail Key Version......: Pass Validity.....: -, Unknown Days till expiry.: infinite <== Exceeds specification Capability.......: Pass Qualified ID.....: Pass This subkey......: Fail Key summary primary..........: Fail signing subkey: Fail encryption subkey: Yes authentication subkey: No SPEC requirements: Fail No signing capable subkey: Patrick Lauer : 0A0901B8F018D5D6A4A31A4410F17899A28441CC Patrick Lauer : F941D86BAA0D851BFE411493A8447784E52864CE No Encryption capable subkey (Notice only): Patrick Lauer : 0A0901B8F018D5D6A4A31A4410F17899A28441CC Incorrect bit length: Patrick Lauer : 0A0901B8F018D5D6A4A31A4410F17899A28441CC Patrick Lauer : F941D86BAA0D851BFE411493A8447784E52864CE Expiry keys: Patrick Lauer : 8FE9C051CD0859ED2E03274104711EEBFBF3D64A Patrick Lauer : F941D86BAA0D851BFE411493A8447784E52864CE Failed to pass SPEC requirements: Patrick Lauer : 0A0901B8F018D5D6A4A31A4410F17899A28441CC Patrick Lauer : F941D86BAA0D851BFE411493A8447784E52864CE Gkey task results: Found Failures: ------- Revoked................: 0 Invalid................: 0 No Signing subkey......: 2 No Encryption subkey...: 1 Algorithm..............: 0 Bit length.............: 2 Expiry.................: 2 Expiry Warnings........: 0 SPEC requirements......: 2 ============================= SPEC Approved..........: 0 dolsen@vulture /var/lib/gkeys $ Like so many of the dev's gpg keys, they can not ever meet the new spec because the bit length of the keys are unsatisfactory and proven to be crackable. Of which, both of his 2 registered (in LDAP) gpg keys are still the insecure type. At least his first one is now expired, but he has not attempted to remove it from LDAP, hmm... Since he has in the past generated gpg keys on 2 separate occasions, You would think he should be able to generate a new gpg key that does meet the GLEP 63 spec. But we have not seen any change in gpg keys nor had requests for help. Just complaints. I'm sorry, but I'm not volunteering my time to things in Gentoo just because I want to please someone that lately just seems to bitch and moan about things not being a single button or keypress fixable for him. We have offered help to devs many times in the past, but few have taken us up on it and fixed or generated a new gpg key. It has been my contention these past few months that the only way to get devs to fix their gpg keys or generate new ones will be to enforce GLEP 63 approved gpg keys for commit access. I know, that will almost completely stall out progress in the gentoo tree for a while. But it seems that is the only way many people will get off their ass and finally do something about it. As for gkeys integration into portage to be able to verify the manifests. It was not difficult, I had preliminary code working in it in just a few days for both portage and pkgcore. It would use gkeys to do the verification since it controlled the gpg key directories and keyrings. Both Zac and Tim said the tie ins should be done a little differently, but I still had code that did the job. I have a gpg wrapper script that git can be configured to use instead of gpg directly. That way it can use the gkeys keyring system. GPG still does the verification work, gkeys just controls the keyrings it sees) One of the things preventing it from mainstream was properly wrapping only the verify, but re-spawn ggp to do any signing (signed commits) without interference from any of gkeys. I believe I have that done now, but it has not been through enough testing to go into a release. It is very close I think. So volunteers please emerge gkeys-9999 and test the gkeys-gpg script and libs. I need to finish up a few more re-writes of a few more maintenance actions to follow the rest of the code changes Pavlos did as part of his GSOC project work. It should then be ready for another release. There have been some changes in the newest versions of gpg that I have been coming across. I am updating pyGPG to handle them as I discover them. So if anyone testing the live version find one, please report it with the traceback so we can update the code for it. Sorry in advance for spouting off some, but I found Patrick's original post in this thread quite offensive. After all a first release of gkeys-0.1 of a new developing code base had some bugs once tested on a wider machine and user base. Oh my, that has never happened before in the history of computing!!!! Patrick, I think it's time you put up or shut up. Bringing up shortcomings or other things that need attention is useful, but your near constant bitching is quite tiresome. You could start by fixing your own gpg key situation. If you don't find adequate documentation to do it, then create a some that does meets your satisfaction. -- Brian Dolbec