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  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-) 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 : PUBCapabilities.: 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 : SUBCapabilities.: 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: Noauthentication subkey: No  
> SPEC requirements: Fail
>
>
> --
> Fingerprint..: F941D86BAA0D851BFE411493A8447784E52864CE
> Key type : PUBCapabilities.: 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.: 

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

[Mike Gilbert]

On Mon, Dec 14, 2015 at 6:12 AM, Patrick Lauer  wrote:
> Why does the official documentation point me at gkeys-gen, which doesn't
> work

The documentation you linked is a project page for the Gentoo-Keys
project. It represents one possible way to accomplish the goal of
generating a gpg key. It is not the only possible way to get the job
done.

The reference on acceptable keys is GLEP 63, which makes no mention of
gkeys. I would expect you to be able to operate gpg sufficiently well
to generate a key meeting the GLEP specification. If not, you can
always ask for help in a support channel.

>
> On a wiki that's horribly broken

Your definition of "broken" is rather skewed. You are using
non-standard browser addons which block CSS/javascript. It works
perfectly well without such addons.

Shouting loudly "this is broken" does not make it so.

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

[Mike Gilbert]

On Sun, Dec 13, 2015 at 2:20 PM, Andrew Savchenko  wrote:
>> 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.

If gkeys is as broken as Patrick describes, it might be helpful to
have step-by-step instructions for manually generating an appropriate
key. This would help new developers.

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

[Andrew Savchenko]

On Sun, 13 Dec 2015 16:30:06 -0500 Mike Gilbert wrote:
> On Sun, Dec 13, 2015 at 2:20 PM, Andrew Savchenko  wrote:
> >> 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.
> 
> If gkeys is as broken as Patrick describes, it might be helpful to
> have step-by-step instructions for manually generating an appropriate
> key. This would help new developers.

GLEP 63 already contains detailed instructions of how to do this:
https://wiki.gentoo.org/wiki/GLEP:63#Specifications_for_GnuPG_keys

New devs only have to run
$ gpg --gen-key
follow instructions from GLEP 63, and upload key using
$ gpgp --send-key $key_id


Best regards,
Andrew Savchenko


pgp0A7TsaOHNI.pgp
Description: PGP signature

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

[Patrick Lauer]

On 12/13/2015 06:36 PM, Patrick Lauer wrote:
>  So apparently we're signing things with gpg now

And a related question:

How would I actually verify the signatures in a meaningful way?

... and why is that not default then.

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

[Andrew Savchenko]

Hi,

On Sun, 13 Dec 2015 18:38:55 +0100 Patrick Lauer wrote:
> On 12/13/2015 06:36 PM, Patrick Lauer wrote:
> >  So apparently we're signing things with gpg now
> 
> And a related question:
> 
> How would I actually verify the signatures in a meaningful way?

git log --show-signature does this using GnuPG.

Of course, in order to gpg to work one have to mark dev keys as
trusted, they can be verified using ldap or several public
keyservers. LDAP is more reliable, of course, but this method works
only for devs (and probably some stuff members) having an access
here.

> ... and why is that not default then.


Best regards,
Andrew Savchenko


pgpaR8EFsY5mi.pgp
Description: PGP signature

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

[Patrick Lauer]

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.

Oh dear. The layout is VERY broken. See [2]. Which redirects to [3],
which is a duplicate of [4], which has been closed because apparently
the persons responsible don't understand how to internet.
Since this bug is only about a year old I don't expect any progress soon
- but fetching random crap from untrusted hosts is not a sane option.
Especially since there is already a webserver, which is also trusted, so
I'm confused why we're still having this conversation.

But hey, let's blindly fetch CSS from unknown, just to notice that this
'theme' needs JavaScript to display properly. Because reasons.

Why would I want to blindly execute code when reading the text of a
wiki? Because, reasons. Because, future!
Sigh. I'll just live with the breakage then.

But anyway, we find [5] the right document, and ... hit [6]. Can't
install, bug is over half a year old, so I have to consider upstream
dead. But we can easily patch the ebuild and somehow install
app-crypt/gkeys.

Well, we can install it, but won't be able to use it because [7][8] it's
TOFU. Totally Fine and Usable!
Nothing some random stabbing won't fix, eh, but now we're an hour in
just trying to get dependencies of dependencies installed.

Sigh.

Now that gkeys is out of the way, let's try to use gkeys-gen!
[9][10][11] Nope. Nope nope, you don't get to play!

So there's no way to actually *use* this software in the default config
(how was this ever released?!), and upstream has not fixed any of these
issues in almost a year. This parrot is an ex-parrot!


Let's capitulate, err, repudiate. Wait, wrong word. Recapitulate! That's
it. Let's recapitulate:

The official docs are running on an unmaintained broken platform. If you
manage to read them they are wrong. And the software to use has been
abandoned a year ago, but is still suggested as default in the docs.

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.

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?!


[1] http://wiki.gentoo.org
[2] https://bugs.gentoo.org/show_bug.cgi?id=559530
[3] https://bugs.gentoo.org/show_bug.cgi?id=547536
[4] https://bugs.gentoo.org/show_bug.cgi?id=536744
[5]
https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Generating_GLEP_63_based_OpenPGP_keys
[6] https://bugs.gentoo.org/show_bug.cgi?id=550848
[7] https://bugs.gentoo.org/show_bug.cgi?id=536338
[8] https://bugs.gentoo.org/show_bug.cgi?id=557090
[9] https://bugs.gentoo.org/show_bug.cgi?id=567768
[10] https://bugs.gentoo.org/show_bug.cgi?id=566782
[11] https://bugs.gentoo.org/show_bug.cgi?id=536316

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

[Andrew Savchenko]

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.
> 
> Oh dear. The layout is VERY broken. See [2]. Which redirects to [3],
> which is a duplicate of [4], which has been closed because apparently
> the persons responsible don't understand how to internet.
> Since this bug is only about a year old I don't expect any progress soon
> - but fetching random crap from untrusted hosts is not a sane option.
> Especially since there is already a webserver, which is also trusted, so
> I'm confused why we're still having this conversation.
> 
> But hey, let's blindly fetch CSS from unknown, just to notice that this
> 'theme' needs JavaScript to display properly. Because reasons.
> 
> Why would I want to blindly execute code when reading the text of a
> wiki? Because, reasons. Because, future!

I agree with you that wikification of the documentation brings
security risks, especially due to sourcing of not-so-trusted
resources. But anyway wiki is just docs, one can read them in any
isolation environment of choise. Of course, javascript powered L3
cache attack may extract ones git key, this kind of attack may
happen from any js-enabled site. So if someone prefers to go for
such high security levels, a physically isolated box should be used
for git purposes only — and this is what Linus does IIRC. Rackcdn
js is not an additional risk in real-life conditions IMO.

Also wiki is barely readable in the lightweigth (and rather secure
due to lack of extra functions) browsers like elinks or lynx. This
irritates me, but is still tolerable in this imperfect world.

> 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


pgpdUcOcxpXcW.pgp
Description: PGP signature

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

[Patrick Lauer]

On 12/13/2015 07:50 PM, Andrew Savchenko wrote:
> Hi,
>
> On Sun, 13 Dec 2015 18:38:55 +0100 Patrick Lauer wrote:
>> On 12/13/2015 06:36 PM, Patrick Lauer wrote:
>>>  So apparently we're signing things with gpg now
>> And a related question:
>>
>> How would I actually verify the signatures in a meaningful way?
> git log --show-signature does this using GnuPG.
That's not very automated or effective.
I'd assume 'emerge' has such functionality included ...?
>
> Of course, in order to gpg to work one have to mark dev keys as
> trusted, they can be verified using ldap or several public
> keyservers. LDAP is more reliable, of course, but this method works
> only for devs (and probably some stuff members) having an access
> here.
That's what the app-crypt/gkeys thing is for, as far as I can tell.

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

[Brian Dolbec]

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-) 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 : PUBCapabilities.: 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 : SUBCapabilities.: 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: Noauthentication subkey: No  
SPEC requirements: Fail


--
Fingerprint..: F941D86BAA0D851BFE411493A8447784E52864CE
Key type : PUBCapabilities.: 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 : SUBCapabilities.: e  encrypt
Algorithm: 

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

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/13/2015 07:00 PM, Brian Dolbec wrote:
> [snip]
> 
> 

I just wanted to say that I didn't have (too) much trouble setting up
my key when I was getting started back in May. I couldn't have done it
without your assistance; I believe one other person helped me out,
too. I went to #gentoo-keys and you guys went over it step by step.

It looks like my key is still good, too.

If you need any help with the project, Brian, I wouldn't mind
contributing. Specifically the documentation. I'd just need an idea of
where to start.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWbmBTAAoJEAEkDpRQOeFwYNEQAId2kLObVWr8RmK/jhD8iD5a
nmTdGi54SeDBYLVufYAq6u6O6xE9RJT0bb8uI2/Yy2ux+ZFGyALNIf736AjS9j15
vCmcnC0QrGXIMCfRMGtbRLdacqFGU0Ov59MyF3mzuFVElqW2YafFDGE0s6uZjt8m
ElC9Q/tewBHAFYbALUxQcYsY6V5xdVkxRBsBRKfE2HaOEnYma6oRcdefYuVHfhEm
Jtn9X+E+pAT8fSoskyQhTMmu4NUBonHcqeZBaWrZmIzKs8w8fdK8Z2Jw4QqzT+Fc
6QclX/BBmrEM8V9649ywaINYXWlOGKVe9PKUlMyr29qJ54azmGFW6LuakTaIpmtc
W2q7JpdL3bX7IREEsLl2+DHAcGIf4GRihbNvEgT5JTGcRH2kf/NtDjHUP+pKdye6
NVlNmIQU8ZwB57n7fWniQFTzEZ5xoD0GGIPHCPAtku4+mnGhRinvJt4zrViPi+Mw
IwKnknKt72fs9kvmPO5o0zna9NdydkxWySU6Cq5jt6gMHcBwacztj+YXazcxL14y
Sb8ozV5mG2IlKL3ghJJhWuEbpMnWuW4XAu4EES5ZB2keXxFxVbpSNL6IDf2hyxxY
AUYHLyTD+aaab0dPsGrddg8iQt+pbH+WxKduhqtGFg8QdYT9AaE5iAZxGMehg+kA
Vpo7Lk1Glb9qYRVCJ+Lg
=EdQ8
-END PGP SIGNATURE-