Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Brian Dolbec]

On Fri, 17 Jul 2015 08:36:25 -0400
Rich Freeman <rich0@g.o> wrote:

> On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@g.o>
> wrote:
> >
> > I don't know tbh, most are already signed, with the git migration,
> > the strongly recommended commit signing will become MANDATORY.
> >
> > So, we are at 50 devs with valid gpg keys now, with 200 more gpg
> > keys listed in LDAP that fail to meet the new spec.  PLEASE fix
> > them or create new keys...
>
> How does somebody know whether their key meets the spec or not?  I
> looked at the gentoo-keys website and didn't see any simple way to
> check.
>
> There was documentation on the gkeys utility for checking keys, but I
> ran into a few issues with this.  First, it can't be installed on a
> stable system with mirrorselect.
>
> On a clean ~arch stage3 when trying to run "gkeys fetch-seed -C
> gentoo-devs" it outputs:
> Connector.connect_url(); Failed to retrieve the content from:
> https://api.gentoo.org/gentoo-keys/seeds/gentoo-devs.seeds
> Error was: Invalid header value 'Wed, 15 Jul 2015 17:50:17 GMT\n'
>
>
> After removing the files in /var/lib/gentoo/gkeys/seeds the fetch
> works.  However, attempting to run "gkeys install-key -C gentoo-devs"
> results in:
>  Found GKEY seeds:
> Traceback (most recent call last):
>   File "/usr/lib/python-exec/python2.7/gkeys", line 50, in <module>
>     success = main()
>   File "/usr/lib64/python2.7/site-packages/gkeys/cli.py", line 63, in
> __call__ return self.run(args)
>   File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 303,
> in run success, results = func(args)
>   File "/usr/lib64/python2.7/site-packages/gkeys/actions.py", line
> 264, in installkey
>     self.output(['', gkey], "\n Found GKEY seeds:")
>   File "/usr/lib64/python2.7/site-packages/gkeys/base.py", line 323,
> in output_results
>     print("\n".join([x.pretty_print for x in msg]))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u017b' in
> position 1233: ordinal not in range(128)
>
>

Yes, the ssl-fetch issue is fixed with ssl-fetch-0.3 and it is now
stabilized.  So that conflict is fixed.


> It might not hurt to publish the list of keys that fail checks.  If
> that list is going to be used to block commits then obviously it needs
> to be updated very frequently.  I do not know if there are any plans
> to block commits with signatures that do not conform to the GLEP.
>

Yeah, I was thinking of putting up a gkeys spec-check report, but we
were (unsuccessfully) trying to get more wiki pages help done on how to
fix those issues reported.  Before we did such a report.  Also I need
to make another release, currently gkeys-9999 and gkeys-gen-999 is the
best option with the most fixes, best functionality.   Hopefully I'll
get those release this weekend.

-- 
Brian Dolbec <dolsen>