| 1 |
On 11/19/18 11:33 AM, Rich Freeman wrote: |
| 2 |
> On Mon, Nov 19, 2018 at 2:21 PM Roy Bamford <neddyseagoon@g.o> wrote: |
| 3 |
>> |
| 4 |
>> "The archive members support optional OpenPGP signatures. |
| 5 |
>> The implementations must allow the user to specify whether OpenPGP |
| 6 |
>> signatures are to be expected in remotely fetched packages." |
| 7 |
>> |
| 8 |
>> Or can the user specify that only some elements need to be signed? |
| 9 |
>> |
| 10 |
>> Is it a problem if not all elements are signed with the same key? |
| 11 |
>> That could happen if one person makes a binpackage and someone |
| 12 |
>> else updates the metadata. |
| 13 |
>> |
| 14 |
> |
| 15 |
> IMO this is going a bit into PM details for a GLEP that is about |
| 16 |
> container formats. |
| 17 |
> |
| 18 |
> Presumably any package manager is going to need to figure out what |
| 19 |
> keys are/aren't valid and allow the user to configure this behavior. |
| 20 |
> Users who want to go editing package innards will presumably adjust |
| 21 |
> their package manager settings to accept their modifications, whether |
| 22 |
> it means accepting their own sigs or disabling them. |
| 23 |
|
| 24 |
With the GLEP as it is, the user *must* use a local signing key to sign |
| 25 |
installed packages during the installation process if they want to be |
| 26 |
able to verify signatures for installed packages at some point in the |
| 27 |
future, since the binary package format does not provide a way to use |
| 28 |
binary package signatures for this purpose. |
| 29 |
-- |
| 30 |
Thanks, |
| 31 |
Zac |
Archives