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

2018-01-19 Thread Michał Górny 
W dniu czw, 18.01.2018 o godzinie 09∶27 -0800, użytkownik Zac Medico
napisał:
> On 01/16/2018 08:43 AM, Michał Górny 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 0..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
> > +
> > +# apply only to ::gentoo, when synced over rsync.
> > +if [[ ${name} == gentoo && ${url} == rsync://* ]]; then
> > +   if ! gemato verify -K "${openpgp_key}" -s "${path}"; then
> > +   eerror "For troubleshooting the verification failures, please 
> > see:"
> > +   eerror "  
> > https://wiki.gentoo.org/wiki/Project:Portage/Repository_Verification;
> > +   return 1
> > +   fi
> > +fi
> > 
> 
> The fact that this hook doesn't check online for revoked keys means it's
> vulnerable to a MITM attack if our keys ever get stolen and revealed to
> the world. That means it gives a false sense of security, and if we
> release it then we're guaranteed to have an immediate GLSA because of it.

I'm currently working on a solution to this problem. I've tried to
establish if we have some 'official' solution to it but it doesn't seem
like it, so I suppose checking keyservers is the way to go forward.

-- 
Best regards,
Michał Górny

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

2018-01-18 Thread Zac Medico 
On 01/16/2018 08:43 AM, Michał Górny 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 0..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
> +
> +# apply only to ::gentoo, when synced over rsync.
> +if [[ ${name} == gentoo && ${url} == rsync://* ]]; then
> + if ! gemato verify -K "${openpgp_key}" -s "${path}"; then
> + eerror "For troubleshooting the verification failures, please 
> see:"
> + eerror "  
> https://wiki.gentoo.org/wiki/Project:Portage/Repository_Verification;
> + return 1
> + fi
> +fi
> 

The fact that this hook doesn't check online for revoked keys means it's
vulnerable to a MITM attack if our keys ever get stolen and revealed to
the world. That means it gives a false sense of security, and if we
release it then we're guaranteed to have an immediate GLSA because of it.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

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

2018-01-17 Thread Zac Medico 
On 01/17/2018 01:31 PM, Zac Medico wrote:
> On 01/17/2018 01:09 PM, Michał Górny wrote:
>> W dniu śro, 17.01.2018 o godzinie 12∶50 -0800, użytkownik Zac Medico
>> napisał:
>>>
>>> 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
>>>
>>
>> I suppose I can live with that. However, gkeys are quite a heavy
>> dependency compared to the keyring, with the latter being the only real
>> requirement for gemato. That is, if that gkeys function works out
>> of the box for non-root users because I recall gkeys having that
>> problem.
> 
> The above gkeys command works for me as any user. However, if I add
> --keydir release to the arguments then it fails to return results unless
> it's running as root. Do we need a working --keydir argument?

I've posted a fix here: https://bugs.gentoo.org/644906
-- 
Thanks,
Zac

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

2018-01-17 Thread Zac Medico 
On 01/17/2018 01:09 PM, Michał Górny wrote:
> W dniu śro, 17.01.2018 o godzinie 12∶50 -0800, użytkownik Zac Medico
> napisał:
>>
>> 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
>>
> 
> I suppose I can live with that. However, gkeys are quite a heavy
> dependency compared to the keyring, with the latter being the only real
> requirement for gemato. That is, if that gkeys function works out
> of the box for non-root users because I recall gkeys having that
> problem.

The above gkeys command works for me as any user. However, if I add
--keydir release to the arguments then it fails to return results unless
it's running as root. Do we need a working --keydir argument?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

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

2018-01-17 Thread Michał Górny 
W dniu śro, 17.01.2018 o godzinie 12∶50 -0800, użytkownik Zac Medico
napisał:
> On 01/17/2018 07:42 AM, Alec Warner wrote:
> > On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny  > > 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
> > > 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 0..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
> 

I suppose I can live with that. However, gkeys are quite a heavy
dependency compared to the keyring, with the latter being the only real
requirement for gemato. That is, if that gkeys function works out
of the box for non-root users because I recall gkeys

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

2018-01-17 Thread Zac Medico 
On 01/17/2018 07:42 AM, Alec Warner wrote:
> On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny  > 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
> > 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 0..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 
   
   pub   dsa1024/9E6438C817072058 2004-07-20 [SC] [expires:

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

2018-01-17 Thread Alec Warner 
On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny  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 
> 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 0..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


>
> --
> Best regards,
> Michał Górny
>
>
>

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

2018-01-17 Thread Michał Górny 
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  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 0..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...

-- 
Best regards,
Michał Górny

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

2018-01-16 Thread Michał Górny 
W dniu wto, 16.01.2018 o godzinie 20∶04 +, użytkownik Robin H.
Johnson napisał:
> On Tue, Jan 16, 2018 at 11:32:28AM -0800, Zac Medico wrote:
> > > 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).
> 
> How about shipping this hook with Gemato, since it's of no use without
> Gemato installed.
> 

I don't want to get into USE dependency hell. Portage needs gemato to do
rsync verification, so we need USE-conditional dep on gemato. However,
gemato doesn't require the hook unconditionally, so we end up with two
USE flags that need to be switched together == a mess.

-- 
Best regards,
Michał Górny

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

2018-01-16 Thread Robin H. Johnson 
On Tue, Jan 16, 2018 at 11:32:28AM -0800, Zac Medico wrote:
> > 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).
How about shipping this hook with Gemato, since it's of no use without
Gemato installed.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

2018-01-16 Thread Zac Medico 
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  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 0..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).
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

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

2018-01-16 Thread Michał Górny 
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  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 0..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.

-- 
Best regards,
Michał Górny

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

2018-01-16 Thread Alec Warner 
On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny  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 0..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)

Or its fine if we think it won't move around. I guess that is mostly up to
dol-sen? :)

-A


> +
> +# apply only to ::gentoo, when synced over rsync.
> +if [[ ${name} == gentoo && ${url} == rsync://* ]]; then
> +   if ! gemato verify -K "${openpgp_key}" -s "${path}"; then
> +   eerror "For troubleshooting the verification failures,
> please see:"
> +   eerror "  https://wiki.gentoo.org/wiki/
> Project:Portage/Repository_Verification"
> +   return 1
> +   fi
> +fi
> --
> 2.16.0.rc2
>
>
>