| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Sorry, |
| 5 |
I lost my notes from when I last looked these over several months ago, |
| 6 |
and only just found them again. I haven't copied this to gleps@g.o, so |
| 7 |
let me know if I should do that. I just had a quick couple of things I |
| 8 |
was thinking about, and one of them I figured out during my re-read, so |
| 9 |
it's only really the following... |
| 10 |
|
| 11 |
In this Glep (xx+1), in the section discussing the procedure for |
| 12 |
creating a MetaManifest file, in step 3.3, does that include |
| 13 |
verification of the manifest's signature if it has one? It would seem |
| 14 |
odd to ignore the signature if it's wrong (I'm not sure about the case |
| 15 |
if a signature isn't present). I also don't know how this would then be |
| 16 |
handled (a complete abort, or ignoring the latest changeset to that |
| 17 |
ebuild?). |
| 18 |
If the signature check happened here, it could also allow for |
| 19 |
enforcable revocation of developer certificates (once they're revoked, |
| 20 |
any signed manifests will have the ebuild changes ignored). That may be |
| 21 |
a lot of work and may take too long, but if not (and depending on our |
| 22 |
users' trust needs), it might allow them just to check the |
| 23 |
MetaManifest's signature, and not that of the individual packages. Does |
| 24 |
that seems sensible? |
| 25 |
|
| 26 |
I've probably missed a key issue somewhere along the way, in which |
| 27 |
case, sorry, and do feel free to chide me liberally... 5:) |
| 28 |
Mike 5:) |
| 29 |
-----BEGIN PGP SIGNATURE----- |
| 30 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 31 |
|
| 32 |
iEYEARECAAYFAkiPdNAACgkQu7rWomwgFXoJ9gCeLZOvpGAyr+EzI/d8EKWrnqnf |
| 33 |
CVoAoI63EiYvB4+1cBSURIlRxaH0xy4o |
| 34 |
=yZH7 |
| 35 |
-----END PGP SIGNATURE----- |
Archives