[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests)
From:       Kristian Fiskerstrand <k_f () gentoo ! org>
Date:       2015-07-17 9:56:06
Message-ID: 55A8D136.4080105 () gentoo ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/17/2015 11:48 AM, hasufell wrote:
> On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote:
>> On 07/17/2015 03:13 AM, NP-Hardass wrote:
>> 
>>> Additionally, I feel that a signature is a means of
>>> acknowledging that a package has been looked over, and that
>>> developer has stated that they approve of the existing state.
>>> I'm not sure if others agree with that sentiment,
>> 
>> I appreciate that you bring up this point. I would expect that
>> part of that state is for the developer to verify the source
>> distfile from upstream using OpenPGP / GnuPG as well, i.e not
>> just rely on TOFU (trust on first use). This also means keeping a
>> (locally) certified copy of the upstream distribution key that is
>> reasonably verified by the developer.
>> 
> 
> This really depends. In general, a signed commit can and should
> only say that the _patch_ comes from or was approved by a
> particular person. If it's a version bump on a single package, you
> can probably assume that he had a rough lookover. But you can't
> expect the same when e.g. the python herd has to do mass commits
> because of USE flag changes.
> 

I was referring to process during a version bump, the manifest entry
for the distfile shouldn't be changed during a USE flag change, so in
this case that verification would be brought along from the developer
doing the bump.

> That "approve of existing state" thing is rather implicit in a
> review workflow, where the package maintainer does the merge. We
> currently don't have any plans to enforce this globally, so
> signatures just say "this patch comes from...".

Not all do, as mentioned the push can be signed, e.g while an
individual commit is signed by another (potentially a non-gentoo-dev).

All I'm trying to say is really (and this isn't specific to the git
workflow); Please take it as a reminder to verify upstream OpenPGP
signatures when bumping packages, and please make an effort to
maintain proper key management practices while doing so so you can do
it properly.

If we don't we have a case of purgamentum init, exit purgamentum
(garbagin in, garbage out)

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJVqNEnAAoJECULev7WN52FohUIAIQrKGb7urSmzWFyIfF00FSr
i+arpIMbClzyUf6fwulf22fkE0UjBykoodA6p67dxakgWOEpHkpoUW7Z3v8eyPu8
+UHzV67sNgoEnJW4PASyrOABMkpi5oHr2nGSq6oHwHG5oXnw9askEH8srThBTwNx
Kflo4mzxSpbgIrbfawFERWPBTtwU1P1WLAVSKRz6GkPAKuY/ypjMeFJ2TSdPeapR
TYLhgSUa/3gUOZx7OBJpYxqU2j7WOnGwxMsReJVnMykB4LOv7SRXzXSM+6r0Q+os
bWv2wKUfOPwoOCMD+F0nIFZ/85T7wSiZxemM5T85+FFL6xl4hXgZr8GUwJU9iB4=
=NylE
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]