On Wed, Aug 03, 2016 at 10:35:39AM -0700, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torres <santiago@xxxxxxx> wrote: > > On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote: > >> On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres <santiago@xxxxxxx> wrote: > >> > > share things before they are published. Thankfully, this is OK in > >> >> > USENIX's book. Here's the link: > >> >> > http://i2.cdn.turner.com/cnnnext/dam/assets/160730192650-14new-week-in-politics-super-169.jpg > >> >> > >> >> While I had a good laugh, I am wondering whether this is the correct link? > >> > > >> > Oh my god, sorry, I meant to p, not to ctrl + v. My head is all over the > >> > place as of late. > >> > > >> > Here's the correct link: > >> > > >> > http://isis.poly.edu/~jcappos/papers/torres_toto_usenixsec-2016.pdf > >> > >> In 4.1 you write: > >> > Finally, Git submodules are also vulnerable, as they automatically track > >> > a tag (or branch). If a build dependency is included in a project as a part > >> > of the submodule, a package might be vulnerable via an underlying library. > >> > >> Submodules actually track commits, not tags or branches. > >> > >> This is confusing for some users, e.g. the user intended to track > >> a library at version 1.1, but it tracks 1234abcd instead (which is what > >> 1.1 points at). > > > > I'm assuming that git submodule update does update where the ref points > > to, does it not? > > > > let me dig into this and try to take the necessary measures to correct > > this > > > > "git submodule update" updates to the recorded sha1, which I assume is used > by downstream users. If you are a maintainer and you want to update the > library used, you'd be interested in have "git submodule update > --remote" to update > the sha1 to the tracking branch, which then exposes the attacks presented. I see, I just tried to reproduce this, and it seems that, with a simple git clone --recursive [path], the submodule fetched does not update to the "malicious ref." You're right. So, in the end, git submodule update --remote also requires you to create a new tree, right? Then this attack wouldn't be possible by just fiddling with the refs if signing is in place, right? Thanks for clarifying! -Santiago. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html