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