{"thread":{"id":"59083","subject":"Gitorious should use CRC128 / 256 / 512 instead of SHA-1","startedAt":"2023-01-13T13:33:18Z","lastAt":"2023-01-16T19:08:18Z","messageCount":16,"participants":["Hans Petter Selasky","brian m. carlson","Junio C Hamano","demerphq","Michal Suchánek","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"470254","messageId":"9c0fda42-67ab-f406-489b-38a2d9bbcfc2@selasky.org","threadId":"59083","inReplyTo":null,"subject":"Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-13T13:23:59Z","receivedAt":"2023-01-13T13:33:18Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"Hi,\n\nCurrently GIT only supports cryptographic hashes for its commit tags.\n\nThat means:\n\n1) It's very difficult to edit the history without also recomputing the \nhash tags for all commits after the needed change-point, which then \nmeans references to a repository is broken.\n\n2) Only a single bit error in the main repository can break everything!\n\n3) Illicit contents may be present in binary blobs, which in the future \nmay be need to be removed without warrant and the only way to do that is \nby rebasing and force pushing, which will break \"everything\". It can be \neverything from child-porn to expired distribution licenses.\n\nMany people think that bit errors cannot happen because the memory uses \nECC and the file system uses cryptographic hashes to verify the \nintegrity of the data. But what many people forget about is that when \ncopying data from memory to disk, typically using a DMA channel data is \ncopied w/o any kind of integrity protection, because the integrity \nprotection is not end-to-end. The integrity protection is only per-link.\n\nTherefore I propose the following changes to GIT.\n\n1) Use a CRC128 / 256 or 512 non-cryptographic based hashing algorithm \nas default.\n\n2) Add support for a CRC fixup field, which usually is zero, but when \nmerges are needed, it can be non-zero, to allow the hash-tag-value to \nremain the same! This also allows for easy conversion of existing GIT \nrepositories to the new scheme.\n\n3) All git objects should be uncompressed.\n\nCRC-XXX can easily be used to correct multiple bit errors without any \nperformance overhead.\n\n--HPS\n"},{"id":"470369","messageId":"Y8NB21PExmifhyeQ@tapette.crustytoothpaste.net","threadId":"59083","inReplyTo":"9c0fda42-67ab-f406-489b-38a2d9bbcfc2@selasky.org","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-01-14T23:59:23Z","receivedAt":"2023-01-14T23:59:29Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-01-13 at 13:23:59, Hans Petter Selasky wrote:\n> Hi,\n> \n> Currently GIT only supports cryptographic hashes for its commit tags.\n> \n> That means:\n> \n> 1) It's very difficult to edit the history without also recomputing the hash\n> tags for all commits after the needed change-point, which then means\n> references to a repository is broken.\n\nThis is intentional.  Commit and tag signing requires an unbroken Merkle\ntree-like construction that prevents the history from being modified by\nsigning a single commit or tag.\n\n> 2) Only a single bit error in the main repository can break everything!\n\ngit fsck is designed to detect this, and by default it's run every time\nthe repository is repacked (such as by git gc).  But yes, this is a\nproblem, and changing to an algorithm which isn't cryptographically\nsecure won't change that.  Prudent users back up data to prevent data\nloss.\n\n> 3) Illicit contents may be present in binary blobs, which in the future may\n> be need to be removed without warrant and the only way to do that is by\n> rebasing and force pushing, which will break \"everything\". It can be\n> everything from child-porn to expired distribution licenses.\n\nThis is a problem in every Merkle tree-like system.  Most repositories\nhave some sort of code review or access control that prevents people\nfrom generally pushing inappropriate content.  For example, if somebody\nproposed to push any sort of pornography or other inappropriate content\n(e.g., a racist screed) to one of my repositories or one of my\nemployer's, I'd refuse to approve or merge such a change, because\nthat wouldn't be appropriate for the repository.\n\nI don't feel this is enough of a problem that using a Merkle tree-like\nconstruction is a bad idea, given the benefits it offers.\n\n> Therefore I propose the following changes to GIT.\n> \n> 1) Use a CRC128 / 256 or 512 non-cryptographic based hashing algorithm as\n> default.\n\nAs the person who wrote the SHA-256 support, I'm pleased to report that\nadding a new hash algorithm isn't very difficult anymore.  The largest\npart of the work is updating all the tests.  I've tried very hard to\nmake this substantially easier for everyone.\n\nHowever, Git is moving in the direction of stronger cryptographic\nalgorithms, rather than insecure hashing algorithms.  I don't think your\nproposal is a good idea, nor do I think it's likely to be adopted.\n\nIf it were adopted, the signing of commits and tags would be\nmeaningless, and because it would be trivial to create collisions[0], there\nwould clearly be some pairs of objects which could not be stored.  This\nwould make Git much less useful, and it might allow users to attempt to\nforge or replace content without being detected.\n\nThat being said, you are free to create your own fork of the code which\ndoes so, provided you comply with the terms of the license.\n\n> 2) Add support for a CRC fixup field, which usually is zero, but when merges\n> are needed, it can be non-zero, to allow the hash-tag-value to remain the\n> same! This also allows for easy conversion of existing GIT repositories to\n> the new scheme.\n\nFor the same reason as above, I don't think this is a good idea.\n\n> 3) All git objects should be uncompressed.\n\nThis would dramatically increase the size of most repositories.  I've\neasily seen repositories where the uncompressed contents exceed 1 TB in\nsize yet the repository is only double-digit gigabytes, if that.  Most\npeople will find the increase in disk usage unacceptable, and I'm\ncertain that includes Git hosterse.\n\n[0] CRC is linear and the following relations apply, which makes forgery\ntrivial (see https://en.wikipedia.org/wiki/Cyclic_redundancy_check):\n\nCRC(x XOR y) = CRC(x) XOR CRC(y) XOR c for some c\nCRC(x XOR y XOR z) = CRC(x) XOR CRC(y) XOR CRC(z)\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"470373","messageId":"xmqqk01oij4y.fsf@gitster.g","threadId":"59083","inReplyTo":"Y8NB21PExmifhyeQ@tapette.crustytoothpaste.net","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-15T03:14:37Z","receivedAt":"2023-01-15T03:14:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n>> 3) Illicit contents may be present in binary blobs, which in the future may\n>> be need to be removed without warrant and the only way to do that is by\n>> rebasing and force pushing, which will break \"everything\". It can be\n>> everything from child-porn to expired distribution licenses.\n>\n> This is a problem in every Merkle tree-like system.  Most repositories\n> have some sort of code review or access control that prevents people\n> from generally pushing inappropriate content.  For example, if somebody\n> proposed to push any sort of pornography or other inappropriate content\n> (e.g., a racist screed) to one of my repositories or one of my\n> employer's, I'd refuse to approve or merge such a change, because\n> that wouldn't be appropriate for the repository.\n>\n> I don't feel this is enough of a problem that using a Merkle tree-like\n> construction is a bad idea, given the benefits it offers.\n\nWhile I agree with the primary thrust of your argument, this one is\na bit tricky to reason about.  External rules change and can declare\nwhat has been accepted as appropriate inappropriate on a whim, long\nafter you reviewed the material coming into your history and decided\nit was perfectly fine, under the then-prevailing definition of what\nis and isn't appropriate.\n\n"},{"id":"470383","messageId":"CANgJU+X0LZfpdh4HWFC6-Y=+G6Mv-wKiZWrB=JJwe6CnYKeORg@mail.gmail.com","threadId":"59083","inReplyTo":"Y8NB21PExmifhyeQ@tapette.crustytoothpaste.net","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2023-01-15T10:09:09Z","receivedAt":"2023-01-15T10:09:25Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Sun, 15 Jan 2023 at 01:05, brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> This is a problem in every Merkle tree-like system.  Most repositories\n> have some sort of code review or access control that prevents people\n> from generally pushing inappropriate content.  For example, if somebody\n> proposed to push any sort of pornography or other inappropriate content\n> (e.g., a racist screed) to one of my repositories or one of my\n> employer's, I'd refuse to approve or merge such a change, because\n> that wouldn't be appropriate for the repository.\n>\n> I don't feel this is enough of a problem that using a Merkle tree-like\n> construction is a bad idea, given the benefits it offers.\n\n\n[resend in plain text]\n\nIt isn't clear to me why this needs to be a problem at all. If the\nMerkele tree contains data later in its chain that says \"replace\nObject X with Y\", provided the replacement mechanism doesn't touch\ncommit objects, only blobs, then you can replace files in the history\nwith other files without altering the commit history.\n\nProvided the toolchain validates that it has found a proper\n\"replacement instruction\" in the history, it should be possible to\nsafely replace blobs without a full history rewrite.\n\nThe replacement mechanism could be structured so that you can only\n\"nuke\" a file, eg, replace it with a zero byte blob, making it\nsomewhat less open to abuse, or it could allow arbitrary blobs to be\nmapped to each other. So long as the mapping data is in the commit\nhistory it should be as secure as the original mapping no? Git could\nbe taught to warn the user \"Checking out a rewritten blob X as Y, see\n012deadbeef for the rewrite instruction.\" when it happened.\n\nAgain, provided this does not touch the *commit* tree, just raw blobs,\nI dont see why you can't have an object replacement facility.  Am I\nmissing something?\n\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"470385","messageId":"20230115135245.GB16547@kitsune.suse.cz","threadId":"59083","inReplyTo":"9c0fda42-67ab-f406-489b-38a2d9bbcfc2@selasky.org","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2023-01-15T13:53:09Z","receivedAt":"2023-01-15T13:53:16Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"Hello,\n\nOn Fri, Jan 13, 2023 at 02:23:59PM +0100, Hans Petter Selasky wrote:\n> Hi,\n> \n> Currently GIT only supports cryptographic hashes for its commit tags.\n> \n> That means:\n> \n> 1) It's very difficult to edit the history without also recomputing the hash\n> tags for all commits after the needed change-point, which then means\n> references to a repository is broken.\n\nThat also makes it difficult to alter the repository intentionally\nwithout anyone noticing. With SHA1 being somewhat weak it may be\npossible to alter repository content although I am not aware of any\npractical attacks shown so far. For that reason using stronger hashes is\nplanned in the future.\n\n> 2) Only a single bit error in the main repository can break everything!\n> \n> 3) Illicit contents may be present in binary blobs, which in the future may\n> be need to be removed without warrant and the only way to do that is by\n> rebasing and force pushing, which will break \"everything\". It can be\n> everything from child-porn to expired distribution licenses.\n\nIt's good to avoid spam getting into your repository. If you really need\nto alter it long into the past you still can. Everyone will notice that\nyou did, and that's an intentional feature. In some situations it is\nunderstandably an annoyance but there's so much you can do. At least\ntags should remain stable.\n\n> Many people think that bit errors cannot happen because the memory uses ECC\n> and the file system uses cryptographic hashes to verify the integrity of the\n> data. But what many people forget about is that when copying data from\n> memory to disk, typically using a DMA channel data is copied w/o any kind of\n> integrity protection, because the integrity protection is not end-to-end.\n> The integrity protection is only per-link.\n\nSo long as all links have integrity protection it's end-to-end.\n\nIntegrity checks for CPU chaches, buses, and IO protocols do exist.\n\nIt's not that errors cannot happen, they are very unlikely.\n\nIn the very rare case that such error happens so long as non-corrupted\nversion of the object can be supplied by anyone who has a copy of the\nrepository it is recoverable.\n\nFor old objects this should be your backup system.\n\nFor new objects the worst case is that the history is rolled back so the\nmissing object is not needed.\n\nThanks\n\nMichal\n"},{"id":"470421","messageId":"b1984123-569a-c290-8048-158c1c5e08b4@selasky.org","threadId":"59083","inReplyTo":"20230115135245.GB16547@kitsune.suse.cz","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-16T07:17:58Z","receivedAt":"2023-01-16T07:18:10Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"On 1/15/23 14:53, Michal Suchánek wrote:\n>> Many people think that bit errors cannot happen because the memory uses ECC\n>> and the file system uses cryptographic hashes to verify the integrity of the\n>> data. But what many people forget about is that when copying data from\n>> memory to disk, typically using a DMA channel data is copied w/o any kind of\n>> integrity protection, because the integrity protection is not end-to-end.\n>> The integrity protection is only per-link.\n >\n> So long as all links have integrity protection it's end-to-end.\n >\n\nHi Michael,\n\nYou clearly don't see what this is about! Only if the same CRC mechanism \nis end-to-end, you don't have any good integrity mechanism at all!\n\nLet me try to explain what this is about in very simple words. Because \nmemcpy() does not copy the ECC CRC values along with the data, it is an \nunsafe memory copy mechanism, which may introduce bit-errors without \nnoticing. It does not help to only have ECC RAM or for that sake protect \nthe PCI links.\n\n--HPS\n"},{"id":"470422","messageId":"02e6b8f4-ac5f-fdf5-cea8-58013a3f693d@selasky.org","threadId":"59083","inReplyTo":"Y8NB21PExmifhyeQ@tapette.crustytoothpaste.net","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-16T07:21:30Z","receivedAt":"2023-01-16T07:21:35Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"On 1/15/23 00:59, brian m. carlson wrote:\n>> 3) Illicit contents may be present in binary blobs, which in the future may\n>> be need to be removed without warrant and the only way to do that is by\n>> rebasing and force pushing, which will break \"everything\". It can be\n>> everything from child-porn to expired distribution licenses.\n> This is a problem in every Merkle tree-like system.  Most repositories\n> have some sort of code review or access control that prevents people\n> from generally pushing inappropriate content.  For example, if somebody\n> proposed to push any sort of pornography or other inappropriate content\n> (e.g., a racist screed) to one of my repositories or one of my\n> employer's, I'd refuse to approve or merge such a change, because\n> that wouldn't be appropriate for the repository.\n> \n> I don't feel this is enough of a problem that using a Merkle tree-like\n> construction is a bad idea, given the benefits it offers.\n> \n\nYeah, right. And of course you have all the tools to decode those \nmegabyte big firmware blobs from intel supporting wireless cards all \nover the place to see what is actually inside there, that they are not \nusing some 3rd party code which licence will expire at some point, and \nthen you need to remove those binaries.\n\n--HPS\n"},{"id":"470423","messageId":"3b0af57c-a144-b0e4-d353-6028b3939291@selasky.org","threadId":"59083","inReplyTo":"Y8NB21PExmifhyeQ@tapette.crustytoothpaste.net","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-16T07:23:56Z","receivedAt":"2023-01-16T07:24:09Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"On 1/15/23 00:59, brian m. carlson wrote:\n> However, Git is moving in the direction of stronger cryptographic\n> algorithms, rather than insecure hashing algorithms.  I don't think your\n> proposal is a good idea, nor do I think it's likely to be adopted.\n\nI disagree. There is no need for signing in a version control system. It \njust makes it harder to change things, like the right-to-repair. In my \neyes there is a high chance of abuse, by vendors that do no want others \nto flash or edit their device firmwares.\n\n--HPS\n"},{"id":"470424","messageId":"20230116091346.GC16547@kitsune.suse.cz","threadId":"59083","inReplyTo":"b1984123-569a-c290-8048-158c1c5e08b4@selasky.org","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2023-01-16T09:13:46Z","receivedAt":"2023-01-16T09:14:35Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, Jan 16, 2023 at 08:17:58AM +0100, Hans Petter Selasky wrote:\n> On 1/15/23 14:53, Michal Suchánek wrote:\n> > > Many people think that bit errors cannot happen because the memory uses ECC\n> > > and the file system uses cryptographic hashes to verify the integrity of the\n> > > data. But what many people forget about is that when copying data from\n> > > memory to disk, typically using a DMA channel data is copied w/o any kind of\n> > > integrity protection, because the integrity protection is not end-to-end.\n> > > The integrity protection is only per-link.\n> >\n> > So long as all links have integrity protection it's end-to-end.\n> >\n> \n> Hi Michael,\n> \n> You clearly don't see what this is about! Only if the same CRC mechanism is\n> end-to-end, you don't have any good integrity mechanism at all!\n> \n> Let me try to explain what this is about in very simple words. Because\n> memcpy() does not copy the ECC CRC values along with the data, it is an\n> unsafe memory copy mechanism, which may introduce bit-errors without\n> noticing. It does not help to only have ECC RAM or for that sake protect the\n> PCI links.\nThe ECC protects against 1bit errors - so long as only 1 bit is flipped\nalong that path it is corrected.\n\nIf you have bigger errors ECC can sometimes detect them and your system\ncrashes or whatever, and sometimes they go unnoticed.\n\nIt does not make sense to copy around that CRC. It is used to recover\nthe corrupted bit, and when that data is copied to a new location a new\nCRC is calculated that can detect an error in that location. Copying\nthat checksum around would only accumulate the errors.\n\nOf course, that assumes that the corruption happens only in the cheaper\nexternal long-term storage, and data does not get corrupted as it goes\nthrough your CPU where it is stored only a few CPU cycles at a time. It\nis mostly the case but when you need extreme reliability system-level\nschemes that mitigate this possibility do exist.\n\nThanks\n\nMichal\n"},{"id":"470425","messageId":"6a398405-e5f8-0b78-e463-41d79e49e78b@selasky.org","threadId":"59083","inReplyTo":"20230116091346.GC16547@kitsune.suse.cz","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-16T09:55:34Z","receivedAt":"2023-01-16T09:56:13Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"On 1/16/23 10:13, Michal Suchánek wrote:\n> when that data is copied to a new location a new\n> CRC is calculated that can detect an error in that location.\n\nYes, that is correct, but what is \"copying data\"? Are you saying that \ncopying data is always error free?\n\n--HPS\n"},{"id":"470429","messageId":"017801d929a6$6f8271b0$4e875510$@nexbridge.com","threadId":"59083","inReplyTo":"6a398405-e5f8-0b78-e463-41d79e49e78b@selasky.org","subject":"RE: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2023-01-16T12:31:10Z","receivedAt":"2023-01-16T12:31:43Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On January 16, 2023 4:56 AM, Hans Petter Selasky wrote:\n>On 1/16/23 10:13, Michal Suchánek wrote:\n>> when that data is copied to a new location a new CRC is calculated\n>> that can detect an error in that location.\n>\n>Yes, that is correct, but what is \"copying data\"? Are you saying that copying data is\n>always error free?\n\nNot in all possible computing devices, no. But in certain high-reliability and mission critical systems, there are parity checks and communication mechanisms that verify the integrity of data transfers memory-to-memory, memory-to-register, and over inter-CPU bus, and memory-to-disk-storage checks. The result of a corruption on one of my systems would result in a CPU halt rather than blindly accepting the result, taking the faulty processor offline until the cause is investigated and then reloaded or repaired. This applies to any component, including disks, CLIMs, DMA, and anything else in the architecture.\n\n"},{"id":"470430","messageId":"017901d929a6$ec180f50$c4482df0$@nexbridge.com","threadId":"59083","inReplyTo":"3b0af57c-a144-b0e4-d353-6028b3939291@selasky.org","subject":"RE: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2023-01-16T12:34:43Z","receivedAt":"2023-01-16T12:35:12Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On January 16, 2023 2:24 AM, Hans Petter Selasky wrote:\n>On 1/15/23 00:59, brian m. carlson wrote:\n>> However, Git is moving in the direction of stronger cryptographic\n>> algorithms, rather than insecure hashing algorithms.  I don't think\n>> your proposal is a good idea, nor do I think it's likely to be adopted.\n>\n>I disagree. There is no need for signing in a version control system. It just makes it\n>harder to change things, like the right-to-repair. In my eyes there is a high chance\n>of abuse, by vendors that do no want others to flash or edit their device\n>firmwares.\n\nThe two matters are completely isolated and distinct. In the OpenSource community, anyone typically has the right to modify. Please refer to the GPLv3, ECLIPSE, and MIT licenses for example. Those are the governing documents that permit modification and define intellectual property rights. Please consult those licenses with regards to right-to-repair statements that have no legal bearing on git or any other GPL-governed software product. In my view, the issue raised is a red herring that keeps getting brought up, which does not contribute positively to this request's discussion, but would presumably would increase the hit rate on web searches, to which this reply unfortunately contributes.\n\nThe assertion of no need for signing can apply to a centralized version control system, like SVN, because users are authenticated centrally, and the contribution can be made definitive without a separate signature, providing no one with root authority on the server hacks the repository. In the architecture of a distributed version control system (specifically git for this discussion), there is no evidence of origin of changes because the commit identity is cooperative rather than being enforced by a central authority and hacking the repository by root is detectible. The assertion of signing as abuse of rights is also an opinion that, so far, has no supporting evidence given. Perhaps a paper in a refereed journal might give this position some credibility.\n\nMy point is that signing is critical in a DVCS and a major function point used by DevOps architects for adopting git in new organizations. In the regulated world, FinTech, FDA, Aviation, etc., signing contributes to the evidence of origin of changes required by PCI and SWIFT (ref: section 6 in each regulation). Without signed tags (which the establishes the change origins for releases for production use), deployment becomes less certain and less acceptable to the audit community with whom I interact on a regular basis.\n\n--Randall\n\n\n"},{"id":"470433","messageId":"85788356-14b1-6afb-c78c-0ab889bbbb59@selasky.org","threadId":"59083","inReplyTo":"017901d929a6$ec180f50$c4482df0$@nexbridge.com","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-16T14:01:07Z","receivedAt":"2023-01-16T14:01:40Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"On 1/16/23 13:34, rsbecker@nexbridge.com wrote:\n> On January 16, 2023 2:24 AM, Hans Petter Selasky wrote:\n>> On 1/15/23 00:59, brian m. carlson wrote:\n>>> However, Git is moving in the direction of stronger cryptographic\n>>> algorithms, rather than insecure hashing algorithms.  I don't think\n>>> your proposal is a good idea, nor do I think it's likely to be adopted.\n>>\n>> I disagree. There is no need for signing in a version control system. It just makes it\n>> harder to change things, like the right-to-repair. In my eyes there is a high chance\n>> of abuse, by vendors that do no want others to flash or edit their device\n>> firmwares.\n> \n\nHi,\n\n> The two matters are completely isolated and distinct. In the OpenSource community, anyone typically has the right to modify. Please refer to the GPLv3, ECLIPSE, and MIT licenses for example. Those are the governing documents that permit modification and define intellectual property rights. Please consult those licenses with regards to right-to-repair statements that have no legal bearing on git or any other GPL-governed software product. In my view, the issue raised is a red herring that keeps getting brought up, which does not contribute positively to this request's discussion, but would presumably would increase the hit rate on web searches, to which this reply unfortunately contributes.\n\nThe use of cryptographic hash tags, allows one party to stay in control \nof and monetize a project, actually by doing nothing more than \nrebranding an existing product.\n\n> The assertion of no need for signing can apply to a centralized version control system, like SVN, because users are authenticated centrally, and the contribution can be made definitive without a separate signature, providing no one with root authority on the server hacks the repository. In the architecture of a distributed version control system (specifically git for this discussion), there is no evidence of origin of changes because the commit identity is cooperative rather than being enforced by a central authority and hacking the repository by root is detectible. The assertion of signing as abuse of rights is also an opinion that, so far, has no supporting evidence given. Perhaps a paper in a refereed journal might give this position some credibility.\n\n From what I've read the GPLv3 goes pretty far to also provide flashing \nrights for software, but what use is that, when flashing the unsigned \nsoftware on your Samsung phone, for example, some fuse breaks in the \nhardware, and then you can no longer use certain apps on your phone?\n\n> \n> My point is that signing is critical in a DVCS and a major function point used by DevOps architects for adopting git in new organizations. In the regulated world, FinTech, FDA, Aviation, etc., signing contributes to the evidence of origin of changes required by PCI and SWIFT (ref: section 6 in each regulation). Without signed tags (which the establishes the change origins for releases for production use), deployment becomes less certain and less acceptable to the audit community with whom I interact on a regular basis.\n> \n\nIt's very clear to me, that supporting signing straight off the VCS, \nwill not help the opensource and right-to-repair community at all. It's \njust ripe for abuse, like I say.\n\nHacking is prevented by using a secure copy mechanism between the \nservers, which you can upgrade separately. You already see the problem, \nSHA-1 is not good enough to prevent hacking. Why not just separate the \nhacking preventing measures and the needs of a good VCS?\n\n--HPS\n"},{"id":"470434","messageId":"31a33eac-5f1b-969a-6e34-2fc18e989293@selasky.org","threadId":"59083","inReplyTo":"017801d929a6$6f8271b0$4e875510$@nexbridge.com","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Hans Petter Selasky","fromEmail":"hps@selasky.org","sentAt":"2023-01-16T14:10:41Z","receivedAt":"2023-01-16T14:28:37Z","isPatch":false,"sender":{"key":"hps@selasky.org","avatar":"https://gravatar.com/avatar/574493343874307c721bb8826c487ad2f070c55437d734d9d7130ae98f50ea25?d=mp&s=160"},"body":"On 1/16/23 13:31, rsbecker@nexbridge.com wrote:\n> On January 16, 2023 4:56 AM, Hans Petter Selasky wrote:\n>> On 1/16/23 10:13, Michal Suchánek wrote:\n>>> when that data is copied to a new location a new CRC is calculated\n>>> that can detect an error in that location.\n>>\n>> Yes, that is correct, but what is \"copying data\"? Are you saying that copying data is\n>> always error free?\n> \n> Not in all possible computing devices, no. But in certain high-reliability and mission critical systems, there are parity checks and communication mechanisms that verify the integrity of data transfers memory-to-memory, memory-to-register, and over inter-CPU bus, and memory-to-disk-storage checks. The result of a corruption on one of my systems would result in a CPU halt rather than blindly accepting the result, taking the faulty processor offline until the cause is investigated and then reloaded or repaired. This applies to any component, including disks, CLIMs, DMA, and anything else in the architecture.\n> \n\nHi,\n\nI doesn't matter if the system is high-reliability or not. The problem \nis exactly the same.\n\nIf you have a CPU register which you add to another CPU register, then \nyou need to recompute the parity information on the destination CPU \nregister. That basically means you always trust the output of the CPU \nadder. There is simply no relationship between input parity and output \nparity in the linear adder case.\n\nWhenever \"parity\" information is lost, it opens up the possiblity of \nirrecoverable errors.\n\nThat's why I say, that GIT would be better of in that regard with an \nend-to-end, CRC parity mechanism.\n\n--HPS\n"},{"id":"470435","messageId":"xmqqbkmyecym.fsf@gitster.g","threadId":"59083","inReplyTo":"85788356-14b1-6afb-c78c-0ab889bbbb59@selasky.org","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-16T15:06:09Z","receivedAt":"2023-01-16T15:17:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hans Petter Selasky <hps@selasky.org> writes:\n\n> From what I've read the GPLv3 goes pretty far to also provide flashing\n> rights for software, but what use is that, when flashing the unsigned\n> software on your Samsung phone, for example, some fuse breaks in the\n> hardware, and then you can no longer use certain apps on your phone?\n\nIt smells that you are conflating the signing of source material and\nthe sealing of tivoized hardware that use cryptographic signature to\ntell what binaries are allowed to run on it.\n\nThe signing implemented by the software we the Git development\ncommunity build is not about the latter.  The source used to build\nbinaries for your tivoized hardware can come from a VCS that is\ndeliberately designed to allow object name collisions, and your\nbuild would just be locked out the same unless you have the signing\nkey that pleases the hardware.  Use of Git there would not make the\nstory any different, I am afraid.\n\n\n"},{"id":"470455","messageId":"20230116190807.GF16547@kitsune.suse.cz","threadId":"59083","inReplyTo":"6a398405-e5f8-0b78-e463-41d79e49e78b@selasky.org","subject":"Re: Gitorious should use CRC128 / 256 / 512 instead of SHA-1","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2023-01-16T19:08:07Z","receivedAt":"2023-01-16T19:08:18Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Mon, Jan 16, 2023 at 10:55:34AM +0100, Hans Petter Selasky wrote:\n> On 1/16/23 10:13, Michal Suchánek wrote:\n> > when that data is copied to a new location a new\n> > CRC is calculated that can detect an error in that location.\n> \n> Yes, that is correct, but what is \"copying data\"? Are you saying that\n> copying data is always error free?\n\nMaybe you should not cut out the answer to your qestion?\n\nThanks\n\nMichal\n"}]}