On 12/14/2015 04:00 AM, Brian Dolbec wrote: > On Sun, 13 Dec 2015 22:20:01 +0300 > Andrew Savchenko <birc...@gentoo.org> 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 <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC > Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE > > > No Encryption capable subkey (Notice only): > Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC > > > Incorrect bit length: > Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC > Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE > > > Expiry keys: > Patrick Lauer <patrick>: 8FE9C051CD0859ED2E03274104711EEBFBF3D64A > Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE > > > Failed to pass SPEC requirements: > Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC > Patrick Lauer <patrick>: 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. > > Ok then.
Why. WHYYYY Why does the official documentation point me at gkeys-gen, which doesn't work On a wiki that's horribly broken gkeys-gen, which has known showstopper-bugs for a year Like seriously, every time I try to approach this set of problems I run into enough stupidity that it takes me about a week until I even want to try again. Yes of course I could read a few different bits of documentation and make educated guesses. But why do we have documentation then when it's not adequate, and why do we have a helper tool when it doesn't work? ... and now I walk away for another week, in the hope that things maybe are saner then. Just to find even more bugs, I expect, but no one uses the documentation anyway, so it doesn't matter, and why am I even bothering to reply to this insanity.
