| 1 |
On Mon, Jul 2, 2018 at 7:48 PM Hanno Böck <hanno@g.o> wrote: |
| 2 |
> Hi, |
| 3 |
|
| 4 |
Oh, thank you for arriving! I've been trying to ping you the last few |
| 5 |
days hoping you'd pop in here. :) |
| 6 |
|
| 7 |
> Something like this was I believe the original idea behind signed |
| 8 |
> manifests. Not sure how long ago this was, but we used to sign Manifest |
| 9 |
> files at some point, though it never was part of any consistent concept |
| 10 |
> as far as I know, and they weren't checked regularly. |
| 11 |
|
| 12 |
Right, but I believe the manifest signatures had some limitations, |
| 13 |
with eclasses and with overly broad granularity. Whereas adding a .asc |
| 14 |
for each individual file as it's edited is really quite simple. |
| 15 |
|
| 16 |
> Anything like this comes with some obvious problems that you need to |
| 17 |
> answer if you want to have such a system: |
| 18 |
> * How are you keeping the keys up to date? Which keys are included |
| 19 |
> there? All currently active developers? All active and former |
| 20 |
> developers? |
| 21 |
> * What happens if a key expires? Do you accept expired signatures if |
| 22 |
> the package has been committed before the expiration date? Or is |
| 23 |
> there some kind of resign process if that happens? Does the developer |
| 24 |
> have to do this himself or can other developers do this? If it's up |
| 25 |
> on the developer what happens if he's inactive / on long holiday / |
| 26 |
> not reachable when his key expires? |
| 27 |
> * What happens if a key is revoked, because a developer decides to |
| 28 |
> create a new key? Same question as with expired keys: Do all |
| 29 |
> signatures need to be recreated? How's that going to happen? |
| 30 |
> * What happens if a developer leaves Gentoo? We'll still want to have |
| 31 |
> his packages. Again a resign procedure? |
| 32 |
> |
| 33 |
> I don't want to say this is unworkable. But these are challenges and |
| 34 |
> imho fixing them all is really, really tricky. Either you break stuff |
| 35 |
> regularly or you have procedures that someone has to do regularly in |
| 36 |
> order to avoid breakage (more work for gentoo devs) or you expand the |
| 37 |
> scope of accepted signatures very excessively. |
| 38 |
|
| 39 |
I think the answer to these questions is to start out fairly |
| 40 |
restrictive and see how it goes and what sorts of easing is needed in |
| 41 |
practice. For example, it might work fine to let keys expire, to let |
| 42 |
developers retire and have their keys removed, and so forth, and |
| 43 |
simply have some nice monitoring infrastructure and alert tools |
| 44 |
(repoman full, for example) so that some developer somewhere re-ups |
| 45 |
the signature after taking a glance. |
| 46 |
|
| 47 |
Jason |
Archives