| 1 |
Rich Freeman posted on Sun, 01 May 2011 19:43:48 -0400 as excerpted: |
| 2 |
|
| 3 |
> On Sun, May 1, 2011 at 7:31 PM, Brian Harring <ferringb@×××××.com> |
| 4 |
> wrote: |
| 5 |
>> Get at that key, and you've got the tree, versus the current form, |
| 6 |
>> crack all signing keys and you've got the tree. |
| 7 |
> |
| 8 |
> Well, more like get any one of the keys and you get the tree, since |
| 9 |
> portage only validates that a trusted key signed a package, and not that |
| 10 |
> the key belonged to the package maintainer. |
| 11 |
|
| 12 |
OK, so everything in a manifest signs together, and if the changelog as-is |
| 13 |
gets server-signed, so does the rest of the manifest. |
| 14 |
|
| 15 |
I see the problem there, but there are ways around it. As I said, changes |
| 16 |
may be necessary, but they aren't huge compared to the scope of the whole |
| 17 |
idea. |
| 18 |
|
| 19 |
What about having the server-generated changelogs separate from the rest |
| 20 |
of the package, say in a changelogs dir, one such dir per category with |
| 21 |
for example portage's changelog then located at |
| 22 |
sys-apps/changelogs/portage, thus preventing between-category naming |
| 23 |
collisions (we've been there!)? |
| 24 |
|
| 25 |
Then the server could generate and sign the changelogs without interfering |
| 26 |
with the package manifests and their signatures. The changelogs would all |
| 27 |
be signed by the same key, but it wouldn't be used for signing anything |
| 28 |
else, thus not interfering with actual package security at all. |
| 29 |
|
| 30 |
-- |
| 31 |
Duncan - List replies preferred. No HTML msgs. |
| 32 |
"Every nonfree program has a lord, a master -- |
| 33 |
and if you use the program, he is your master." Richard Stallman |
Archives