From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] repo/gentoo.git, or how committing is challenging
Date: Mon, 14 Dec 2015 12:12:15 +0100 [thread overview]
Message-ID: <566EA40F.5090806@gentoo.org> (raw)
In-Reply-To: <20151213190045.1e186781.dolsen@gentoo.org>
On 12/14/2015 04:00 AM, Brian Dolbec wrote:
> On Sun, 13 Dec 2015 22:20:01 +0300
> Andrew Savchenko <bircoph@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.
next prev parent reply other threads:[~2015-12-14 11:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-13 17:36 [gentoo-dev] repo/gentoo.git, or how committing is challenging Patrick Lauer
2015-12-13 17:38 ` Patrick Lauer
2015-12-13 18:50 ` Andrew Savchenko
2015-12-13 19:05 ` Patrick Lauer
2015-12-13 19:20 ` Andrew Savchenko
2015-12-13 21:30 ` Mike Gilbert
2015-12-13 21:53 ` Andrew Savchenko
2015-12-14 3:00 ` Brian Dolbec
2015-12-14 6:23 ` Daniel Campbell
2015-12-14 11:12 ` Patrick Lauer [this message]
2015-12-14 17:52 ` Mike Gilbert
2015-12-15 0:31 ` Peter Stuge
2015-12-21 3:21 ` [gentoo-dev] " Ryan Hill
2015-12-21 18:59 ` Peter Stuge
2015-12-22 0:45 ` Rich Freeman
2015-12-22 9:41 ` Patrick Lauer
2015-12-22 12:08 ` Rich Freeman
2015-12-22 12:53 ` Patrick Lauer
2015-12-22 13:14 ` Rich Freeman
2015-12-22 13:31 ` Patrick Lauer
2015-12-22 14:04 ` Rich Freeman
2015-12-22 18:21 ` Patrick Lauer
2015-12-22 23:55 ` Peter Stuge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566EA40F.5090806@gentoo.org \
--to=patrick@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox