Re: [gentoo-dev] repo/gentoo.git, or how committing is challenging

[Patrick Lauer]

On 12/14/2015 04:00 AM, Brian Dolbec wrote:
> On Sun, 13 Dec 2015 22:20:01 +0300
> Andrew Savchenko <bircoph@g.o> 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.