On Mon, Jul 2, 2018 at 7:48 PM Hanno Böck <ha...@gentoo.org> wrote:
> Hi,

Oh, thank you for arriving! I've been trying to ping you the last few
days hoping you'd pop in here. :)

> Something like this was I believe the original idea behind signed
> manifests. Not sure how long ago this was, but we used to sign Manifest
> files at some point, though it never was part of any consistent concept
> as far as I know, and they weren't checked regularly.

Right, but I believe the manifest signatures had some limitations,
with eclasses and with overly broad granularity. Whereas adding a .asc
for each individual file as it's edited is really quite simple.

> Anything like this comes with some obvious problems that you need to
> answer if you want to have such a system:
> * How are you keeping the keys up to date? Which keys are included
>   there? All currently active developers? All active and former
>   developers?
> * What happens if a key expires? Do you accept expired signatures if
>   the package has been committed before the expiration date? Or is
>   there some kind of resign process if that happens? Does the developer
>   have to do this himself or can other developers do this? If it's up
>   on the developer what happens if he's inactive / on long holiday /
>   not reachable when his key expires?
> * What happens if a key is revoked, because a developer decides to
>   create a new key? Same question as with expired keys: Do all
>   signatures need to be recreated? How's that going to happen?
> * What happens if a developer leaves Gentoo? We'll still want to have
>   his packages. Again a resign procedure?
>
> I don't want to say this is unworkable. But these are challenges and
> imho fixing them all is really, really tricky. Either you break stuff
> regularly or you have procedures that someone has to do regularly in
> order to avoid breakage (more work for gentoo devs) or you expand the
> scope of accepted signatures very excessively.

I think the answer to these questions is to start out fairly
restrictive and see how it goes and what sorts of easing is needed in
practice. For example, it might work fine to let keys expire, to let
developers retire and have their keys removed, and so forth, and
simply have some nice monitoring infrastructure and alert tools
(repoman full, for example) so that some developer somewhere re-ups
the signature after taking a glance.

Jason

Reply via email to