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