{"thread":{"id":"37982","subject":"How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","startedAt":"2014-11-16T15:31:10Z","lastAt":"2014-11-25T17:23:10Z","messageCount":21,"participants":["Patrick Schleizer","Jeff King","Jason Pyeron","Duy Nguyen","Michael J Gruber","Nico Williams","Jonathan Nieder","Stefan Beller","brian m. carlson","Fedor Brunner","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251962","messageId":"5468C33E.2080108@whonix.org","threadId":"37982","inReplyTo":null,"subject":"How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Patrick Schleizer","fromEmail":"patrick-mailinglists@whonix.org","sentAt":"2014-11-16T15:31:10Z","receivedAt":"2014-11-16T15:31:10Z","isPatch":false,"sender":{"key":"patrick-mailinglists@whonix.org","avatar":null},"body":"Hi!\n\nHow safe are signed git tags? Especially because git uses SHA-1. There\nis contradictory information around.\n\nSo if one verifies a git tag (`git tag -v tagname`), then `checksout`s\nthe tag, and checks that `git status` reports no untracked/modified\nfiles, without further manually auditing the code, how secure is this\nactually? Is it only as safe as SHA-1?\n\nLet's assume an adversary, that is capable of producing SHA-1 collisions.\n\nLinus Torvalds said: [1]\n\n> Git uses SHA-1 not for security\n\nAnd goes on.\n\n> The security parts are elsewhere\n\nCould you please elaborate on this? Where are the security parts? Can\nyou please briefly explain how these work? Where can I read more about this?\n\nWikipedia says. [2]\n\n> Nonetheless, without second preimage resistance [3] of SHA-1 signed\ncommits and tags would no longer secure the state of the repository as\nthey only sign the root of a Merkle tree [4].\n\nWhich contradicts what Linus Torvalds said. What does that mean for\nsecurity? Which statement is true?\n\n> \"The source control management system Git uses SHA-1 not for security\nbut for ensuring that the data has not changed due to accidental\ncorruption. Linus Torvalds has said, \"If you have disk corruption, if\nyou have DRAM corruption, if you have any kind of problems at all, Git\nwill notice them. It's not a question of if, it's a guarantee. You can\nhave people who try to be malicious. They won't succeed. [...] Nobody\nhas been able to break SHA-1, but the point is the SHA-1, as far as Git\nis concerned, isn't even a security feature. It's purely a consistency\ncheck. The security parts are elsewhere, so a lot of people assume that\nsince Git uses SHA-1 and SHA-1 is used for cryptographically secure\nstuff, they think that, OK, it's a huge security feature. It has nothing\nat all to do with security, it's just the best hash you can get. [...] I\nguarantee you, if you put your data in Git, you can trust the fact that\nfive years later, after it was converted from your hard disk to DVD to\nwhatever new technology and you copied it along, five years later you\ncan verify that the data you get back out is the exact same data you put\nin. [...] One of the reasons I care is for the kernel, we had a break in\non one of the BitKeeper sites where people tried to corrupt the kernel\nsource code repositories.\" [6]\n\nIf (!) I understand Mike Gerwitz ([...] GNU [...]) 's opinion, his\nopinion is, that for best security each and every commit should be\nsigned for best possible git verification security.\n\nSee also:\n\n- Mike Gerwitz's \"A Git Horror Story: Repository Integrity With Signed\nCommits\" [7]\n\n- Verbose reply by Mike Gerwitz to my question. [8]\n\n- Similar question on security stackexchange. [9] Quote: \"Nevertheless,\nIf somebody managed to find a way how to find SHA1 collisions easily,\nthen git would have much bigger problem.\"\n\nCheers,\nPatrick\n\n[1] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s\n[2] https://en.wikipedia.org/wiki/SHA-1#Data_integrity\n[3] https://en.wikipedia.org/wiki/Second_preimage_resistance\n[4] https://en.wikipedia.org/wiki/Merkle_tree\n[5] https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s\n[6] https://en.wikipedia.org/wiki/SHA-1#Data_integrity\n[7] http://mikegerwitz.com/papers/git-horror-story\n[8] https://www.whonix.org/forum/index.php/topic,538.msg4278.html#msg4278\n[9]\nhttps://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer\n"},{"id":"252003","messageId":"20141117212657.GC15880@peff.net","threadId":"37982","inReplyTo":"5468C33E.2080108@whonix.org","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-17T21:26:57Z","receivedAt":"2014-11-17T21:26:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:\n\n> How safe are signed git tags? Especially because git uses SHA-1. There\n> is contradictory information around.\n> \n> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s\n> the tag, and checks that `git status` reports no untracked/modified\n> files, without further manually auditing the code, how secure is this\n> actually? Is it only as safe as SHA-1?\n\nYes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\nonly a SHA-1 hash. If somebody can find a collision with a hash you have\nsigned, they can substitute the colliding data for the data you signed.\n\nOf course, \"safe as SHA-1\" and \"find a collision\" are vague. If\npre-image attacks are feasible (i.e., given already-published SHA-1, I\ncan find a different input with the same SHA-1), then attacks are\ntrivial. But when people talk about attacks on SHA-1, they are usually\nreferring to finding a collision between two new pieces of data. You can\nalso use that in an attack, but it's much less straightforward\n(basically, you need to get somebody to sign one of the colliding pieces\nof data and then replace it with the other).\n\nAnd of course there is the question of getting the colliding data to the\nvictim. Git does collision checks whenever a remote (e.g., from a \"git\nfetch\") gives us data that we already have. So you could poison new\ncloners with bad data, but you could not convince a repository with the\nexisting \"good\" half of the collision to fetch the \"evil\" half.\n\n> > Git uses SHA-1 not for security\n> \n> And goes on.\n> \n> > The security parts are elsewhere\n> \n> Could you please elaborate on this? Where are the security parts? Can\n> you please briefly explain how these work? Where can I read more about this?\n\nI cannot speak for Linus, but I would not agree that SHA-1 is not part\nof Git's security model. If we consider the GPG signature as a black box\n(and we largely do in Git), then we _never_ sign the tree contents\nitself. We always sign the SHA-1 of the tree, along with some metadata\n(whether you are signing a tag or a commit). If an attacker can create\nSHA-1 collisions (either by pre-image, or if you agree to sign a tree\ncontaining a potential collision from an attacker), then you are\nvulnerable to having the tree contents swapped out after the fact (and\nthe signature still checking out).\n\nI am not sure that is what Linus is saying, though. In the paragraph you\nquote:\n\n> > \"The source control management system Git uses SHA-1 not for security\n> but for ensuring that the data has not changed due to accidental\n> corruption. Linus Torvalds has said, \"If you have disk corruption, if\n> you have DRAM corruption, if you have any kind of problems at all, Git\n> will notice them. It's not a question of if, it's a guarantee. You can\n> have people who try to be malicious. They won't succeed. [...] Nobody\n> has been able to break SHA-1, but the point is the SHA-1, as far as Git\n> is concerned, isn't even a security feature. It's purely a consistency\n> check. The security parts are elsewhere, so a lot of people assume that\n> since Git uses SHA-1 and SHA-1 is used for cryptographically secure\n> stuff, they think that, OK, it's a huge security feature. It has nothing\n> at all to do with security, it's just the best hash you can get. [...] I\n> guarantee you, if you put your data in Git, you can trust the fact that\n> five years later, after it was converted from your hard disk to DVD to\n> whatever new technology and you copied it along, five years later you\n> can verify that the data you get back out is the exact same data you put\n> in. [...] One of the reasons I care is for the kernel, we had a break in\n> on one of the BitKeeper sites where people tried to corrupt the kernel\n> source code repositories.\" [6]\n\nI think he is saying more \"SHA-1 is about data integrity, not about\nauthenticity; if you want authenticity, that's elsewhere [handled by\ngpg]\". Unsaid there is that you can't really have authenticity without\nthe integrity, and that I think he was assuming that SHA-1 works (he\nsays \"Nobody has been able to break SHA-1..\").\n\n> If (!) I understand Mike Gerwitz ([...] GNU [...]) 's opinion, his\n> opinion is, that for best security each and every commit should be\n> signed for best possible git verification security.\n\nI think it would depend on your threat model. You haven't defined \"best\nsecurity\".\n\nEven without a break in SHA-1, there is value to signing every commit\nversus signing just tags. If Linus signs a tag, all it says is \"I think\nthis tree state and the history leading up to it is called v3.16\". But\nLinus can lie all he likes about who made each commit, and what happened\nin each one. Signing commits is more about authenticating individual\ncommits: who made them, what was the state they were based on, and what\nwas the end state (and between the two, you can calculate the introduced\nchanges).\n\nOf course, that comes with its own headaches, too. E.g., in mailing-list\ndevelopment, the patch is picked up and applied by a maintainer, who\ndoes not necessarily commit it on the same state you used to create it.\nAnd even if they did, the committer information is different than what\nyou would create locally.  You inherently _can't_ sign that ahead of\ntime.\n\n-Peff\n"},{"id":"252369","messageId":"546FC446.50101@whonix.org","threadId":"37982","inReplyTo":"20141117212657.GC15880@peff.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Patrick Schleizer","fromEmail":"patrick-mailinglists@whonix.org","sentAt":"2014-11-21T23:01:26Z","receivedAt":"2014-11-21T23:01:26Z","isPatch":false,"sender":{"key":"patrick-mailinglists@whonix.org","avatar":null},"body":"Dear git developers!\n\nJeff King wrote:\n> On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:\n> \n>> How safe are signed git tags? Especially because git uses SHA-1. There\n>> is contradictory information around.\n>>\n>> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s\n>> the tag, and checks that `git status` reports no untracked/modified\n>> files, without further manually auditing the code, how secure is this\n>> actually? Is it only as safe as SHA-1?\n> \n> Yes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\n> only a SHA-1 hash. If somebody can find a collision with a hash you have\n> signed, they can substitute the colliding data for the data you signed.\n> \n> Of course, \"safe as SHA-1\" and \"find a collision\" are vague. If\n> pre-image attacks are feasible (i.e., given already-published SHA-1, I\n> can find a different input with the same SHA-1), then attacks are\n> trivial. But when people talk about attacks on SHA-1, they are usually\n> referring to finding a collision between two new pieces of data. You can\n> also use that in an attack, but it's much less straightforward\n> (basically, you need to get somebody to sign one of the colliding pieces\n> of data and then replace it with the other).\n\nSounds pretty sad. Isn't this a security issue that should be fixed?\n\nRather than discussing how feasible collisions in SHA-1 are... Attacks\non SHA-1 are only getting worse, no? Since the Snowden revelations we\nknow that powerful adversaries that are working on such things and would\nuse such weaknesses to exploit users.\n\nDear git developers, could you please make a long story short? Change to\nsome stronger hash algorithm? (sha256, sha512, or so?) Or provide an\noption for that?\n\n> And of course there is the question of getting the colliding data to the\n> victim. Git does collision checks whenever a remote (e.g., from a \"git\n> fetch\") gives us data that we already have. So you could poison new\n> cloners with bad data, but you could not convince a repository with the\n> existing \"good\" half of the collision to fetch the \"evil\" half.\n\nPoison git cloners with bad data is exactly my point here. Because\nsometimes I am a cloner of my own code - cloning it on a separate\nmachine - then verify it using gpg - but don't check it any further. In\nsuch cases, I'd prefer if security wouldn't depend on SHA-1.\n\nCheers,\nPatrick\n"},{"id":"252375","messageId":"1B02B87E88254A4A95EE138C9D2C4B8B@black","threadId":"37982","inReplyTo":"546FC446.50101@whonix.org","subject":"RE: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2014-11-21T23:32:46Z","receivedAt":"2014-11-21T23:32:46Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Patrick Schleizer\n> Sent: Friday, November 21, 2014 18:01\n> \n> Dear git developers!\n> \n> Jeff King wrote:\n> > On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:\n> > \n> >> How safe are signed git tags? Especially because git uses \n> SHA-1. There\n> >> is contradictory information around.\n> >>\n> >> So if one verifies a git tag (`git tag -v tagname`), then \n> `checksout`s\n> >> the tag, and checks that `git status` reports no untracked/modified\n> >> files, without further manually auditing the code, how \n> secure is this\n> >> actually? Is it only as safe as SHA-1?\n> > \n> > Yes, it is only as \"safe as SHA-1\" in the sense that you \n> have GPG-signed\n> > only a SHA-1 hash. If somebody can find a collision with a \n> hash you have\n> > signed, they can substitute the colliding data for the data \n> you signed.\n\nThe whole issue is a lot better than this makes it sound. Yes it is just a SHA1 hash, but it is a hash of a structured data format.\n\nYou have very observable parts of that well structured data providede to the hash.\n\nThe commit message, the directory contents, and lastly the files themselves.\n\nFor a collision to occur, the commit message would have to likely have garbage in the message of a large nature. To generate a colision by commited file contents is unlikely because the file contents is reduced to a hash in the directory structure, which is in turn reduced to a hash in a commit structure.\n\nThis would be noticed.\n\n\n--\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n-                                                               -\n- Jason Pyeron                      PD Inc. http://www.pdinc.us -\n- Principal Consultant              10 West 24th Street #100    -\n- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -\n-                                                               -\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\nThis message is copyright PD Inc, subject to license 20080407P00. \n"},{"id":"252380","messageId":"20141122194313.GB13340@peff.net","threadId":"37982","inReplyTo":"546FC446.50101@whonix.org","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-22T19:43:13Z","receivedAt":"2014-11-22T19:43:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 21, 2014 at 11:01:26PM +0000, Patrick Schleizer wrote:\n\n> > Yes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\n> > only a SHA-1 hash. If somebody can find a collision with a hash you have\n> > signed, they can substitute the colliding data for the data you signed.\n> [..]\n> Sounds pretty sad. Isn't this a security issue that should be fixed?\n\nSure, for some definition of \"should\". It's not a problem today. It may\nbe a problem in the future. If we were designing git from scratch today,\nit would probably make sense to use a different hash, or to somehow\nparameterize the hash.\n\nBut we're not starting from scratch. A change like that needs to\nconsider a transition plan. What happens to the existing history? Do we\njust rewrite it all using the new hash in all object references? If so,\nwhat do we do with non-object references to sha1s (in external systems,\nor even partial sha1s mentioned in commit message)? What do we do with\nsigned tags which are now invalid?  Or do we graft history with the new\nhashes onto the old, letting the two coexist in the same repository? How\ndo we expand the data structures to handle the extra information needed\nto specify the hash type?\n\nNone of these problems is insurmountable, but it's going to take real\nwork on the development side, and is going to create incompatibilities\nand headaches on the user side. It's probably something we'll need to\ndeal with in the next 10-15 years, but nobody knows quite when.\n\nIf you'd like to start working on it, I'd be happy to review your\npatches. :) But in the meantime, I don't know that anybody considers it\nan extremely high priority to work on, versus other fixes and features.\n\n> Rather than discussing how feasible collisions in SHA-1 are... Attacks\n> on SHA-1 are only getting worse, no?\n\nActually, not really. I do not keep up terribly well with the academic\nliterature, but I don't think that attacks have gotten any worse in the\nlast few years. Computers _are_ getting faster, though, so a number like\n2^61 (which is what Wikipedia claims as the best widely accepted value\nfor producing a collision) gets more and more feasible as time passes.\n\nOf course, we might find worse attacks (or if you want to put on your\ntinfoil hat, perhaps certain government organizations already have and\nare keeping them secret). 2^61 is a best case.\n\n> > And of course there is the question of getting the colliding data to the\n> > victim. Git does collision checks whenever a remote (e.g., from a \"git\n> > fetch\") gives us data that we already have. So you could poison new\n> > cloners with bad data, but you could not convince a repository with the\n> > existing \"good\" half of the collision to fetch the \"evil\" half.\n> \n> Poison git cloners with bad data is exactly my point here. Because\n> sometimes I am a cloner of my own code - cloning it on a separate\n> machine - then verify it using gpg - but don't check it any further. In\n> such cases, I'd prefer if security wouldn't depend on SHA-1.\n\nI agree that cloners are an important category of users to clone. But it\nalso means that a single fetcher can detect tampering quite easily.\nThink about it this way: let's say the Walker/Schneier estimate is\nright, and in 2021 it will cost ~$43K to find a collision. You spend the\nmoney, find a collision on some binary blob that's in the kernel,\nconvince Linus to accept your \"good\" version, he signs, and then you\nhack into kernel.org and replace the blob with your evil version. Now\nthe first time somebody fetches the evil version, their git complains\nabout the collision, kernel.org admins investigate, and the problem is\nfixed. There's some damage, but ultimately you didn't accomplish much.\n\nOr you could spend that $43K hiring somebody to break into Linus's house\nand manipulate the local copy of the kernel on his computer that he's\ngoing to sign. Or buy a zero-day exploit for his browser that gives you\nremote code execution on his workstation.\n\nDon't get me wrong. I think moving away from SHA-1 is a good idea, and\nsomething we're going to want to do for security reasons eventually. But\nwe're definitely not at the point of \"well, all of our signatures are\nworthless now\", and I'm not sure we'll be there sooner than a decade\nfrom now.\n\n-Peff\n"},{"id":"252381","messageId":"20141122194841.GA13665@peff.net","threadId":"37982","inReplyTo":"1B02B87E88254A4A95EE138C9D2C4B8B@black","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-22T19:48:42Z","receivedAt":"2014-11-22T19:48:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 21, 2014 at 06:32:46PM -0500, Jason Pyeron wrote:\n\n> The whole issue is a lot better than this makes it sound. Yes it is\n> just a SHA1 hash, but it is a hash of a structured data format.\n> \n> You have very observable parts of that well structured data providede to the hash.\n\nYeah, I glossed over that because I don't know enough about the specific\nattacks.  In the worst case, you have a binary file format that lets\npeople stick arbitrary bits of data in the middle (like the MD5 attacks\non Postscript and PDF files), and you do the collision on the blobs.\n\nBut even with that, the sha1s are taken over \"blob <n>\\0<content>\" where\n<n> is the number of bytes of <content>. Depending on the exact scheme\nfor generating probable collisions is less than brute force time, even\nthat amount of structure may prove problematic. I don't know whether\nthat is the case for the best-known attacks or not (remember that nobody\nhas _actually_ generated a sha-1 collision at all yet).\n\n-Peff\n"},{"id":"252415","messageId":"CACsJy8D-W_YrxMgUDScSmkNBKMVpRu_Kc0k6nsfyhmoLg5HBjg@mail.gmail.com","threadId":"37982","inReplyTo":"20141117212657.GC15880@peff.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-24T01:23:27Z","receivedAt":"2014-11-24T01:23:27Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Nov 18, 2014 at 4:26 AM, Jeff King <peff@peff.net> wrote:\n> Yes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\n> only a SHA-1 hash. If somebody can find a collision with a hash you have\n> signed, they can substitute the colliding data for the data you signed.\n\nI wonder if we can have an option to sign all blob content of the tree\nassociated to a commit, and the content of parent commit(s). It's more\nexpensive than signing just commit/tag content. But it's also safer\nwithout completely ditching SHA-1.\n-- \nDuy\n"},{"id":"252422","messageId":"54730546.7000200@drmicha.warpmail.net","threadId":"37982","inReplyTo":"CACsJy8D-W_YrxMgUDScSmkNBKMVpRu_Kc0k6nsfyhmoLg5HBjg@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2014-11-24T10:15:34Z","receivedAt":"2014-11-24T10:15:34Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Duy Nguyen schrieb am 24.11.2014 um 02:23:\n> On Tue, Nov 18, 2014 at 4:26 AM, Jeff King <peff@peff.net> wrote:\n>> Yes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\n>> only a SHA-1 hash. If somebody can find a collision with a hash you have\n>> signed, they can substitute the colliding data for the data you signed.\n> \n> I wonder if we can have an option to sign all blob content of the tree\n> associated to a commit, and the content of parent commit(s). It's more\n> expensive than signing just commit/tag content. But it's also safer\n> without completely ditching SHA-1.\n> \n\nThis amounts to hashing the blob content with whatever hash you told\nyour gpg to use (hopefully not sha1 ;) ) and signing that.\n\nYou're free to do that now and store the signature wherever your\ntoolchain deems fit, say in a note or an annotated tag. But that\napproach won't sign the history, that is: If you are concerned about the\nbreakability of sha1, then history is \"possibly broken\" no matter how\nyou sign a commit object whose \"parent\" entry is based on the sha1 of\nits parent object.\n\nCheers\nMichael\n"},{"id":"252426","messageId":"CACsJy8B5dbYZm25019avX2q0Ymp=f4jt=jt898M_znE8eEcOVg@mail.gmail.com","threadId":"37982","inReplyTo":"54730546.7000200@drmicha.warpmail.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-24T11:44:10Z","receivedAt":"2014-11-24T11:44:10Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Nov 24, 2014 at 5:15 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Duy Nguyen schrieb am 24.11.2014 um 02:23:\n>> On Tue, Nov 18, 2014 at 4:26 AM, Jeff King <peff@peff.net> wrote:\n>>> Yes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\n>>> only a SHA-1 hash. If somebody can find a collision with a hash you have\n>>> signed, they can substitute the colliding data for the data you signed.\n>>\n>> I wonder if we can have an option to sign all blob content of the tree\n>> associated to a commit, and the content of parent commit(s). It's more\n>> expensive than signing just commit/tag content. But it's also safer\n>> without completely ditching SHA-1.\n>>\n>\n> This amounts to hashing the blob content with whatever hash you told\n> your gpg to use (hopefully not sha1 ;) ) and signing that.\n>\n> You're free to do that now and store the signature wherever your\n> toolchain deems fit, say in a note or an annotated tag. But that\n> approach won't sign the history, that is: If you are concerned about the\n> breakability of sha1, then history is \"possibly broken\" no matter how\n> you sign a commit object whose \"parent\" entry is based on the sha1 of\n> its parent object.\n\nIf you store the singature in commit message, and if you hash the\nparent commit messages as well, which are also signed, then you have\nthe same chaining effect that we have with SHA-1. I think this could\nbe done with some hooks already, except maybe for the verification\npart.\n-- \nDuy\n"},{"id":"252432","messageId":"20141124155108.GC25912@peff.net","threadId":"37982","inReplyTo":"54730546.7000200@drmicha.warpmail.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-24T15:51:08Z","receivedAt":"2014-11-24T15:51:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 24, 2014 at 11:15:34AM +0100, Michael J Gruber wrote:\n\n> > I wonder if we can have an option to sign all blob content of the tree\n> > associated to a commit, and the content of parent commit(s). It's more\n> > expensive than signing just commit/tag content. But it's also safer\n> > without completely ditching SHA-1.\n> > \n> \n> This amounts to hashing the blob content with whatever hash you told\n> your gpg to use (hopefully not sha1 ;) ) and signing that.\n\nRight. You could also create a graph of SHA-256 (or whatever) object\nhashes and sign that. I.e., create a parallel to git's trees using\nSHA-256 and include a single:\n\n  object-256 ....\n\nline in the tag header. That still involves re-hashing all of the data,\nbut it would at least be possible to cache (i.e., a mapping of SHA-1 to\nSHA-256 hashes). Of course one way to keep that caching layer up to date\nwould be to just calculate the SHA-256 along with the SHA-1 whenever we\ncreate an object. And then you can sprinkle SHA-256 links in other\nplaces, too, like commit objects.\n\nAnd now you are halfway down the road to a combined SHA-1/SHA-256 git.\n:)\n\nThe tricky thing is fitting the extra hash into the tree objects. And of\ncourse the rules for actually generating and/or sending extra objects.\n\n-Peff\n"},{"id":"252437","messageId":"CAK3OfOgko5Fb5FMGCKw3+12fAzMVEHuUriaiBNGi8nb28bNTQA@mail.gmail.com","threadId":"37982","inReplyTo":"20141117212657.GC15880@peff.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-11-24T18:14:34Z","receivedAt":"2014-11-24T18:14:34Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"Is there a plan for upgrading to a better hash function in the future?\n (E.g., should it become an urgent need.)\n\nWhat are the roadblocks to adoption of a replacement hash function?\nJust documenting this would go a long way towards making it possible\nto upgrade some day.\n\nThanks,\n\nNico\n--\n"},{"id":"252479","messageId":"CACsJy8BMNXUinfK=YcJPkx98tYv_e40N0_mqqnzMLxDN6hkruA@mail.gmail.com","threadId":"37982","inReplyTo":"CAK3OfOgko5Fb5FMGCKw3+12fAzMVEHuUriaiBNGi8nb28bNTQA@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-25T01:16:15Z","receivedAt":"2014-11-25T01:16:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Nov 25, 2014 at 1:14 AM, Nico Williams <nico@cryptonector.com> wrote:\n> Is there a plan for upgrading to a better hash function in the future?\n>  (E.g., should it become an urgent need.)\n>\n> What are the roadblocks to adoption of a replacement hash function?\n> Just documenting this would go a long way towards making it possible\n> to upgrade some day.\n\nThe biggest obstacle is the assumption of SHA-1 everywhere in the\nsource code (e.g. assume the object name always takes 20 bytes). Brian\nstarted on cleaning that up [1] but I think it's stalled. Then we need\nto deal with upgrade path for SHA-1 repos.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/248054\n-- \nDuy\n"},{"id":"252480","messageId":"20141125012359.GR6527@google.com","threadId":"37982","inReplyTo":"CACsJy8BMNXUinfK=YcJPkx98tYv_e40N0_mqqnzMLxDN6hkruA@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-11-25T01:23:59Z","receivedAt":"2014-11-25T01:23:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Duy Nguyen wrote:\n\n> The biggest obstacle is the assumption of SHA-1 everywhere in the\n> source code (e.g. assume the object name always takes 20 bytes). Brian\n> started on cleaning that up [1] but I think it's stalled. Then we need\n> to deal with upgrade path for SHA-1 repos.\n\nI think the biggest obstacle is the upgrade path. ;-)\n\nIf the upgrade path is taken care of, I won't mind writing and\nreviewing a coccinelle-generated patch to replace 20, 40, 21, 41, and\nso on with appropriate constants.  Or we can take the first 20 bytes\nof a SHA-256, which is already supposed to have better security\nproperties than SHA-1.\n\nAnother obstacle is hard-coded SHA-1s in tests.\n\nThanks,\nJonathan\n"},{"id":"252482","messageId":"CACsJy8C3Bfruy=usn9MajmLP_10s2zf8AFZJmxyeGSPDS9SwVQ@mail.gmail.com","threadId":"37982","inReplyTo":"20141125012359.GR6527@google.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-25T01:52:58Z","receivedAt":"2014-11-25T01:52:58Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> I think the biggest obstacle is the upgrade path. ;-)\n\nIn the worst case we can always treat new repos as a different VCS. So\npeople will need a migration from SHA-1 to the new format, just like\nthey migrate from SVN/CVS to Git. Painful but simple.\n-- \nDuy\n"},{"id":"252484","messageId":"CAGZ79kZkqVZ+G-J+HKDwmK+W80E_28DyvxKVpEACPXoX88KLAA@mail.gmail.com","threadId":"37982","inReplyTo":"CACsJy8C3Bfruy=usn9MajmLP_10s2zf8AFZJmxyeGSPDS9SwVQ@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2014-11-25T03:40:30Z","receivedAt":"2014-11-25T03:40:30Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"That's not *as* painful, because you'd have the beautiful\nfast-{import/export} tools in your new and old version control system.\nBut yeah, there might be better ways to do so.\n\n\nOn Mon, Nov 24, 2014 at 5:52 PM, Duy Nguyen <pclouds@gmail.com> wrote:\n> On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>> I think the biggest obstacle is the upgrade path. ;-)\n>\n> In the worst case we can always treat new repos as a different VCS. So\n> people will need a migration from SHA-1 to the new format, just like\n> they migrate from SVN/CVS to Git. Painful but simple.\n> --\n> Duy\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"252487","messageId":"20141125034730.GB19161@peff.net","threadId":"37982","inReplyTo":"CACsJy8C3Bfruy=usn9MajmLP_10s2zf8AFZJmxyeGSPDS9SwVQ@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-25T03:47:31Z","receivedAt":"2014-11-25T03:47:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 25, 2014 at 08:52:58AM +0700, Duy Nguyen wrote:\n\n> On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> > I think the biggest obstacle is the upgrade path. ;-)\n> \n> In the worst case we can always treat new repos as a different VCS. So\n> people will need a migration from SHA-1 to the new format, just like\n> they migrate from SVN/CVS to Git. Painful but simple.\n\nMaybe we can fix the tree-sorting order while we are at it. :)\n\nMore seriously, there may come a day when we are ready to break\ncompatibility completely with a new \"Git v3.0\" (2.0 is already taken, of\ncourse). I do not have immediate plans for it, but it's possible that\nmultiple factors may make such a move desirable sometime in the next 10\nyears, and that would be a good time to jump hash algorithms, as well.\n\nSo it's possible that procrastinating on SHA-1 issues may be the least\npainful route. Or it may just be pushing off the day of pain. :)\n\n-Peff\n"},{"id":"252511","messageId":"20141125104152.GA13038@lanh","threadId":"37982","inReplyTo":"CACsJy8B5dbYZm25019avX2q0Ymp=f4jt=jt898M_znE8eEcOVg@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-25T10:41:52Z","receivedAt":"2014-11-25T10:41:52Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Nov 24, 2014 at 06:44:10PM +0700, Duy Nguyen wrote:\n> >> I wonder if we can have an option to sign all blob content of the tree\n> >> associated to a commit, and the content of parent commit(s). It's more\n> >> expensive than signing just commit/tag content. But it's also safer\n> >> without completely ditching SHA-1.\n> >>\n> >\n> > This amounts to hashing the blob content with whatever hash you told\n> > your gpg to use (hopefully not sha1 ;) ) and signing that.\n> >\n> > You're free to do that now and store the signature wherever your\n> > toolchain deems fit, say in a note or an annotated tag. But that\n> > approach won't sign the history, that is: If you are concerned about the\n> > breakability of sha1, then history is \"possibly broken\" no matter how\n> > you sign a commit object whose \"parent\" entry is based on the sha1 of\n> > its parent object.\n> \n> If you store the singature in commit message, and if you hash the\n> parent commit messages as well, which are also signed, then you have\n> the same chaining effect that we have with SHA-1. I think this could\n> be done with some hooks already, except maybe for the verification\n> part.\n\nTo demonstrate, a hook like this can take commit object from stdin and\nproduce some hash lines, which are appended at the end of the commit\nmessage before the new commit object is created. So if I commit \"foo\"\nthe final commit message would be\n\n  foo\n\n  SHA512: <long hash>\n\nThis script uses sha512sum, but you can add as many hashes as you want\n(and pay the penalty at commit time, of course). I think it covers\nenough content to validate history up to the last signed commit.\n\n-- 8< --\n#!/bin/bash\n# commit content\ncat >$GIT_DIR/tmp\n# parent commit content\nsed '/^$/q' $GIT_DIR/tmp |\n    grep '^parent ' |\n    cut -c 8- |\n    xargs -n1 git cat-file commit >>$GIT_DIR/tmp\n# all blobs\nsed '/^$/q' $GIT_DIR/tmp |\n    grep '^tree ' |\n    cut -c 6- |\n    xargs -n1 git ls-tree -r |\n    cut -c 13-52 |\n    git cat-file --batch >>$GIT_DIR/tmp\necho\necho \"SHA512: `sha512sum < $GIT_DIR/tmp`\"\n-- 8< --\n\nAn extra patch is required to hook this in final commit steps.\n\n-- 8< --\ndiff --git a/commit.c b/commit.c\nindex 19cf8f9..c447c1d 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -11,6 +11,8 @@\n #include \"commit-slab.h\"\n #include \"prio-queue.h\"\n #include \"sha1-lookup.h\"\n+#include \"run-command.h\"\n+#include \"sigchain.h\"\n \n static struct commit_extra_header *read_commit_extra_header_lines(const char *buf, size_t len, const char **);\n \n@@ -1064,6 +1066,36 @@ struct commit_list *reduce_heads(struct commit_list *heads)\n \treturn result;\n }\n \n+static int run_sign_commit_hook(struct strbuf *buf)\n+{\n+\tstruct child_process hook = CHILD_PROCESS_INIT;\n+\tconst char *p = find_hook(\"sign-commit\");\n+\tint len;\n+\n+\tif (!p)\n+\t\treturn 0;\n+\n+\targv_array_push(&hook.args, p);\n+\thook.in = -1;\n+\thook.out = -1;\n+\tif (start_command(&hook))\n+\t\treturn error(_(\"could not run sign-commit hook\"));\n+\tsigchain_push(SIGPIPE, SIG_IGN);\n+\tif (write_in_full(hook.in, buf->buf, buf->len) != buf->len) {\n+\t\tclose(hook.in);\n+\t\tclose(hook.out);\n+\t\tfinish_command(&hook);\n+\t\treturn error(_(\"sign-commit hook did not accept the data\"));\n+\t}\n+\tclose(hook.in);\n+\tlen = strbuf_read(buf, hook.out, 1024);\n+\tclose(hook.out);\n+\tsigchain_pop(SIGPIPE);\n+\tif (finish_command(&hook) || len <= 0)\n+\t\treturn error(_(\"sign-commit hook failed to sign the data\"));\n+\treturn 0;\n+}\n+\n static const char gpg_sig_header[] = \"gpgsig\";\n static const int gpg_sig_header_len = sizeof(gpg_sig_header) - 1;\n \n@@ -1555,6 +1587,9 @@ int commit_tree_extended(const char *msg, size_t msg_len,\n \tif (encoding_is_utf8 && !verify_utf8(&buffer))\n \t\tfprintf(stderr, commit_utf8_warn);\n \n+\tif (run_sign_commit_hook(&buffer))\n+\t\treturn -1;\n+\n \tif (sign_commit && do_sign_commit(&buffer, sign_commit))\n \t\treturn -1;\n \n-- 8< --\n"},{"id":"252508","messageId":"CACsJy8C5F7JPvfpGPOPy0oT=1YrhLeheF9fc29PgkAK=SnhXww@mail.gmail.com","threadId":"37982","inReplyTo":"20141125034730.GB19161@peff.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-25T10:55:08Z","receivedAt":"2014-11-25T10:55:08Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Nov 25, 2014 at 10:47 AM, Jeff King <peff@peff.net> wrote:\n> Maybe we can fix the tree-sorting order while we are at it. :)\n\nAt this speed, there a teeny tiny chance that pack v4 will be ready by\nGit v3.0 and we can pile that on top of the new tree format. And we\ndon't have to worry about v3<->v4 online conversion either because\nit's backward incompatible ;)\n\n> More seriously, there may come a day when we are ready to break\n> compatibility completely with a new \"Git v3.0\" (2.0 is already taken, of\n> course). I do not have immediate plans for it, but it's possible that\n> multiple factors may make such a move desirable sometime in the next 10\n> years, and that would be a good time to jump hash algorithms, as well.\n>\n> So it's possible that procrastinating on SHA-1 issues may be the least\n> painful route. Or it may just be pushing off the day of pain. :)\n-- \nDuy\n"},{"id":"252509","messageId":"20141125110711.GF28310@vauxhall.crustytoothpaste.net","threadId":"37982","inReplyTo":"CACsJy8BMNXUinfK=YcJPkx98tYv_e40N0_mqqnzMLxDN6hkruA@mail.gmail.com","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-11-25T11:07:11Z","receivedAt":"2014-11-25T11:07:11Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Nov 25, 2014 at 08:16:15AM +0700, Duy Nguyen wrote:\n> On Tue, Nov 25, 2014 at 1:14 AM, Nico Williams <nico@cryptonector.com> wrote:\n> > Is there a plan for upgrading to a better hash function in the future?\n> >  (E.g., should it become an urgent need.)\n> >\n> > What are the roadblocks to adoption of a replacement hash function?\n> > Just documenting this would go a long way towards making it possible\n> > to upgrade some day.\n> \n> The biggest obstacle is the assumption of SHA-1 everywhere in the\n> source code (e.g. assume the object name always takes 20 bytes). Brian\n> started on cleaning that up [1] but I think it's stalled. Then we need\n> to deal with upgrade path for SHA-1 repos.\n\nYes, it is stalled.  It ended up being a Herculean task, so when I pick\nup the patch series again, I'll probably submit changes in chunks to\navoid the huge amount of code churn required.  I feel the list and Junio\nin particular will appreciate that more.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"252514","messageId":"54747D14.2020406@azet.sk","threadId":"37982","inReplyTo":"546FC446.50101@whonix.org","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Fedor Brunner","fromEmail":"fedor.brunner@azet.sk","sentAt":"2014-11-25T12:59:00Z","receivedAt":"2014-11-25T12:59:00Z","isPatch":false,"sender":{"key":"fedor.brunner@azet.sk","avatar":null},"body":"On 22.11.2014 00:01, Patrick Schleizer wrote:\n> Dear git developers!\n> \n> Jeff King wrote:\n>> On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:\n>>\n>>> How safe are signed git tags? Especially because git uses SHA-1. There\n>>> is contradictory information around.\n>>>\n>>> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s\n>>> the tag, and checks that `git status` reports no untracked/modified\n>>> files, without further manually auditing the code, how secure is this\n>>> actually? Is it only as safe as SHA-1?\n>>\n>> Yes, it is only as \"safe as SHA-1\" in the sense that you have GPG-signed\n>> only a SHA-1 hash. If somebody can find a collision with a hash you have\n>> signed, they can substitute the colliding data for the data you signed.\n>>\n>> Of course, \"safe as SHA-1\" and \"find a collision\" are vague. If\n>> pre-image attacks are feasible (i.e., given already-published SHA-1, I\n>> can find a different input with the same SHA-1), then attacks are\n>> trivial. But when people talk about attacks on SHA-1, they are usually\n>> referring to finding a collision between two new pieces of data. You can\n>> also use that in an attack, but it's much less straightforward\n>> (basically, you need to get somebody to sign one of the colliding pieces\n>> of data and then replace it with the other).\n> \n> Sounds pretty sad. Isn't this a security issue that should be fixed?\n> \n> Rather than discussing how feasible collisions in SHA-1 are... Attacks\n> on SHA-1 are only getting worse, no? Since the Snowden revelations we\n> know that powerful adversaries that are working on such things and would\n> use such weaknesses to exploit users.\n> \n> Dear git developers, could you please make a long story short? Change to\n> some stronger hash algorithm? (sha256, sha512, or so?) Or provide an\n> option for that?\n> \n>> And of course there is the question of getting the colliding data to the\n>> victim. Git does collision checks whenever a remote (e.g., from a \"git\n>> fetch\") gives us data that we already have. So you could poison new\n>> cloners with bad data, but you could not convince a repository with the\n>> existing \"good\" half of the collision to fetch the \"evil\" half.\n> \n> Poison git cloners with bad data is exactly my point here. Because\n> sometimes I am a cloner of my own code - cloning it on a separate\n> machine - then verify it using gpg - but don't check it any further. In\n> such cases, I'd prefer if security wouldn't depend on SHA-1.\n> \n> Cheers,\n> Patrick\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n\nDear git developers,\nhow about skipping SHA-2 and moving to SHA-3 finalist BLAKE.\n\nNIST, in the final report of the SHA-3 competition, said this about the\nfinalists (which included BLAKE, Keccak, Skein, and Grøstl):\n\n    BLAKE had a security margin — the gap between a known-weak reduced\nversion and the full version — comparable to Keccak and superior to the\nother finalists. (§4.3: “BLAKE and Keccak have very large security\nmargins.”)\n    BLAKE had a depth of analysis — the amount of published research\nanalyzing its security — comparable to Grøstl and Skein and superior to\nthe other finalists. (§3.1: “Keccak received a significant amount of\ncryptanalysis, although not quite the depth of analysis applied to\nBLAKE, Grøstl, or Skein”)\n    BLAKE had performance (in software) comparable to Skein and superior\nto the other finalists. (§5.1.4: “Skein and BLAKE […] have the best\noverall software performance.”)\n\nhttp://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf\n\n\n\nMeasurements of SHA-3 finalists, indexed by machine\n\nhttp://bench.cr.yp.to/results-sha3.html\n\n\nFedor\n"},{"id":"252526","messageId":"xmqqfvd7tcsh.fsf@gitster.dls.corp.google.com","threadId":"37982","inReplyTo":"20141125034730.GB19161@peff.net","subject":"Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-25T17:23:10Z","receivedAt":"2014-11-25T17:23:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Nov 25, 2014 at 08:52:58AM +0700, Duy Nguyen wrote:\n>\n>> On Tue, Nov 25, 2014 at 8:23 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>> > I think the biggest obstacle is the upgrade path. ;-)\n>> \n>> In the worst case we can always treat new repos as a different VCS. So\n>> people will need a migration from SHA-1 to the new format, just like\n>> they migrate from SVN/CVS to Git. Painful but simple.\n>\n> Maybe we can fix the tree-sorting order while we are at it. :)\n>\n> More seriously, there may come a day when we are ready to break\n> compatibility completely with a new \"Git v3.0\" (2.0 is already taken, of\n> course). I do not have immediate plans for it, but it's possible that\n> multiple factors may make such a move desirable sometime in the next 10\n> years, and that would be a good time to jump hash algorithms, as well.\n\nAs the fundamental data model of Git is built around \"given the\nobject name, the same data is retrieved, and equally importantly,\ngiven the same data, the same object name is used, so that we can\nsay two objects with different names record different contents\nwithout looking at the data\", it does not mesh with the use of\ntagged hash where object name consists of a pair of <what hash is\nused> and <what the hash value is> at all.  It is a proper mindset\nto treat it as a different VCS to give us a clean break when (I did\nnot say \"if\") we need to switch hashes, I think.\n\nThanks.\n"}]}