On Fri, 17 Jul 2015 08:36:25 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dol...@gentoo.org> > 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>
