| 1 |
On 15 September 2014 22:10, Jauhien Piatlicki <jauhien@g.o> wrote: |
| 2 |
|
| 3 |
> So signing of git commits does not guarantee enough security (taking |
| 4 |
> that SHA1 is weak and can be broken), right? Could we than just use |
| 5 |
> usual (not thin) manifests? |
| 6 |
> |
| 7 |
|
| 8 |
However, the attackability of SHA1 may be entirely immaterial, because |
| 9 |
methods to exploit that require compromising other security strategies. |
| 10 |
|
| 11 |
If somebody pushes signed commit 0x0001 with parents 0x0002 and 0x0003 |
| 12 |
with tree 0x0004 with files 0x0005 to 0x0010, those binary blobs are |
| 13 |
pushed. And there is no way I know of to have those binary blobs replaced |
| 14 |
with cuckoo blobs. |
| 15 |
|
| 16 |
Once they're replicated, Git doesn't try re-replicating the same SHA1s. |
| 17 |
|
| 18 |
So your attack vectors entail directly manipulating the git storage on |
| 19 |
gentoo's servers, or poisoning a mirror under their control, or poisoning |
| 20 |
the data *PRIOR* to it landing on gentoo servers, or being NSA and |
| 21 |
poisoning it dynamically when a user attempts to fetch that specific SHA1. |
| 22 |
|
| 23 |
None of these are impossible things, but they're much more complex than |
| 24 |
"just make a dodgy commit and get somebody to pull it". |
| 25 |
|
| 26 |
This basically means you could use CRC32 as your hash algorithm and still |
| 27 |
pose a respectable problem for would-be attackers. |
| 28 |
|
| 29 |
As such, I don't presently see git commit signing as a "Security" model, |
| 30 |
merely a proof of authorship model. Anybody can forge commits with your |
| 31 |
'author = ' and 'committer = ', but you're the only person who can sign |
| 32 |
the commit with your signature. |
| 33 |
|
| 34 |
That is to say, you sign that you crafted the *commit*. But you're *not* |
| 35 |
signing the creation of any of the dependencies. |
| 36 |
|
| 37 |
For instance, two commits may have the same tree, but obviously only one |
| 38 |
person forged that tree object. |
| 39 |
|
| 40 |
And two trees may have the same file ( and indeed, this is an expected |
| 41 |
element of how git works ), but you're not signing that you created all the |
| 42 |
files in that tree. You may infer that from the chain of authority from the |
| 43 |
commit itself, but it is not fact. |
| 44 |
|
| 45 |
And parent objects are also dependencies, and nobody would ever consider |
| 46 |
claiming they're a signing authority for all of that ;), that would be by |
| 47 |
proxy signing the creation of the entire repository back to the first |
| 48 |
commit ever forged! .... and its for that reason its probably good that git |
| 49 |
doesn't presently recursively feed all dependencies of a commit into GPG. I |
| 50 |
don't have 5 hours while every single blob in my repository is uncompressed |
| 51 |
and fed through GPG :p |
| 52 |
|
| 53 |
|
| 54 |
-- |
| 55 |
Kent |
| 56 |
|
| 57 |
*KENTNL* - https://metacpan.org/author/KENTNL |
Archives