{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-02-23\n📝 Original message:Worth noting: the impact of the SHA1 collison attack on Git is *not* limited\nonly to maintainers making maliciously colliding Git commits, but also\nthird-party's submitting pull-reqs containing commits, trees, and especially\nfiles for which collisions have been found. This is likely to be exploitable in\npractice with binary files, as reviewers aren't going to necessarily notice\ngarbage at the end of a file needed for the attack; if the attack can be\nextended to constricted character sets like unicode or ASCII, we're in trouble\nin general.\n\nConcretely, I could prepare a pair of files with the same SHA1 hash, taking\ninto account the header that Git prepends when hashing files. I'd then submit\nthat pull-req to a project with the \"clean\" version of that file. Once the\nmaintainer merges my pull-req, possibly PGP signing the git commit, I then take\nthat signature and distribute the same repo, but with the \"clean\" version\nreplaced by the malicious version of the file.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170223/fe8c9937/attachment.sig\u003e"}