1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
2 |
Hash: SHA512
|
3 |
|
4 |
On Thu, 16 Jul 2015 23:06:03 -0400
|
5 |
NP-Hardass <NP-Hardass@g.o> wrote:
|
6 |
|
7 |
> -----BEGIN PGP SIGNED MESSAGE----- |
8 |
> Hash: SHA256 |
9 |
> |
10 |
> On 07/16/2015 09:25 PM, Brian Dolbec wrote: |
11 |
> > On Thu, 16 Jul 2015 21:13:09 -0400 NP-Hardass |
12 |
> > <NP-Hardass@g.o> wrote: |
13 |
> > |
14 |
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
15 |
> > |
16 |
> >> Not sure if this has been covered in some of the rather long |
17 |
> >> chains of late, but I was thinking about GPG signing, and how the |
18 |
> >> proposed workflow requires every developer to sign their commits. |
19 |
> >> Currently, it's advised that every manifest be signed. As far as |
20 |
> >> I know, there are a number that are not. When a manifest is |
21 |
> >> signed, the author is saving a state, and providing a means to |
22 |
> >> check it has not changed. |
23 |
> > |
24 |
> >> Additionally, I feel that a signature is a means of acknowledging |
25 |
> >> that a package has been looked over, and that developer has |
26 |
> >> stated that they approve of the existing state. I'm not sure if |
27 |
> >> others agree with that sentiment, but if anyone does, my question |
28 |
> >> is, how does the conversion process to git handle these packages, |
29 |
> >> where the manifests are not signed. Is there an intention to |
30 |
> >> blanket cover all packages when we switch to git? Will these |
31 |
> >> packages be copied over directly and still maintain their |
32 |
> >> unsigned manifest (I think this is unlikely as I read that there |
33 |
> >> would be a switch to thin manifests, requiring regeneration)? If |
34 |
> >> the community doesn't view the signature of the manifest as I |
35 |
> >> just described, then a blanket signing would be fine. |
36 |
> > |
37 |
> >> Would appreciate your thoughts either way, as I could be |
38 |
> >> overthinking the issue :P |
39 |
> > |
40 |
> >> - -- NP-Hardass |
41 |
> > |
42 |
> > |
43 |
> > No, with the git working tree, we will switch to thin manifests and |
44 |
> > the entire commit will be signed. Not only that, but the push to |
45 |
> > the main server will also be signed (a push may contain commits |
46 |
> > signed by a different person that the person pushing). |
47 |
> > |
48 |
> > For the regular rsync tree, Full manifests will be regenerated as |
49 |
> > needed and signed by a common infra supplied gpg key. So for |
50 |
> > general users, it will be easy to verify without having all gentoo |
51 |
> > devs gpg keys. That will be different for users of the git tree. |
52 |
> > |
53 |
> > |
54 |
> > |
55 |
> |
56 |
> Ah ha. so, with thin manifests, we as devs don't sign the manifest, me |
57 |
> sign the commit. |
58 |
> |
59 |
|
60 |
Yes, you sign all changes made by that commit.
|
61 |
|
62 |
In CVS this was not possible, so the best workaround was a 2 stage
|
63 |
commit, where the initial changes were committed, then repoman updated
|
64 |
and signed the new Manifest and committed that.
|
65 |
|
66 |
|
67 |
> The infra key for the user facing tree makes sense. Thanks for |
68 |
> filling me in. So, will infra be using that key to do the initial |
69 |
> commit to the repo? |
70 |
|
71 |
I don't know tbh, most are already signed, with the git migration, the
|
72 |
strongly recommended commit signing will become MANDATORY.
|
73 |
|
74 |
So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys
|
75 |
listed in LDAP that fail to meet the new spec. PLEASE fix them or
|
76 |
create new keys...
|
77 |
|
78 |
> |
79 |
> Are there plans to the make the repo, w/ metadata and signed by infra, |
80 |
> available to end users as a rsync alternative? |
81 |
> |
82 |
|
83 |
Yes, there will be an anonymous git mirror/server for general
|
84 |
consumption. But I believe there again, a user using it will have to
|
85 |
get the gentoo-devs seed file and install those keys in order to
|
86 |
validate it for themselves.
|
87 |
|
88 |
|
89 |
|
90 |
|
91 |
|
92 |
- --
|
93 |
Brian Dolbec <dolsen>
|
94 |
|
95 |
-----BEGIN PGP SIGNATURE-----
|
96 |
Version: GnuPG v2.1
|
97 |
|
98 |
iQJ8BAEBCgBmBQJVqIe1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
|
99 |
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG
|
100 |
QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7Y15QQAKl+8k3PJM6ZrToDqAH2o+Af
|
101 |
4O5FRAr48NVOL+AsA9/8pihiR0p7xZ0N35TJoCh3vkyfPj3sPfxvm3ZC46azVS7r
|
102 |
HoLgRLYVEv8cZpZXBRi7tqi2XWSYxvGl2tqyF9N/k+Eur00s9zLOepgmxjmvDSjq
|
103 |
J88qd/oi6KB0ufVGpl6HkcumPAY5uVw1yjJu5GO/UIWivkXdaHUAwNe2w0eE/TUv
|
104 |
+8YmzkYhmKMAfOF3RFIxcjxtjh13hMrSWqAjxgMG+sH/4jWXi0PWRXNTU6fCTJXP
|
105 |
oxKFyB/XyZObugOMrmDGXX4jnW5oJpj4P02xDyAbsQR/85EAygoxGEr1jvOXrPhN
|
106 |
vX9XYrLaQ62Us6UM8bM8mv1W7gKn/NJSJoeoRpKDsAvUcJlUp4fcCUWc4F/AaE3a
|
107 |
cDYM8uqDJcN571QlR07Rd28/TTX2BFfEclu/u9SznfMLeveET9CUa12LYiIKfKfx
|
108 |
PnO301QRih0FqH/kvX9kAvpJWZeBmn8xdhZ4VyOeYNQFKuROiexswKTapHbuIJec
|
109 |
eM1P0rZmh9AQfVaZhZJpKbvfRl6HyU6cTeHQJ9mvNzQV87MQuhmIyckJfCQONUZM
|
110 |
SQJ95nlg69NJBLY5IHUYdC1A5k3neRhLvpErOFJZQzlVbAaFXfSPnuDKR/YiBbJ3
|
111 |
Benzg8eJp5Dpngyzr1Mz
|
112 |
=4Hgt
|
113 |
-----END PGP SIGNATURE----- |