1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 07/16/2015 09:25 PM, Brian Dolbec wrote: |
5 |
> On Thu, 16 Jul 2015 21:13:09 -0400 NP-Hardass |
6 |
> <NP-Hardass@g.o> wrote: |
7 |
> |
8 |
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
9 |
> |
10 |
>> Not sure if this has been covered in some of the rather long |
11 |
>> chains of late, but I was thinking about GPG signing, and how the |
12 |
>> proposed workflow requires every developer to sign their commits. |
13 |
>> Currently, it's advised that every manifest be signed. As far as |
14 |
>> I know, there are a number that are not. When a manifest is |
15 |
>> signed, the author is saving a state, and providing a means to |
16 |
>> check it has not changed. |
17 |
> |
18 |
>> Additionally, I feel that a signature is a means of acknowledging |
19 |
>> that a package has been looked over, and that developer has |
20 |
>> stated that they approve of the existing state. I'm not sure if |
21 |
>> others agree with that sentiment, but if anyone does, my question |
22 |
>> is, how does the conversion process to git handle these packages, |
23 |
>> where the manifests are not signed. Is there an intention to |
24 |
>> blanket cover all packages when we switch to git? Will these |
25 |
>> packages be copied over directly and still maintain their |
26 |
>> unsigned manifest (I think this is unlikely as I read that there |
27 |
>> would be a switch to thin manifests, requiring regeneration)? If |
28 |
>> the community doesn't view the signature of the manifest as I |
29 |
>> just described, then a blanket signing would be fine. |
30 |
> |
31 |
>> Would appreciate your thoughts either way, as I could be |
32 |
>> overthinking the issue :P |
33 |
> |
34 |
>> - -- NP-Hardass |
35 |
> |
36 |
> |
37 |
> No, with the git working tree, we will switch to thin manifests and |
38 |
> the entire commit will be signed. Not only that, but the push to |
39 |
> the main server will also be signed (a push may contain commits |
40 |
> signed by a different person that the person pushing). |
41 |
> |
42 |
> For the regular rsync tree, Full manifests will be regenerated as |
43 |
> needed and signed by a common infra supplied gpg key. So for |
44 |
> general users, it will be easy to verify without having all gentoo |
45 |
> devs gpg keys. That will be different for users of the git tree. |
46 |
> |
47 |
> |
48 |
> |
49 |
|
50 |
Ah ha. so, with thin manifests, we as devs don't sign the manifest, me |
51 |
sign the commit. |
52 |
|
53 |
The infra key for the user facing tree makes sense. Thanks for |
54 |
filling me in. So, will infra be using that key to do the initial |
55 |
commit to the repo? |
56 |
|
57 |
Are there plans to the make the repo, w/ metadata and signed by infra, |
58 |
available to end users as a rsync alternative? |
59 |
|
60 |
And my apologies to all for the multiple messages. My cron plugin for |
61 |
my email client is wonking. |
62 |
|
63 |
- -- |
64 |
NP-Hardass |
65 |
-----BEGIN PGP SIGNATURE----- |
66 |
Version: GnuPG v2 |
67 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
68 |
|
69 |
iQIcBAEBCAAGBQJVqHEbAAoJEBzZQR2yrxj7jVMQALWoMkXzxapjYlBaGtOk5eyd |
70 |
XQQuWH6m4U+9DrzQRJEeaCivIJmzXHPAVU6Rd40gBGqlSTMoJKm2pIMkxGvDLLd7 |
71 |
zIwuPolamQhFM0vhkUOidfgBqvCbFJV5rFTKtIPXg28JivoY7omi4/oANd0V8L7A |
72 |
YRik152d2cFW+rdITLhgf3JNky99yOy4NR3SYB/dQY+E8D+5RaCXjy/EqjNqbsin |
73 |
To+/far3d5e2/Z7dDlfyuhYyG6dwbFl8vY7RN+eERH68GTqj2bjy2EL0T9FAVwWI |
74 |
O9i4T1sRIneYVfd3MEoLwkPHjhfDOmP/zLloFaqT9AUtiVlVf9vMy5dKXHva1OTe |
75 |
cmNicf66YBsSD2J6mMRHE4N7iTn8tpI5W7+WpXa2gyEeqWwDwbENxNU1IHlZ0Ys7 |
76 |
cHpfhkx63oWwvDQX3XKjl1fUjoVEoJ/6HhHNWboLaAxJ/XUcZCAGNEaF9NVtE0FN |
77 |
VUFmU7ZU1GLkk+MAKxpwdMqa9+LJ+Sr+4/NzF1ceE54yoq0ks+PfafyMybseOptK |
78 |
bKbiAQ4/GvDB3Tpw4S2QuqYZ3pT/enxYET3v8YxVPE6Hw79RYeaMtEEnm0Niy29k |
79 |
CHUT6T0Ul3IfS6LQZtEwC40Izs/usM+HH2XuYP3OfkBLgK8LUhEUcVNiC6B6frUD |
80 |
M6d04xGeSvDVMo9vBoYb |
81 |
=Fufx |
82 |
-----END PGP SIGNATURE----- |