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

[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

[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]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Mike Gilbert]

On Sun, Dec 13, 2015 at 2:20 PM, Andrew Savchenko <bircoph@gentoo.org> 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]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On Sun, 13 Dec 2015 16:30:06 -0500 Mike Gilbert wrote:
> On Sun, Dec 13, 2015 at 2:20 PM, Andrew Savchenko <bircoph@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 10361 bytes --]

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.


-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

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@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.

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

[Mike Gilbert]

On Mon, Dec 14, 2015 at 6:12 AM, Patrick Lauer <patrick@gentoo.org> 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

[Peter Stuge]

Patrick,

Patrick Lauer wrote:
> Like seriously, every time I try to approach this set of problems I
> run into enough stupidity

Stop the silly complaining and help work on solving the problem instead.

If you can contribute then do so. If not, your options are to hire
someone who is, or await the day when a fix to your problem magically
appears. :) It really is that simple.

You mentioned that you use Gentoo professionally. This means that you
have already invested in Gentoo and have probably planned to
contribute to Gentoo. It seems that you have come across an
area where you could contribute.

If you choose not to that's perfectly fine, but since there is no
warranty you really do not get to complain that it's broken if you're
not helping fix it, and the tone you are using is certainly not
acceptable.


> why do we have documentation then when it's not adequate

Because you haven't helped make it adequate for your needs.


> why do we have a helper tool when it doesn't work?

Because you haven't helped make it work the way you need.


> ... and now I walk away for another week, in the hope that things
> maybe are saner then.

In my opinion that is the very last thing you should be doing.

Open source only works when you take ownership of the problems you have.

You are on the contrary saying that you refuse to own your problems,
that you only want to consume perfect solutions that someone else has
provided you.

It sounds like something a spoiled teenager might say, and it is
really not acceptable behavior in any open source project.

Help fix the problem instead - as you initially offered to do. That's
the very best approach! Everyone will be thankful and the world will
be a happier place.

You need to work on communication. Nobody will want anything to do
with you as long as you continue to sound like a spoiled teenager,
and once you change your communication style plenty will still
remember you for how you used to be, but you have to start somewhere.

It's simple. Stop complaining, be concrete and specific, and send
patches.


Thanks for your contributions to Gentoo, past and future!

//Peter

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

On Sun, 13 Dec 2015 19:00:45 -0800
Brian Dolbec <dolsen@gentoo.org> wrote:


> 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).

It's a little difficult for people to generate new keys with gkeys-gen when
the version of gkeys-gen in the tree is completely and utterly broken, and has
been for almost a year now. The last time I tried to make a new key it spit
out a bunch of errors and tried to put data in $HOME/~/gkeys-user/gpghome.
Like it didn't expand the tilde, but made a directory literally named '~'.  I'm
supposed to use this for security sensitive data?  You want me to use a
potentially unstable live ebuild instead?  Well, no, that's not gonna happen.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

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

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Ryan Hill wrote:
> You want me to use a potentially unstable live ebuild instead?
> Well, no, that's not gonna happen.

Are you demanding that someone else produces for you, and refusing to
do anything but consume?

If the stable version is broken and if needing to use ~ or live is
not up to your standards then why not help roll the next stable version?

Help solve the problem instead of complaining.

Everyone will benefit.


Thanks for your contributions to Gentoo - past and future!

//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

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

[Rich Freeman]

On Mon, Dec 21, 2015 at 1:59 PM, Peter Stuge <peter@stuge.se> wrote:
> Ryan Hill wrote:
>> You want me to use a potentially unstable live ebuild instead?
>> Well, no, that's not gonna happen.
>
> Are you demanding that someone else produces for you, and refusing to
> do anything but consume?
>

Keep in mind that the GLEP does not require anybody to actually use
gkeys.  It is just a tool intended to make the GLEP easier to follow.

As has been pointed out, we haven't exactly been strict about
enforcing compliance, and for my part I'm not inclined to see a lot
more enforcement until the instructions/tools/etc catch up.  If
anybody wants to see increased adoption of the new GLEP, I'd recommend
focusing more on easy instructions and tools.

That said, anybody who cares enough will figure out how to get it
working.  I just made myself a dedicated tree-signing key and as far
as I could tell the last time I looked at it the key complied.  Just
don't try to send me any encrypted email, since the key in LDAP
probably doesn't work for encryption (having a separate LDAP record
for signing key and communication key might make sense).  :)

--
Rich

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

[Patrick Lauer]

On 12/21/2015 04:21 AM, Ryan Hill wrote:
> On Sun, 13 Dec 2015 19:00:45 -0800
> Brian Dolbec <dolsen@gentoo.org> wrote:
>
>
>> 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).
> It's a little difficult for people to generate new keys with gkeys-gen when
> the version of gkeys-gen in the tree is completely and utterly broken, and has
> been for almost a year now.
Wiki says:

"In this guide we are going to show you how to create a GLEP 63
<https://wiki.gentoo.org/wiki/GLEP:63> based OpenPGP Key using
app-crypt/gkeys-gen
<https://packages.gentoo.org/packages/app-crypt/gkeys-gen> tool which is
the official way of managing OpenPGP keys in the Gentoo Infrastructure."

So either the documentation is wrong, or we're supposed to use a broken
tool.

Interesting challenge!
>  The last time I tried to make a new key it spit
> out a bunch of errors and tried to put data in $HOME/~/gkeys-user/gpghome.
> Like it didn't expand the tilde, but made a directory literally named '~'.  I'm
> supposed to use this for security sensitive data?  You want me to use a
> potentially unstable live ebuild instead?  Well, no, that's not gonna happen.
It gets even better when you try to read the code. But, not to worry -
it's actually pretty easy. Took me only about 4h to combine the
fragments together ...


So, first part of the puzzle:
https://wiki.gentoo.org/wiki/GLEP:63

Build a gpg.conf with the suggestions there.

Now read http://www.gnupg.org/gph/en/manual.html ... well, the
interesting part is:

"""
$ gpg --full-gen-key

Your selection? 4
What keysize do you want? (2048) 4096
Key is valid for? (0) 36m
"""
Those are the required base parameters, all other questions are
identifier (name/email). It'll take a minute or five to collect enough
entropy.

Now you want to generate a subkey (where ${keyid} is the keyid of the
main key):

"""
$ gpg --edit-key ${keyid}
gpg> addkey
Your selection? 4
What keysize do you want? (2048) 4096
Key is valid for? (0) 12m
"""
and maybe a revocation certificate:
"""
$ gpg --output revoke.asc --gen-revoke ${keyid}
"""

What I did then was to export the subkey, and keep the main key
somewhere safe. Then import the subkey on the victim machine(s) used for
gentoo committery.

Now you need to read the gpg docs again and figure out that you need
"gpg --send-keys" to upload the key to the public keyservers.

Then you wait a few minutes for it to become visible, you can check that
on http://pool.sks-keyservers.net.

Now your wiki skills are needed, if you don't know the magic invocation
you won't find it.
Hint: https://wiki.gentoo.org/wiki/Project:Infrastructure/LDAP_Guide
||

The magic line|||||||is: "perl_ldap -b user -C gentooGPGfingerprint
"<newfp>" $USER".

So now log in to dev.gentoo.org and add your key's fingerprint there.
Wait 15 minutes.

Use that time to read https://wiki.gentoo.org/wiki/Gentoo_git_workflow

especially the repository settings chapter.


... and now you can clone the repo, and do (signed) commits. Easy!



So, our onboarding experience sucks, this information is spread out in a
way that makes it hard to find even if you know what you want.

It took me literally hours, which means every new dev trying to do this
will spend hours. It's a colossal waste of time, drains motivation, and
especially the conflicting/wrong docs are not really a good idea.

The complaints are mostly that no one seems to have thought about how a
new user will find things, so there's no combined doc. The wiki is hard
to search, making it extra challenging to figure out what to do.



How to improve? Take my email, cut out the parts that state the obvious,
turn it into a wiki page referencing the other wiki pages (if wiki is
your thing - I refuse to touch MediaWiki outside of paid work, because I
got paid too long to work with it and understand the deeply ingrained
confusion its authors had about the universe)

Or just point people at a random email, because that's about as good as
documentation.
I've wasted enough time documenting the missing pieces, instead of
running gkeys-gen and doing this whole process in under half an hour it
took me most of an afternoon, with my mood definitely not improving.


Please, stop wasting people's time, if you write code or documentation
write it once properly, don't release untested things and claim they are
an official tool, and don't ignore complaints (because they mean, as a
first approximation, that you screwed up and need to fix stuff)

Sigh.


|||

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

[Rich Freeman]

On Tue, Dec 22, 2015 at 4:41 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> Wiki says:
>
> "In this guide we are going to show you how to create a GLEP 63
> <https://wiki.gentoo.org/wiki/GLEP:63> based OpenPGP Key using
> app-crypt/gkeys-gen
> <https://packages.gentoo.org/packages/app-crypt/gkeys-gen> tool which is
> the official way of managing OpenPGP keys in the Gentoo Infrastructure."
>
> So either the documentation is wrong, or we're supposed to use a broken
> tool.

The GLEP is certainly official.  I think the tool was intended to be,
but the whole point of a "standard GLEP" is that you have to meet the
standard, not use a particular implementation.  gkeys isn't even the
reference implementation.

>
> Or just point people at a random email, because that's about as good as
> documentation.

Thank you for writing up a guide/outline.

You appear to hate mediawiki, but you do realize that you could
probably copy/paste that email into the box and call it half-done,
right?  Somebody else can always come along and improve it, and that
is kind of the whole point of a wiki, and of FOSS in general.

>
> Please, stop wasting people's time, if you write code or documentation
> write it once properly, don't release untested things and claim they are
> an official tool, and don't ignore complaints (because they mean, as a
> first approximation, that you screwed up and need to fix stuff)
>

Gentoo devs and volunteers are more than welcome to ignore complaints.
I'll take half-implemented code over no code any day of the week.
Maybe somebody isn't good at writing documentation, and we benefit
from getting their contributions all the same which somebody can later
follow-up on (perhaps somebody who is better at writing documentation
than code).  You're going to make more progress with evolutionary
steps.

BTW, bugs aren't complaints, and I don't really consider "complaints"
nearly as useful.  If you want to point out an error by all means do
so.  You can do it without implying that somebody somehow owed you
something better. They don't.

-- 
Rich

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

[Patrick Lauer]

On 12/22/2015 01:08 PM, Rich Freeman wrote:
>> Or just point people at a random email, because that's about as good as
>> documentation.
> Thank you for writing up a guide/outline.
>
> You appear to hate mediawiki, but you do realize that you could
> probably copy/paste that email into the box and call it half-done,
> right?  Somebody else can always come along and improve it, and that
> is kind of the whole point of a wiki, and of FOSS in general.
I've worked with Semantic Mediawiki long enough to understand that it is
a pile of buggy hacks, on top of a horribly bad codebase, on top of a
horribly broken language. Upstream developers don't understand concepts
like data truncation, and debugging this pile of code is going to make
you cry.

(Just as an example: I found a 'pathological' pageview that cost ~40000
SQL connections (yes!) and 90 CPU-seconds render time, server side, on a
4Ghz machine. Moving the database from dedicated hardware to the MW
server sped up page render time because the network latency of ethernet
becomes painful ...)

From the beginning I've suggested to use something sane, but people Know
what needs to be done, so there's no way to avoid such badness to
spread.  And thus I just refuse to interact with it now, because I know
enough details about SMW templates to not want to stare at that buggy
ad-hoc mess of random again.

>
>> Please, stop wasting people's time, if you write code or documentation
>> write it once properly, don't release untested things and claim they are
>> an official tool, and don't ignore complaints (because they mean, as a
>> first approximation, that you screwed up and need to fix stuff)
>>
> Gentoo devs and volunteers are more than welcome to ignore complaints.
> I'll take half-implemented code over no code any day of the week.
Broken code is worse than no code: Now you spend lots of time on
debugging, instead of doing something more useful.

I'd replace gkeys-gen with a ~10-line shell script ... if I had some
motivation to dig through some old experiments of mine where I managed
to set all parameters for pgp from CLI. Which is all that gkeys-gen
would do!
> Maybe somebody isn't good at writing documentation, and we benefit
> from getting their contributions all the same which somebody can later
> follow-up on (perhaps somebody who is better at writing documentation
> than code).  You're going to make more progress with evolutionary
> steps.
>
> BTW, bugs aren't complaints, and I don't really consider "complaints"
> nearly as useful.  If you want to point out an error by all means do
> so.  You can do it without implying that somebody somehow owed you
> something better. They don't.
>
I guess we fundamentally disagree - if you do shoddy work, it is shoddy.
I won't praise you for it.

Look, *I* spent about a working day all in all on just figuring out why
things don't work. Multiply by number of contributors, and it starts
looking really sad. Time and motivation are not free resources!

That's my time, spent to work around deficiencies I shouldn't even see -
if other people had done their job. And that's just frustrating if it
happens again and again, and instead of doing something interesting I
spend most of my time just being janitor and cleaning up stuff.

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

[Rich Freeman]

On Tue, Dec 22, 2015 at 7:53 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> I'd replace gkeys-gen with a ~10-line shell script ... if I had some
> motivation to dig through some old experiments of mine where I managed
> to set all parameters for pgp from CLI. Which is all that gkeys-gen
> would do!

Sounds great.

> I guess we fundamentally disagree - if you do shoddy work, it is shoddy.
> I won't praise you for it.

Nobody is looking for your praise.

> That's my time, spent to work around deficiencies I shouldn't even see -
> if other people had done their job. And that's just frustrating if it
> happens again and again, and instead of doing something interesting I
> spend most of my time just being janitor and cleaning up stuff.

I hope you're not the one looking for praise.  I can't imagine that
your pep talk has done a great deal to motivate people to spend time
improving the Gentoo Keys experience.

Do you want to see this fixed?
Are you willing to do the fixing yourself?

If the answer to the first question is yes, and the second is no, then
you've just volunteered for the job of either community motivator, or
frustrated user.  The goal then is to make people care more about
going out of their way to fix things than going out of their way to
find ways to make you even more frustrated.  Which do you think is
going to be more emotionally satisfying to those who read this thread?

-- 
Rich

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

[Patrick Lauer]

On 12/22/2015 02:14 PM, Rich Freeman wrote:
> On Tue, Dec 22, 2015 at 7:53 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>> I'd replace gkeys-gen with a ~10-line shell script ... if I had some
>> motivation to dig through some old experiments of mine where I managed
>> to set all parameters for pgp from CLI. Which is all that gkeys-gen
>> would do!
> Sounds great.
>
>> I guess we fundamentally disagree - if you do shoddy work, it is shoddy.
>> I won't praise you for it.
> Nobody is looking for your praise.
>
>> That's my time, spent to work around deficiencies I shouldn't even see -
>> if other people had done their job. And that's just frustrating if it
>> happens again and again, and instead of doing something interesting I
>> spend most of my time just being janitor and cleaning up stuff.
> I hope you're not the one looking for praise.  I can't imagine that
> your pep talk has done a great deal to motivate people to spend time
> improving the Gentoo Keys experience.
Well, it's abandoned anyway (bugs open for >1 year means there's
literally no one working on it, for a year)
Like the git 'migration' it's half-finished work with little thought
about workflow or user experience, "Change is Progress"

If we didn't have it at all I would not have had to file bugs, spend
time being very confused, etc. So all in all it has negative value in
its current state. And it wastes the time of everyone who tries to use
it, which is a few man-weeks of work ground away with inefficiency and
carelessness. Imagine how much progress we could have had if someone had
spent one afternoon on writing coherent docs!

>
> Do you want to see this fixed?
> Are you willing to do the fixing yourself?
I don't have infinite time, and wasting a day documenting things that
should have been documented a year ago is not a good way of spending time.

>
> If the answer to the first question is yes, and the second is no, then
> you've just volunteered for the job of either community motivator, or
> frustrated user.  The goal then is to make people care more about
> going out of their way to fix things than going out of their way to
> find ways to make you even more frustrated.  Which do you think is
> going to be more emotionally satisfying to those who read this thread?
>
Things working.

So, the trick is not to have user-visible breakage.

Now you know the great trick too and can apply it to your daily life.

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

[Rich Freeman]

On Tue, Dec 22, 2015 at 8:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>
>> Do you want to see this fixed?
>> Are you willing to do the fixing yourself?
> I don't have infinite time, and wasting a day documenting things that
> should have been documented a year ago is not a good way of spending time.

So, it sounds like the answer to the first question is yes, and the
second is no...

>>
>> If the answer to the first question is yes, and the second is no, then
>> you've just volunteered for the job of either community motivator, or
>> frustrated user.  The goal then is to make people care more about
>> going out of their way to fix things than going out of their way to
>> find ways to make you even more frustrated.  Which do you think is
>> going to be more emotionally satisfying to those who read this thread?
>>
> Things working.
>
> So, the trick is not to have user-visible breakage.
>
> Now you know the great trick too and can apply it to your daily life.
>

Yeah, but if I don't lift a finger to help fix this bug, I know it
will drive you crazy for a few more days, or even months.  That's
basically my point.  You're basically begging everybody who would
otherwise want to fix this issue to just troll you instead.  And that
isn't helpful to anybody.

You can't just wave your hands and have no user-visible breakage.  You
either need to fix things yourself or help motivate others to do it.
The approach you're taking is about as helpful as telling your
significant other that they're fat.  After they're finished stabbing
you to death with their spoon they're going to stick it in some Ben
and Jerry's.

Ugh, gotta take a break.  Happy holidays!

-- 
Rich

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

[Patrick Lauer]

On 12/22/2015 03:04 PM, Rich Freeman wrote:
> On Tue, Dec 22, 2015 at 8:31 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>>> Do you want to see this fixed?
>>> Are you willing to do the fixing yourself?
>> I don't have infinite time, and wasting a day documenting things that
>> should have been documented a year ago is not a good way of spending time.
> So, it sounds like the answer to the first question is yes, and the
> second is no...
I shouldn't have to clean up other people's mess. I mean, cleaning up
after toddlers is ok, but, well ... sigh.
Are any of you toddlers? :D

>
>>> If the answer to the first question is yes, and the second is no, then
>>> you've just volunteered for the job of either community motivator, or
>>> frustrated user.  The goal then is to make people care more about
>>> going out of their way to fix things than going out of their way to
>>> find ways to make you even more frustrated.  Which do you think is
>>> going to be more emotionally satisfying to those who read this thread?
>>>
>> Things working.
>>
>> So, the trick is not to have user-visible breakage.
>>
>> Now you know the great trick too and can apply it to your daily life.
>>
> Yeah, but if I don't lift a finger to help fix this bug, I know it
> will drive you crazy for a few more days, or even months.  That's
> basically my point.  You're basically begging everybody who would
> otherwise want to fix this issue to just troll you instead.  And that
> isn't helpful to anybody.
>
> You can't just wave your hands and have no user-visible breakage.  You
> either need to fix things yourself or help motivate others to do it.
> The approach you're taking is about as helpful as telling your
> significant other that they're fat.  After they're finished stabbing
> you to death with their spoon they're going to stick it in some Ben
> and Jerry's.
>
> Ugh, gotta take a break.  Happy holidays!
>
So here's the magic:

Create a file "keyspec.txt" containing something like:

"""
%echo Generating a basic OpenPGP key
Key-Type: RSA
Key-Length: 4096
Key-Usage: sign
Expire-Date: 1y
Subkey-Type: RSA
Subkey-Length: 4096
Subkey-Usage: sign
Name-Real: Patrick Lauer
Name-Email: changethis@email.xyz
Passphrase: ThisIsBadPassphrayse
%commit
%echo done
"""
Not that Name-* and Passphrase should be personalized (or Passphrase
removed!)

Now make a backup of .gnupg because this will be destructive.
Do not run this command as a normal user unless you are sure you want to
overwrite the default keyring.

So now that we are sure that you don't accidentally all your keys (do
not run this for fun! This is a destructive command)

"""
gpg --batch --gen-key keyspec.txt
"""

Tadaah! (well, it'll take a few minutes, since gpg wants really sexy
entropy and takes its time to get there)

The part I haven't figured out yet is how to non-interactively set key
validity, so you will need to run a second command:

"""
gpg --edit-key expire
"""
and set validity to, say, 3 years, confirm, save, done.


(This mostly obsoletes the 500 lines of eyebleed that were gkeys-gen,
and it actually works. Do you understand why I'm feeling very confused
that something this trivial took over a year?!)

Time from start of RTFM to email: 1h.

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

[Peter Stuge]

Patrick Lauer wrote:
> my time, spent to work around deficiencies I shouldn't even see -
> if other people had done their job.

Ah but that's the thing - it *isn't* their job.

They are volunteering. That's a very different construct.

And yes, you do have to work around deficiencies created by others.
That's pretty much the essence of volunteer-based collaboration. So fun!


Thank you very much for volunteering time to document and improve
automatic GLEP63-compliant key generation! Sweet! You deserve to
publish it somewhere. Anything gentoo.org please. :)


//Peter