1 |
On 17 July 2015 at 15:36, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec <dolsen@g.o> wrote: |
3 |
>> |
4 |
>> I don't know tbh, most are already signed, with the git migration, the |
5 |
>> strongly recommended commit signing will become MANDATORY. |
6 |
>> |
7 |
>> So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys |
8 |
>> listed in LDAP that fail to meet the new spec. PLEASE fix them or |
9 |
>> create new keys... |
10 |
> |
11 |
> How does somebody know whether their key meets the spec or not? I |
12 |
> looked at the gentoo-keys website and didn't see any simple way to |
13 |
> check. |
14 |
> |
15 |
> There was documentation on the gkeys utility for checking keys, but I |
16 |
> ran into a few issues with this. First, it can't be installed on a |
17 |
> stable system with mirrorselect. |
18 |
|
19 |
The use of keys should be by counter signature, when pushing the |
20 |
counter signature service should check if signature is valid and dev |
21 |
key is valid using the internal ldap for example, and counter sign |
22 |
with its own key and add timestamp. Users should trust only the |
23 |
counter signature service key which is formal and should be valid for |
24 |
long time. |
25 |
|
26 |
This is yet another reason why it is best to not use signature within |
27 |
git but remain the signed manifest. When commit one can sign the |
28 |
manifest, send the manifest to the counter signature service and |
29 |
obtain a formal signed manifest to be committed into tree. |
30 |
|
31 |
Using signed manifest also reduce the merge conflict, survive rebase, |
32 |
enable code review without loosing original signer and will enable |
33 |
future migration to other technology. |
34 |
|
35 |
Regards, |
36 |
Alon |