Extending this reasoning to git, I guess the "security best practices" for vendors should now be: always have your own commit at HEAD?https://twitter.com/rootkovska/status/834868944376852482 …
-
-
Replying to @rootkovska
Otherwise the attacker might give us a benign commit which we happily merge (since benign), but have the colliding one to feed to our users.
2 replies 2 retweets 4 likes -
Replying to @rootkovska
Yup, and on top of that, this isn't just a commit level problem, but also a *file-level* problem.
2 replies 0 retweets 1 like -
Replying to @peterktodd @petertoddbtc
I'm somehow skeptical that this might work for anything other than binary blobs in PR?
1 reply 0 retweets 0 likes -
Replying to @rootkovska
Binary blobs are the most likely problem, but it may be possible to extend the attack to more limited character sets. :(
1 reply 0 retweets 1 like -
Replying to @peterktodd @petertoddbtc
... which would also happen to be a valid string in the context of the commit? E.g. valid Python or C code?
1 reply 0 retweets 0 likes -
Replying to @rootkovska
Like I say, it's less likely, but not implausible.
1 reply 0 retweets 0 likes -
Replying to @peterktodd @rootkovska
Tree objects may be the more concerning thing, because likely possible to hide extra data at the end of a tree obj from review.
3 replies 0 retweets 4 likes
Shouldn't it be possible to enhance git to reject/report tree objects with extra junk at the end?
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.