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.
--
Brian Dolbec <dolsen>
pgpZWBsy9zasU.pgp
Description: OpenPGP digital signature
