Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification

[Zac Medico]

On 01/17/2018 07:42 AM, Alec Warner wrote:
> On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny <mgorny@g.o
> <mailto:mgorny@g.o>> wrote:
>
>     W dniu wto, 16.01.2018 o godzinie 11∶32 -0800, użytkownik Zac Medico
>     napisał:
>     > On 01/16/2018 10:39 AM, Michał Górny wrote:
>     > > W dniu wto, 16.01.2018 o godzinie 12∶44 -0500, użytkownik Alec
>     Warner
>     > > napisał:
>     > > > On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny
>     <mgorny@g.o <mailto:mgorny@g.o>> wrote:
>     > > >
>     > > > > Include a repo.postsync.d hook to verify the rsync checkout
>     using
>     > > > > gemato. Given that not all people will want to have it enabled
>     > > > > unconditionally, no setup.py rules are included -- instead,
>     the file
>     > > > > would be installed conditionally by the ebuild.
>     > > > >
>     > > > > [v2: included link to the wiki page]
>     > > > > ---
>     > > > >  MANIFEST.in                   |  2 +-
>     > > > >  misc/repo.postsync.d/00gemato | 18 ++++++++++++++++++
>     > > > >  2 files changed, 19 insertions(+), 1 deletion(-)
>     > > > >  create mode 100644 misc/repo.postsync.d/00gemato
>     > > > >
>     > > > > diff --git a/MANIFEST.in b/MANIFEST.in
>     > > > > index 4f6cac162..edc6704e7 100644
>     > > > > --- a/MANIFEST.in
>     > > > > +++ b/MANIFEST.in
>     > > > > @@ -14,4 +14,4 @@ include cnf/make.conf.example.*
>     > > > >  include .portage_not_installed
>     > > > >
>     > > > >  # extra scripts
>     > > > > -include misc/*
>     > > > > +graft misc
>     > > > > diff --git a/misc/repo.postsync.d/00gemato
>     b/misc/repo.postsync.d/00gemato
>     > > > > new file mode 100644
>     > > > > index 000000000..f2af50925
>     > > > > --- /dev/null
>     > > > > +++ b/misc/repo.postsync.d/00gemato
>     > > > > @@ -0,0 +1,18 @@
>     > > > > +#!/bin/bash
>     > > > > +# repo.postsync.d hook to verify ::gentoo checkout using gemato
>     > > > > +
>     > > > > +name=${1}
>     > > > > +url=${2}
>     > > > > +path=${3}
>     > > > > +
>     > > > > +# keyring installed by gentoo-keys
>     > > > >
>     +openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
>     > > > >
>     > > >
>     > > > This seems a bit leaky to me.
>     > > >
>     > > > Possible to get gentoo-keys to print it?
>     > > >
>     > > > e.g:
>     > > >
>     > > > openpgp_key=$(gentoo-keys --print-key-path)
>     > >
>     > > But app-crypt/gentoo-keys doesn't include that executable, and
>     it has
>     > > no dependency on app-crypt/gkeys. I'd rather not introduce an
>     artificial
>     > > dependency here.
>     >
>     > I suppose we could using a separate ebuild to install this hook,
>     so that
>     > we can update it separately from portage if necessary. The hook can
>     > still live in the portage repository (like emerge-delta-webrsync which
>     > is also installed by a separate ebuild).
>
>     I don't see a strong reason to add yet another rebuild for a single file
>     that is going to be updated really rarely. However, if we're going to do
>     it that way, then there's no point in putting it in Portage repository.
>
>     However, this 'update it separately from portage' reminds me of repoman
>     that frequently gets seriously outdated and/or incompatible with Portage
>     because of independent release cycle...
>
>
> I'll rephrase my objection.
>
> I don't care what you do as long as Zac (the person releasing portage)
> agrees with whatever
> requirements you need. If we need 3 releases in a row because the hook
> is buggy, as long as
> Zac is happy with that I'm happy with that.
>
> What I don't want to see is surprise when the hook is cut and suddenly
> its buggy and we need new
> cuts and Zac is not around, or HEAD is broken, or some other problem.
>
> Looking at the release history, multiple cuts in O(few) days is fairly
> common (11/20, 11/21, 12/10, 12/15)
> so this seems low risk to me; but AFAIK Zac is usually driving these
> changes himself so its a bit more obvious
> what is going on. Or just allow Michał to cut his own portage releases
> when he needs hook updates.
>
> -A

The thing is, this pubring.gpg path tightly couples the hook to gentoo-keys.
I'd feel much more comfortable about including it with portage if we
used something like this command to query the pubring.gpg location:

$ gkeys list-key -C gentoo -n snapshot

Nick.....: snapshot
Name.....: Gentoo Tree Snapshot (Automated) Signing Key
Keydir...: release
Gpg info.: /var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
           ---------------------------------------------------------
           pub   rsa4096/825533CBF6CD6C97 2014-10-03 [C] [expired: 2017-09-17]
                 Key fingerprint = D2DE 1DBB A0F4 3EBA 341B  97D8 8255 33CB F6CD 6C97
           uid                 [ expired] Gentoo-keys Team <gkeys@g.o>
           
           pub   dsa1024/9E6438C817072058 2004-07-20 [SC] [expires: 2018-07-01]
                 Key fingerprint = D99E AC73 79A8 50BC E47D  A5F2 9E64 38C8 1707 2058
           uid                 [ unknown] Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@g.o>
           sub   elg2048/0403710E1415B4ED 2004-07-20 [E] [expires: 2018-07-01]
           
           pub   rsa4096/DB6B8C1F96D8BF6D 2011-11-25 [C] [expires: 2018-07-01]
                 Key fingerprint = DCD0 5B71 EAB9 4199 527F  44AC DB6B 8C1F 96D8 BF6D
           uid                 [ unknown] Gentoo Portage Snapshot Signing Key (Automated Signing Key)
           sub   rsa4096/EC590EEAC9189250 2011-11-25 [S] [expires: 2018-07-01]
           
           pub   rsa4096/BB572E0E2D182910 2009-08-25 [SC] [expired: 2017-08-25]
                 Key fingerprint = 13EB BDBE DE7A 1277 5DFD  B1BA BB57 2E0E 2D18 2910
           uid                 [ expired] Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@g.o>

-- 
Thanks,
Zac