Re: [OT] USENIX paper on Git
On Wed, 3 Aug 2016, Santiago Torres wrote: So if you want to treat Git as a cryptographic end-to-end distribution mechanism, then no, it fails horribly at that. But the state of the art in source code distribution, no matter which system you use, is much less advanced than that. People download tarballs, even ones with GPG signatures, all the time without verifying their contents. Most packages distribute a sha1sum or similar (sometimes even gpg-signed), but quite often the source of authority is questionable. Yes, this happens an awful lot of times. We did some work with python's pypi last year, and we found out that less than 1% of people actually downloaded the gpg signature for the package they are retrieving[1]. For example, consider somebody downloading a new package for the first time. They don't know the author in any out-of-band way, so any signatures are likely meaningless. They _might_ be depending on the source domain for some security (and using some hierarchical PKI like TLS+x.509 to be sure they're talking to that domain), but in your threat model, even well-known hosts like FSF could be compromised internally. So yes, I think the current state of affairs (especially open-source) is that people download and run possibly-compromised code all the time. But I'm not sure that lack of tool support is really the limiting factor. Or that it has turned out to be all that big a problem in practice. I couldn't agree more. I feel that OSS is slowly moving towards a more cryptographically robust, trust-based way of doing things, which I find pleasing. It's too easy to look at this from purely a technical, cryptographic point of view and miss a very important point. It may be very easy to see that this was signed by "cool-internet-name" but how can I tell if this is really Joe Blow the developer? and if it is, I still have no way of knowing if he's working for the NSA or not. The lack of meaningful termination of the signatures to the real world is why so few people bother to check package signatures, etc. David Lang -- 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
Re: [OT] USENIX paper on Git
On Wed, Aug 03, 2016 at 01:58:54PM -0400, Jeff King wrote: > On Wed, Aug 03, 2016 at 01:45:00PM -0400, Santiago Torres wrote: > > > > - if there is a chain of signatures, the attacker must follow the > > > chain, but they can always withhold links from the end. So imagine a > > > repository has held a sequence of signed states (A, B, C), that B > > > has a bug, C has the fix, and I am at A. An attacker can serve me B > > > and I cannot know without out-of-band information that it is not the > > > correct tip (because until C was created, it _was_ the correct tip). > > > > I think we address this by using the "nonce bag". We basically force the > > server to fork the user's history if it withholds changes from on group > > to the other. By doing so, the user's nonce can't be added to any other > > history. I don't think this is noticeable from start though. > > OK, I think that is in the details I glossed over. ;) > > If you are effectively preventing the server from showing different > states to different people, then at least that lets the "main" > developers notice problems (because at least one of them already saw "C" > because they wrote it). yeah, that was one of our assumptions. I think it's unrealistic to think that people do not coordinate over mailing lists or other means. > > > > I think git in general is quite weak in automatic tooling for > > > verifications. There are room for signatures in the data format and > > > tools for checking that the bytes haven't been touched, but there's > > > almost nothing to tell you that signatures make any sense, tools for > > > handling trust, etc. > > > > Yes, from our previous interactions, it seems that git's philosophy > > focuses on providing the right information to users/tools and let those > > tools make the call of whether something is fishy. I don't think this is > > necessarily bad. > > I think it's half philosophy (git strives for flexibility, and so aims > to provide low-level tooling that you can build on), and half that > nobody has bothered to implement a sane set of automatic checks. > > There's definitely some low-hanging fruit there. I think we've discussed > things like checking that verifying refs/tags/v1.0.0 actually gets you a > tag that says "v1.0.0" in it. But I'd love to see a framework either > built into or on top of git that would implement sensible policies, and > make out-of-the-box verification easy to do. Then people might actually > use it. :) Yeah, that's one of the long-term goals with my PhD, but it's still on the early stages, and I don't have much done yet in that field. I can of course share this around once it's more mature if that's ok with people in here :) > > > > I think your solution also had some mechanisms for adding trusted keys > > > as part of the hash chain. I'm not convinced that's something that > > > should be part of git's solution in particular, and not an out-of-band > > > thing handled as part of the PKI. Because it's really a group key > > > management problem, and applies to anything you might sign. > > > > I see. What about, for example, having an official "overlay" on git for > > signing and verification of a repository? (e.g., similar to what > > monotone does). I see that other VCS's have a plugin mechanism, and they > > host official plugins. > > In general, if something is more general than git, I'd like to see a > general tool address it, and then add support to git to make use of the > tool. > > For group key management, I specifically was wondering if you could do > something like: > > - start with some seed GPG keys for the project > > - existing keys can sign or revoke certificates to add or remove other > keys to/from the project; you could even require a threshold of > signatures, etc. > > - those keys could be used for signing git pushes, but also for other > things, like signing tarballs, used as encryption keys for sending > for-developers-eyes-only security reports, etc > > You'd want a tool that asks not just "is this signed" but "is this > signed _by a key that is valid for this project_". Yep and also "is this signed thing the thing I should be looking at?" > > And then git support would just consist of feeding signatures to > "gpg-group --project=..." instead of "gpg". Management of the group > would be out-of-band from git, which is in some ways good and in some > ways bad. yep, what I like from in-band solution is that it is easy to piggyback on existing git mechanisms (e.g., git ref backend). > > I think a naive implementation would be pretty easy, but I've glossed > over all of the chaining properties we've discussed. So whatever > mechanism you use to receive updates to the key-group would have all the > same problems (e.g., withholding revocations of compromised keys). It's > still orders of magnitude ahead of what's currently happening > day-to-day. :) yeah, a naive implementation may be
Re: [OT] USENIX paper on Git
On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torreswrote: > On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote: >> On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres 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
Re: [OT] USENIX paper on Git
On Wed, Aug 03, 2016 at 10:35:39AM -0700, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 10:22 AM, Santiago Torreswrote: > > On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote: > >> On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torres 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OT] USENIX paper on Git
On Wed, Aug 03, 2016 at 01:45:00PM -0400, Santiago Torres wrote: > > - if there is a chain of signatures, the attacker must follow the > > chain, but they can always withhold links from the end. So imagine a > > repository has held a sequence of signed states (A, B, C), that B > > has a bug, C has the fix, and I am at A. An attacker can serve me B > > and I cannot know without out-of-band information that it is not the > > correct tip (because until C was created, it _was_ the correct tip). > > I think we address this by using the "nonce bag". We basically force the > server to fork the user's history if it withholds changes from on group > to the other. By doing so, the user's nonce can't be added to any other > history. I don't think this is noticeable from start though. OK, I think that is in the details I glossed over. ;) If you are effectively preventing the server from showing different states to different people, then at least that lets the "main" developers notice problems (because at least one of them already saw "C" because they wrote it). > > I think git in general is quite weak in automatic tooling for > > verifications. There are room for signatures in the data format and > > tools for checking that the bytes haven't been touched, but there's > > almost nothing to tell you that signatures make any sense, tools for > > handling trust, etc. > > Yes, from our previous interactions, it seems that git's philosophy > focuses on providing the right information to users/tools and let those > tools make the call of whether something is fishy. I don't think this is > necessarily bad. I think it's half philosophy (git strives for flexibility, and so aims to provide low-level tooling that you can build on), and half that nobody has bothered to implement a sane set of automatic checks. There's definitely some low-hanging fruit there. I think we've discussed things like checking that verifying refs/tags/v1.0.0 actually gets you a tag that says "v1.0.0" in it. But I'd love to see a framework either built into or on top of git that would implement sensible policies, and make out-of-the-box verification easy to do. Then people might actually use it. :) > > I think your solution also had some mechanisms for adding trusted keys > > as part of the hash chain. I'm not convinced that's something that > > should be part of git's solution in particular, and not an out-of-band > > thing handled as part of the PKI. Because it's really a group key > > management problem, and applies to anything you might sign. > > I see. What about, for example, having an official "overlay" on git for > signing and verification of a repository? (e.g., similar to what > monotone does). I see that other VCS's have a plugin mechanism, and they > host official plugins. In general, if something is more general than git, I'd like to see a general tool address it, and then add support to git to make use of the tool. For group key management, I specifically was wondering if you could do something like: - start with some seed GPG keys for the project - existing keys can sign or revoke certificates to add or remove other keys to/from the project; you could even require a threshold of signatures, etc. - those keys could be used for signing git pushes, but also for other things, like signing tarballs, used as encryption keys for sending for-developers-eyes-only security reports, etc You'd want a tool that asks not just "is this signed" but "is this signed _by a key that is valid for this project_". And then git support would just consist of feeding signatures to "gpg-group --project=..." instead of "gpg". Management of the group would be out-of-band from git, which is in some ways good and in some ways bad. I think a naive implementation would be pretty easy, but I've glossed over all of the chaining properties we've discussed. So whatever mechanism you use to receive updates to the key-group would have all the same problems (e.g., withholding revocations of compromised keys). It's still orders of magnitude ahead of what's currently happening day-to-day. :) -Peff -- 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
Re: [OT] USENIX paper on Git
On Wed, Aug 03, 2016 at 10:35:54AM -0700, Junio C Hamano wrote: > Santiago Torreswrites: > > >> 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? > > I think you may configure the command to do so, instead of the default > "detach at the commit recorded in the superproject". > > But then your tree immediately will be marked by "git status" as > "modified" at such a submodule, meaning "what you have in the working > tree is different from what the commit in the superproject wants you > to have", I would think. > Ah, I see where is my confusion. Thanks for the correction :) -Santiago. -- 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
Re: [OT] USENIX paper on Git
Santiago Torreswrites: >> 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? I think you may configure the command to do so, instead of the default "detach at the commit recorded in the superproject". But then your tree immediately will be marked by "git status" as "modified" at such a submodule, meaning "what you have in the working tree is different from what the commit in the superproject wants you to have", I would think. -- 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
Re: [OT] USENIX paper on Git
Hello, > Here are my comments on the work itself. They're critical, but meant in > a friendly way. :) > Thanks! If anything, the community here has been incredibly helpful in helping me understand everything. > As far as the attack goes, I'm still not convinced this is all that > _interesting_ an attack in the real world. What it boils down to is: the > ref state is not signed or authenticated in any way, so somebody who can > compromise your server repo or do a MiTM can lie about where the refs > are (even if individual commits are signed). Yup, that's pretty much it. I do agree that some of these attacks feel tangential in the way it should be used. I also agree that, if git is used how the Linux kernel or git.git does, then these attacks are rather hard to pull off. > > So if you want to treat Git as a cryptographic end-to-end distribution > mechanism, then no, it fails horribly at that. But the state of the art > in source code distribution, no matter which system you use, is much > less advanced than that. People download tarballs, even ones with GPG > signatures, all the time without verifying their contents. Most packages > distribute a sha1sum or similar (sometimes even gpg-signed), but quite > often the source of authority is questionable. Yes, this happens an awful lot of times. We did some work with python's pypi last year, and we found out that less than 1% of people actually downloaded the gpg signature for the package they are retrieving[1]. > > For example, consider somebody downloading a new package for the first > time. They don't know the author in any out-of-band way, so any > signatures are likely meaningless. They _might_ be depending on the > source domain for some security (and using some hierarchical PKI like > TLS+x.509 to be sure they're talking to that domain), but in your threat > model, even well-known hosts like FSF could be compromised internally. > > So yes, I think the current state of affairs (especially open-source) is > that people download and run possibly-compromised code all the time. But > I'm not sure that lack of tool support is really the limiting factor. Or > that it has turned out to be all that big a problem in practice. I couldn't agree more. I feel that OSS is slowly moving towards a more cryptographically robust, trust-based way of doing things, which I find pleasing. > > Anyway. As far as your solution goes, I'll admit I skimmed over the > details, but it looks like basically a sequence of signatures producing > a chain of state (so the tip state is signed, but you can also make sure > the chain connects from your current state to what the server claims is > the new tip state, and not a replay of some old state). Please correct > me if that's not accurate. :) Yeah, this sounds about right. > > Without having thought too hard about it, it seems like you could do the > same thing with push certs, as they have both a "before" and "after" for > each ref. So if in addition to fetching the refs from a server, I fetch > all of the push certs, I should be able to walk the chain of push certs > from the one at my current state, to the one at the tip state, making > sure that each one builds on the last. Yeah, when we looked at push certs I actually thought that "chaining" the certs could achieve a similar effect to the solution I described. > > There are two cases that I don't think that handles, but that I also > don't see are handled in your solution: > > - if I am cloning for the first time, I have no "current" state to > base the chain from. An attacker could serve me any old signed ref > state, and I have no way to know that it's old (except perhaps by > seeing the wall-clock timestamp and comparing it to my clock; this > isn't a proof but may be cause for suspicion if it's too old) Hmm, I didn't think about it. Let me jot it down. This sounds interesting. I recall you mentioning metadata expiration back then. > > - if there is a chain of signatures, the attacker must follow the > chain, but they can always withhold links from the end. So imagine a > repository has held a sequence of signed states (A, B, C), that B > has a bug, C has the fix, and I am at A. An attacker can serve me B > and I cannot know without out-of-band information that it is not the > correct tip (because until C was created, it _was_ the correct tip). I think we address this by using the "nonce bag". We basically force the server to fork the user's history if it withholds changes from on group to the other. By doing so, the user's nonce can't be added to any other history. I don't think this is noticeable from start though. > > I think this is actually a generalization of the cloning issue > (where state "A" is simply "I have no existing state yet"). > > So it seems like there is room for better tooling around push-certs > (e.g., to fetch and verify the chaining automatically). Yeah, I think that in-band cert
Re: [OT] USENIX paper on Git
Jeff Kingwrites: > Here are my comments on the work itself. They're critical, but meant in > a friendly way. :) A tl;dr version of your analysis seems to me that "you solve it the same way as the push certificate solves it (including the limitation the latter has)". If that is the case, I think the solution presented in the paper is a good one ;-). -- 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
Re: [OT] USENIX paper on Git
On Wed, Aug 03, 2016 at 10:14:21AM -0700, Stefan Beller wrote: > On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torreswrote: > > > 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 Thanks for the feedback! -Santiago. -- 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
Re: [OT] USENIX paper on Git
On Wed, Aug 3, 2016 at 8:25 AM, Santiago Torreswrote: > > 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). Thanks, Stefan > > Thanks! > -Santiago. > -- > 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 -- 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
Re: [OT] USENIX paper on Git
On Wed, Aug 03, 2016 at 10:58:31AM -0400, Santiago Torres wrote: > I will be presenting a paper regarding the Git metadata issues that we > discussed at the beginning on the year on USENIX '16. I'm writing To > make everyone in this ML aware that this work exists and to bring > everyone into the loop. > > I'm open for feedback and corrections. If anything seems odd imprecise > to the community, I can make an errata in the presentation (at least). > I'll also try to work towards making corrections anywhere if possible; > this is my first publication, so I wasn't sure if it was possible to > share things before they are published. Thankfully, this is OK in > USENIX's book. Here's the link: I read it over. As far as technical descriptions of Git, it looked OK. I found a few minor nits, but nothing worth caring about (e.g., ref storage is not quite so simple these days as 40 bytes in a file, but there is no point describing the whole packed-refs scheme in your paper, as it does not change anything with respect to your work). Here are my comments on the work itself. They're critical, but meant in a friendly way. :) As far as the attack goes, I'm still not convinced this is all that _interesting_ an attack in the real world. What it boils down to is: the ref state is not signed or authenticated in any way, so somebody who can compromise your server repo or do a MiTM can lie about where the refs are (even if individual commits are signed). So if you want to treat Git as a cryptographic end-to-end distribution mechanism, then no, it fails horribly at that. But the state of the art in source code distribution, no matter which system you use, is much less advanced than that. People download tarballs, even ones with GPG signatures, all the time without verifying their contents. Most packages distribute a sha1sum or similar (sometimes even gpg-signed), but quite often the source of authority is questionable. For example, consider somebody downloading a new package for the first time. They don't know the author in any out-of-band way, so any signatures are likely meaningless. They _might_ be depending on the source domain for some security (and using some hierarchical PKI like TLS+x.509 to be sure they're talking to that domain), but in your threat model, even well-known hosts like FSF could be compromised internally. So yes, I think the current state of affairs (especially open-source) is that people download and run possibly-compromised code all the time. But I'm not sure that lack of tool support is really the limiting factor. Or that it has turned out to be all that big a problem in practice. Anyway. As far as your solution goes, I'll admit I skimmed over the details, but it looks like basically a sequence of signatures producing a chain of state (so the tip state is signed, but you can also make sure the chain connects from your current state to what the server claims is the new tip state, and not a replay of some old state). Please correct me if that's not accurate. :) Without having thought too hard about it, it seems like you could do the same thing with push certs, as they have both a "before" and "after" for each ref. So if in addition to fetching the refs from a server, I fetch all of the push certs, I should be able to walk the chain of push certs from the one at my current state, to the one at the tip state, making sure that each one builds on the last. There are two cases that I don't think that handles, but that I also don't see are handled in your solution: - if I am cloning for the first time, I have no "current" state to base the chain from. An attacker could serve me any old signed ref state, and I have no way to know that it's old (except perhaps by seeing the wall-clock timestamp and comparing it to my clock; this isn't a proof but may be cause for suspicion if it's too old) - if there is a chain of signatures, the attacker must follow the chain, but they can always withhold links from the end. So imagine a repository has held a sequence of signed states (A, B, C), that B has a bug, C has the fix, and I am at A. An attacker can serve me B and I cannot know without out-of-band information that it is not the correct tip (because until C was created, it _was_ the correct tip). I think this is actually a generalization of the cloning issue (where state "A" is simply "I have no existing state yet"). So it seems like there is room for better tooling around push-certs (e.g., to fetch and verify the chaining automatically). I think git in general is quite weak in automatic tooling for verifications. There are room for signatures in the data format and tools for checking that the bytes haven't been touched, but there's almost nothing to tell you that signatures make any sense, tools for handling trust, etc. I think your solution also had some mechanisms for adding trusted keys as part of the hash chain. I'm not convinced that's something that
Re: [OT] USENIX paper on Git
> 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 Thanks! -Santiago. -- 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
Re: [OT] USENIX paper on Git
Hi Santiago, On Wed, 3 Aug 2016, Santiago Torres wrote: > I'm open for feedback and corrections. If anything seems odd imprecise > to the community, I can make an errata in the presentation (at least). > I'll also try to work towards making corrections anywhere if possible; > this is my first publication, so I wasn't sure if it was possible to > 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? Ciao, Johannes -- 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