| 1 |
On 2018.11.19 19:33, Rich Freeman wrote: |
| 2 |
> On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford <neddyseagoon@g.o> |
| 3 |
> wrote: |
| 4 |
> > |
| 5 |
> > "The archive members support optional OpenPGP signatures. |
| 6 |
> > The implementations must allow the user to specify whether OpenPGP |
| 7 |
> > signatures are to be expected in remotely fetched packages." |
| 8 |
> > |
| 9 |
> > Or can the user specify that only some elements need to be signed? |
| 10 |
> > |
| 11 |
> > Is it a problem if not all elements are signed with the same key? |
| 12 |
> > That could happen if one person makes a binpackage and someone |
| 13 |
> > else updates the metadata. |
| 14 |
> > |
| 15 |
> |
| 16 |
> IMO this is going a bit into PM details for a GLEP that is about |
| 17 |
> container formats. |
| 18 |
> |
| 19 |
|
| 20 |
Rich, |
| 21 |
|
| 22 |
Not really. The GLEP needs to be clear about the signing. |
| 23 |
Is it every element or none? |
| 24 |
The GLEP hints that a mix of is possible with |
| 25 |
|
| 26 |
If the implementation needs to manipulate archive members, it must |
| 27 |
either create a new signature or discard the existing signature. |
| 28 |
|
| 29 |
An individual binpackage could start life with all elements signed |
| 30 |
by the same key. |
| 31 |
|
| 32 |
Some element could be updated and the key for the signature of |
| 33 |
that element changed. |
| 34 |
|
| 35 |
Later still, another element can be changed an have its signature |
| 36 |
dropped. |
| 37 |
|
| 38 |
Should some combinations have no practical value, they should |
| 39 |
not be permitted by the GLEP. |
| 40 |
|
| 41 |
> -- |
| 42 |
> Rich |
| 43 |
> |
| 44 |
> |
| 45 |
> |
| 46 |
|
| 47 |
-- |
| 48 |
Regards, |
| 49 |
|
| 50 |
Roy Bamford |
| 51 |
(Neddyseagoon) a member of |
| 52 |
elections |
| 53 |
gentoo-ops |
| 54 |
forum-mods |
Archives