| 1 |
On Wednesday 18 February 2009, Robin H. Johnson wrote: |
| 2 |
> Using the converse, all files covered by AUX, DIST, MISC have GIT |
| 3 |
> SHA1 commit ids. Explicitly performing a checksum on them is not |
| 4 |
> needed, just extract it from Git. |
| 5 |
|
| 6 |
These hashes would need to be regenerated for the rsync though, because |
| 7 |
otherwise it does not provide integrity and this would make tree |
| 8 |
signing impossible. Overlays would have to abandon the hashes though, |
| 9 |
otherwise you'll get the same merge trouble again. |
| 10 |
|
| 11 |
|
| 12 |
> When it comes to generating the outgoing Manifests for users on the |
| 13 |
> central server, it's pretty simple. |
| 14 |
> |
| 15 |
> The only downside I see is the potential for a degree of lesser |
| 16 |
> security for anybody using the Git repo directly instead of rsync. |
| 17 |
|
| 18 |
It'll also ease attacks on distfiles when first mirroring them. |
| 19 |
Currently, developers download the code (verify checksums, gpg, or |
| 20 |
review the code, ... at least sometimes) and then commit the hash of |
| 21 |
what they have seen. The distfiles master box then verifies that hash |
| 22 |
and users only ever can install it if it's the same the dev had seen. |
| 23 |
If the distfiles master is the one generating that hash, there is (1) a |
| 24 |
time gap between the dev reviewing the file and the box getting the |
| 25 |
hash and (2) only one box would need to be attacked via |
| 26 |
man-in-the-middle, whereas it is currently two. |
| 27 |
|
| 28 |
|
| 29 |
Robert |
Archives