| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 09/18/2015 10:58 AM, Justin (jlec) wrote: |
| 5 |
> Hello, |
| 6 |
> |
| 7 |
> there are quite a number of Manifest still not containing one or |
| 8 |
> more of the three hashes. I would like to update them as far as we |
| 9 |
> can download the sources. |
| 10 |
> |
| 11 |
> Procedure would be: 1. Download package 2. verify current hashes |
| 12 |
> match 3. Calculate new 4. commit |
| 13 |
> |
| 14 |
> Following question need to be answered first: |
| 15 |
> |
| 16 |
> Does anybody have any general objections, remarks or ideas on |
| 17 |
> that? |
| 18 |
|
| 19 |
As long as the current hashes are verified for the download I'm fine |
| 20 |
with this, but I'd like to take the opportunity to bring up a general |
| 21 |
note with regards to manifest generation and OpenPGP verification of |
| 22 |
source files. |
| 23 |
|
| 24 |
Now that we're hopefully getting closer to a fully signed OpenPGP |
| 25 |
Gentoo Tree, it is also important that package maintainers pay |
| 26 |
attention to OpenPGP signatures when generating the initial manifest |
| 27 |
files e.g. on a version bump. This also brings up some interesting key |
| 28 |
management issues with regards to ensuring that the package is signed |
| 29 |
with the correct key. Of course, where the maintainer has met the |
| 30 |
developer and cross-signed the keys, this part is relatively easy, as |
| 31 |
the key will have full validity or can be easily verified by one hope |
| 32 |
distance. |
| 33 |
|
| 34 |
Where this becomes more difficult is of course where no direct |
| 35 |
certification has been made, leading into more probabilistic |
| 36 |
approaches to determining key validity. I would expect maintainers of |
| 37 |
a package following the mailing lists giving a high expectation of the |
| 38 |
key being correct, and as such keeping a local copy of the keys used |
| 39 |
for distribution with a local signature (lsign in GnuPG's edit-key |
| 40 |
interface) marking this key as valid. |
| 41 |
|
| 42 |
We currently don't (well, I don't at least) store information about |
| 43 |
the file verification in the git commit messages, and I'm not sure if |
| 44 |
this is something that would be valuable exceeding the cost of the |
| 45 |
added message and finding a format to do so. But given that we're |
| 46 |
talking about the manifests, I do sincerely hope package maintainers |
| 47 |
have a well thought out setup for key management locally and in fact |
| 48 |
verify the OpenPGP signatures vs known good keys, and that appropriate |
| 49 |
measures are being taken in the case of non-maintainer commits that |
| 50 |
doesn't reduce the level of security. |
| 51 |
|
| 52 |
- -- |
| 53 |
Kristian Fiskerstrand |
| 54 |
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net |
| 55 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
| 56 |
-----BEGIN PGP SIGNATURE----- |
| 57 |
|
| 58 |
iQEcBAEBCgAGBQJV+9Z8AAoJECULev7WN52FgucH/jN6bwIe/AJuv6y2VkVC7gT2 |
| 59 |
pdtZY4hEv2TlVJUcGKgMfk5BWD2vm0vBdOCTwyPMgNXf+fnXv70507RmReecRiyB |
| 60 |
ouVgacu1nQYMCG2urvuQckXPdGfycbgk0ESe+XcKbRnOmmJ2a4ZVKENXk0TbA38Y |
| 61 |
hJ/c2boxpJiVZHF6JSPwfXBrC0j6GpRsLnce/vKybH0uDye4/7Q1Hw9R76KQDATd |
| 62 |
DB+hcAsQfonj7rDy4FoKviuiSiZmbHam0yCQGiBaR2fqQOc+erSJ29Hy+MLkdCCa |
| 63 |
Zy36sUv299u71J/9LYXuQBpeULV0XQ82ERz1VuJ6SV4YPYRtroqoKmnasA77Prw= |
| 64 |
=bV4C |
| 65 |
-----END PGP SIGNATURE----- |
Archives