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

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  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-) 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
 based OpenPGP Key using
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
"" $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 

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  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  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 4:41 AM, Patrick Lauer  wrote:
> Wiki says:
>
> "In this guide we are going to show you how to create a GLEP 63
>  based OpenPGP Key using
> 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 ~4
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

[Peter Stuge]

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


pgpPjFwTn4HmV.pgp
Description: PGP signature

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