| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 07/17/2015 11:48 AM, hasufell wrote: |
| 5 |
> On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: |
| 6 |
>> On 07/17/2015 03:13 AM, NP-Hardass wrote: |
| 7 |
>> |
| 8 |
>>> Additionally, I feel that a signature is a means of |
| 9 |
>>> acknowledging that a package has been looked over, and that |
| 10 |
>>> developer has stated that they approve of the existing state. |
| 11 |
>>> I'm not sure if others agree with that sentiment, |
| 12 |
>> |
| 13 |
>> I appreciate that you bring up this point. I would expect that |
| 14 |
>> part of that state is for the developer to verify the source |
| 15 |
>> distfile from upstream using OpenPGP / GnuPG as well, i.e not |
| 16 |
>> just rely on TOFU (trust on first use). This also means keeping a |
| 17 |
>> (locally) certified copy of the upstream distribution key that is |
| 18 |
>> reasonably verified by the developer. |
| 19 |
>> |
| 20 |
> |
| 21 |
> This really depends. In general, a signed commit can and should |
| 22 |
> only say that the _patch_ comes from or was approved by a |
| 23 |
> particular person. If it's a version bump on a single package, you |
| 24 |
> can probably assume that he had a rough lookover. But you can't |
| 25 |
> expect the same when e.g. the python herd has to do mass commits |
| 26 |
> because of USE flag changes. |
| 27 |
> |
| 28 |
|
| 29 |
I was referring to process during a version bump, the manifest entry |
| 30 |
for the distfile shouldn't be changed during a USE flag change, so in |
| 31 |
this case that verification would be brought along from the developer |
| 32 |
doing the bump. |
| 33 |
|
| 34 |
> That "approve of existing state" thing is rather implicit in a |
| 35 |
> review workflow, where the package maintainer does the merge. We |
| 36 |
> currently don't have any plans to enforce this globally, so |
| 37 |
> signatures just say "this patch comes from...". |
| 38 |
|
| 39 |
Not all do, as mentioned the push can be signed, e.g while an |
| 40 |
individual commit is signed by another (potentially a non-gentoo-dev). |
| 41 |
|
| 42 |
All I'm trying to say is really (and this isn't specific to the git |
| 43 |
workflow); Please take it as a reminder to verify upstream OpenPGP |
| 44 |
signatures when bumping packages, and please make an effort to |
| 45 |
maintain proper key management practices while doing so so you can do |
| 46 |
it properly. |
| 47 |
|
| 48 |
If we don't we have a case of purgamentum init, exit purgamentum |
| 49 |
(garbagin in, garbage out) |
| 50 |
|
| 51 |
- -- |
| 52 |
Kristian Fiskerstrand |
| 53 |
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net |
| 54 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
| 55 |
-----BEGIN PGP SIGNATURE----- |
| 56 |
|
| 57 |
iQEcBAEBCgAGBQJVqNEnAAoJECULev7WN52FohUIAIQrKGb7urSmzWFyIfF00FSr |
| 58 |
i+arpIMbClzyUf6fwulf22fkE0UjBykoodA6p67dxakgWOEpHkpoUW7Z3v8eyPu8 |
| 59 |
+UHzV67sNgoEnJW4PASyrOABMkpi5oHr2nGSq6oHwHG5oXnw9askEH8srThBTwNx |
| 60 |
Kflo4mzxSpbgIrbfawFERWPBTtwU1P1WLAVSKRz6GkPAKuY/ypjMeFJ2TSdPeapR |
| 61 |
TYLhgSUa/3gUOZx7OBJpYxqU2j7WOnGwxMsReJVnMykB4LOv7SRXzXSM+6r0Q+os |
| 62 |
bWv2wKUfOPwoOCMD+F0nIFZ/85T7wSiZxemM5T85+FFL6xl4hXgZr8GUwJU9iB4= |
| 63 |
=NylE |
| 64 |
-----END PGP SIGNATURE----- |
Archives