Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Updated the hash policy document, mainly to put it in past tense and to cover the current situation. |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
df8baf94069f88823c54b2edb2239b39 |
User & Date: | wyoung 2019-01-06 04:27:57 |
Context
2019-01-07
| ||
01:32 | Fix a typo in the hashpolicy.wiki document. check-in: 3b17294d user: drh tags: trunk | |
2019-01-06
| ||
04:27 | Updated the hash policy document, mainly to put it in past tense and to cover the current situation. check-in: df8baf94 user: wyoung tags: trunk | |
04:10 | Updated the paragraph on SHA1 hashes in www/concepts.wiki to also talk about SHA3-256. check-in: ac2c2c77 user: wyoung tags: trunk | |
Changes
Changes to www/hashpolicy.wiki.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 .. 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 ... 167 168 169 170 171 172 173 |
<title>Hash Policy</title> <h2> Executive Summary, Or How To Avoid Reading This Article </h2> There is much angst over the [http://www.shattered.io|Shattered attack] against SHA1. If you are concerned about this and its implications for Fossil, simply upgrade to Fossil 2.0 or later and the problem will go away. Everything will continue to work as before. All of your legacy repositories will continue to work and all of your old check-ins will still have the same name. Your workflow will be unchanged. But if you are curious and want a deeper understanding of what is going on, read on... <h2> Introduction </h2> The first snapshot-based distributed version control system was [http://www.monotone.ca|Monotone]. Many of the ideas behind the design of Fossil were copied from Monotone, including the use of a SHA1 hash to assign names to artifacts. Git and Mercurial did the same thing. The SHA1 hash algorithm is used only to create names for artifacts in Fossil (and in Git, Mercurial, and Monotone). It is not used for security. Nevertheless, when the [http://www.shattered.io|Shattered attack] found two different PDF files with the same SHA1 hash, many users learned that "SHA1 is broken". They see that Fossil (and Git, Mercurial, and Monotone) use SHA1 and they therefore conclude that "Fossil is broken". This is not true, but it is a public relations problem. So the decision was made to migrate Fossil away from SHA1. This article describes how that migration is occurring. ................................................................................ hashes. Hardened SHA1 is slower (and a lot bigger) but Fossil does not do that much hashing, so performance is not really an issue. All versions of Fossil moving forward will use Hardened SHA1. So if someone says "SHA1 is broken, and Fossil uses SHA1, therefore Fossil is broken", you can rebut the argument by pointing out that Fossil uses <em>Hardened SHA1</em> not generic SHA1 and Hardened SHA1 is <em>not</em> broken. <h2>Support For SHA3-256</h2> Prior to Fossil version 2.0 ([/timeline?c=version-2.0|2017-03-03]), all artifacts in all Fossil repositories were named by only a SHA1 hash. Version 2.0 extended the [./fileformat.wiki|Fossil file format] to allow artifacts to be named by either SHA1 or SHA3-256 hashes. (SHA3-256 is the only variant of SHA3 that Fossil uses for artifact naming, so for the remainder of this article it will be called simply "SHA3". Similarly, "Hardened SHA1" will shortened to "SHA1" in the sequel.) Other than permitting the use of SHA3 in addition to SHA1, there were no file format changes in Fossil version 2.0 relative to the previous version 1.37. Both Fossil 2.0 and Fossil 1.37 read and write all the same repositories and sync with one another, as long as none of the repositories contain artifacts named using SHA3. If a repository does contain artifacts named using SHA3, Fossil 1.37 will ................................................................................ <h2>A Pure SHA3 Future</h2> At some point in the future, years from now, after everybody has finally upgraded to Fossil 2.0 or later, the default hash policy will probably change to "sha3", or maybe even "shun-sha1". By the time that happens, you will probably already be using SHA3 on all your projects and so you are unlikely to notice. |
> > | | > | | | | | | | | | | > > > > > > > |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 .. 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 170 171 172 173 174 175 176 177 178 179 180 181 182 183 |
<title>Hash Policy</title> <h2>Executive Summary</h2> <b>Or: How To Avoid Reading This Article</b> There was much angst over the [http://www.shattered.io|SHAttered attack] against SHA1 when it was announced in early 2017. If you are concerned about this and its implications for Fossil, simply upgrade to Fossil 2.1 or later, and the problem will go away. Everything will continue to work as before. All of your legacy repositories will continue to work, and all of your old check-ins will still have the same name. Your workflow will be unchanged. But if you are curious and want a deeper understanding of what is going on, read on... <h2>Introduction</h2> The first snapshot-based distributed version control system was [http://www.monotone.ca|Monotone]. Many of the ideas behind the design of Fossil were copied from Monotone, including the use of a SHA1 hash to assign names to artifacts. Git and Mercurial did the same thing. The SHA1 hash algorithm is used only to create names for artifacts in Fossil (and in Git, Mercurial, and Monotone). It is not used for security. Nevertheless, when the [http://www.shattered.io|SHAttered attack] found two different PDF files with the same SHA1 hash, many users learned that "SHA1 is broken". They see that Fossil (and Git, Mercurial, and Monotone) use SHA1 and they therefore conclude that "Fossil is broken". This is not true, but it is a public relations problem. So the decision was made to migrate Fossil away from SHA1. This article describes how that migration is occurring. ................................................................................ hashes. Hardened SHA1 is slower (and a lot bigger) but Fossil does not do that much hashing, so performance is not really an issue. All versions of Fossil moving forward will use Hardened SHA1. So if someone says "SHA1 is broken, and Fossil uses SHA1, therefore Fossil is broken," you can rebut the argument by pointing out that Fossil uses <em>Hardened SHA1</em>, not generic SHA1, and Hardened SHA1 is <em>not</em> broken. <h2>Support For SHA3-256</h2> Prior to Fossil version 2.0 ([/timeline?c=version-2.0|2017-03-03]), all artifacts in all Fossil repositories were named by only a SHA1 hash. Version 2.0 extended the [./fileformat.wiki|Fossil file format] to allow artifacts to be named by either SHA1 or SHA3-256 hashes. (SHA3-256 is the only variant of SHA3 that Fossil uses for artifact naming, so for the remainder of this article it will be called simply "SHA3". Similarly, "Hardened SHA1" will shortened to "SHA1" in the remaining text.) Other than permitting the use of SHA3 in addition to SHA1, there were no file format changes in Fossil version 2.0 relative to the previous version 1.37. Both Fossil 2.0 and Fossil 1.37 read and write all the same repositories and sync with one another, as long as none of the repositories contain artifacts named using SHA3. If a repository does contain artifacts named using SHA3, Fossil 1.37 will ................................................................................ <h2>A Pure SHA3 Future</h2> At some point in the future, years from now, after everybody has finally upgraded to Fossil 2.0 or later, the default hash policy will probably change to "sha3", or maybe even "shun-sha1". By the time that happens, you will probably already be using SHA3 on all your projects and so you are unlikely to notice. This probably won't happen until after all of the operating systems shipping binary versions of Fossil switch to Fossil 2.1 or later. The big standout is Debian Stretch (9.0), which is not expected to be replaced until March 2019, and it won't fall out of support until June 2022. We do not yet know if we will switch the default hash policy during that window or not until after Debian 9 is fully out of support. |