| 1 |
On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: |
| 2 |
> On 07/17/2015 03:13 AM, NP-Hardass wrote: |
| 3 |
> |
| 4 |
>> Additionally, I feel that a signature is a means of acknowledging |
| 5 |
>> that a package has been looked over, and that developer has stated |
| 6 |
>> that they approve of the existing state. I'm not sure if others |
| 7 |
>> agree with that sentiment, |
| 8 |
> |
| 9 |
> I appreciate that you bring up this point. I would expect that part of |
| 10 |
> that state is for the developer to verify the source distfile from |
| 11 |
> upstream using OpenPGP / GnuPG as well, i.e not just rely on TOFU |
| 12 |
> (trust on first use). This also means keeping a (locally) certified |
| 13 |
> copy of the upstream distribution key that is reasonably verified by |
| 14 |
> the developer. |
| 15 |
> |
| 16 |
|
| 17 |
This really depends. In general, a signed commit can and should only say |
| 18 |
that the _patch_ comes from or was approved by a particular person. If |
| 19 |
it's a version bump on a single package, you can probably assume that he |
| 20 |
had a rough lookover. But you can't expect the same when e.g. the python |
| 21 |
herd has to do mass commits because of USE flag changes. |
| 22 |
|
| 23 |
That "approve of existing state" thing is rather implicit in a review |
| 24 |
workflow, where the package maintainer does the merge. We currently |
| 25 |
don't have any plans to enforce this globally, so signatures just say |
| 26 |
"this patch comes from...". |
Archives