On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torres <santi...@nyu.edu> 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 <santi...@nyu.edu> 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. Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
