Fossil SCM
Updates to the hashpolicy.wiki document. The recent attention it received on HN caused me to notice that it needed refreshing.
Commit
2f5bb4f04deb9ad8435b8c8f98f797f25f0e26758c85eb284a017dc62b9bf2d4
Parent
ea66927c0cb112a…
1 file changed
+29
-10
+29
-10
| --- www/hashpolicy.wiki | ||
| +++ www/hashpolicy.wiki | ||
| @@ -6,14 +6,19 @@ | ||
| 6 | 6 | |
| 7 | 7 | There was much angst over the [http://www.shattered.io|SHAttered attack] |
| 8 | 8 | against SHA1 when it was announced in early 2017. If you are concerned |
| 9 | 9 | about this and its implications for Fossil, simply |
| 10 | 10 | [./quickstart.wiki#install|upgrade to Fossil 2.1 or later], and the |
| 11 | -problem will go away. Everything will continue to work as before. All | |
| 12 | -of your legacy repositories will continue to work, and all of your old | |
| 13 | -check-ins will still have the same name. Your workflow will be | |
| 14 | -unchanged. | |
| 11 | +problem will go away. Everything will continue to work as before. | |
| 12 | + | |
| 13 | + * All of your legacy repositories will continue to work, without | |
| 14 | + needing any changes or upgrades. | |
| 15 | + * All of your historical check-ins will still have the same historical | |
| 16 | + SHA1 names. | |
| 17 | + * Your new check-ins will get more secure SHA3-256 hash names. | |
| 18 | + * Your workflow will be unchanged. | |
| 19 | + * Everything will continue as if nothing happened. | |
| 15 | 20 | |
| 16 | 21 | But if you are curious and want a deeper understanding of what is |
| 17 | 22 | going on, read on... |
| 18 | 23 | |
| 19 | 24 | |
| @@ -75,20 +80,30 @@ | ||
| 75 | 80 | (SHA3-256 is the only variant of SHA3 that |
| 76 | 81 | Fossil uses for artifact naming, so for the remainder of this article |
| 77 | 82 | it will be called simply "SHA3". Similarly, "Hardened SHA1" will |
| 78 | 83 | shortened to "SHA1" in the remaining text.) |
| 79 | 84 | |
| 85 | +To be clear: Fossil (version 2.0 and later) | |
| 86 | +allows the SHA1 and SHA3 hashes to be mixed within | |
| 87 | +the same repository. Older check-ins, created years ago, | |
| 88 | +continue to be named using their legacy SHA1 hashes while | |
| 89 | +newer check-ins are named using modern SHA3 hashes. There | |
| 90 | +is not need to "convert" a repository from SHA1 over to SHA3. | |
| 91 | +You can see this in Fossil itself. The recent | |
| 92 | +[9d9ef82234f63758] check-in uses a SHA3 hash where as the older | |
| 93 | +[1669115ab9d05c18] check-in uses a SHA1 hash. | |
| 94 | + | |
| 80 | 95 | Other than permitting the use of SHA3 in addition to SHA1, there |
| 81 | 96 | were no file format changes in Fossil version 2.0 relative |
| 82 | 97 | to the previous version 1.37. Both Fossil 2.0 and Fossil 1.37 read |
| 83 | 98 | and write all the same repositories and sync with one another, as long |
| 84 | 99 | as none of the repositories contain artifacts named using SHA3. If |
| 85 | 100 | a repository does contain artifacts named using SHA3, Fossil 1.37 will |
| 86 | 101 | not know how to interpret those artifacts and will generate various warnings |
| 87 | 102 | and errors. |
| 88 | 103 | |
| 89 | -<h2>How Fossil Decides Which Hash Algorithm To Use</h2> | |
| 104 | +<h2>How Fossil Decides Which Hash Algorithm To Use For New Artifacts</h2> | |
| 90 | 105 | |
| 91 | 106 | If newer versions of Fossil are able to use either SHA1 or SHA3 to |
| 92 | 107 | name artifacts, which hash algorithm is actually used? That question |
| 93 | 108 | is answered by the "hash policy". These are the supported hash policies: |
| 94 | 109 | |
| @@ -168,14 +183,18 @@ | ||
| 168 | 183 | artifacts with SHA3 names, because once you do that your recalcitrant |
| 169 | 184 | coworkers will no longer be able to collaborate. |
| 170 | 185 | |
| 171 | 186 | <h2>A Pure SHA3 Future</h2> |
| 172 | 187 | |
| 173 | -Fossil 2.10 will change the default hash policy to "sha3" mode. We | |
| 174 | -decided to make the change since the last known distributor of Fossil | |
| 175 | -1.x binaries — Debian 9 — was finally replaced in June 2019 by a newer | |
| 176 | -version distributing Fossil 2.x. All other known sources of Fossil 1.x | |
| 177 | -binaries upgraded well before that point. | |
| 188 | +Fossil 2.10 changed the default hash policy to "sha3" mode. So if you | |
| 189 | +upgrade to the latest version of Fossil, all of your new artifacts will | |
| 190 | +use a SHA3 hash. Legacy SHA1 artifacts continue to use their original | |
| 191 | +names but new artifacts will use SHA3 names. | |
| 192 | + | |
| 193 | +We decided to make the change pur SHA3 since the last known distributor | |
| 194 | +of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019 | |
| 195 | +by a newer version distributing Fossil 2.x. All other known sources of | |
| 196 | +Fossil 1.x binaries upgraded well before that point. | |
| 178 | 197 | |
| 179 | 198 | Because Fossil 2.x tends to silently upgrade existing repos to SHA-3 |
| 180 | 199 | mode unless carefully forced not to, you probably won't even notice the |
| 181 | 200 | change. |
| 182 | 201 |
| --- www/hashpolicy.wiki | |
| +++ www/hashpolicy.wiki | |
| @@ -6,14 +6,19 @@ | |
| 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 |
| 10 | [./quickstart.wiki#install|upgrade to Fossil 2.1 or later], and the |
| 11 | problem will go away. Everything will continue to work as before. All |
| 12 | of your legacy repositories will continue to work, and all of your old |
| 13 | check-ins will still have the same name. Your workflow will be |
| 14 | unchanged. |
| 15 | |
| 16 | But if you are curious and want a deeper understanding of what is |
| 17 | going on, read on... |
| 18 | |
| 19 | |
| @@ -75,20 +80,30 @@ | |
| 75 | (SHA3-256 is the only variant of SHA3 that |
| 76 | Fossil uses for artifact naming, so for the remainder of this article |
| 77 | it will be called simply "SHA3". Similarly, "Hardened SHA1" will |
| 78 | shortened to "SHA1" in the remaining text.) |
| 79 | |
| 80 | Other than permitting the use of SHA3 in addition to SHA1, there |
| 81 | were no file format changes in Fossil version 2.0 relative |
| 82 | to the previous version 1.37. Both Fossil 2.0 and Fossil 1.37 read |
| 83 | and write all the same repositories and sync with one another, as long |
| 84 | as none of the repositories contain artifacts named using SHA3. If |
| 85 | a repository does contain artifacts named using SHA3, Fossil 1.37 will |
| 86 | not know how to interpret those artifacts and will generate various warnings |
| 87 | and errors. |
| 88 | |
| 89 | <h2>How Fossil Decides Which Hash Algorithm To Use</h2> |
| 90 | |
| 91 | If newer versions of Fossil are able to use either SHA1 or SHA3 to |
| 92 | name artifacts, which hash algorithm is actually used? That question |
| 93 | is answered by the "hash policy". These are the supported hash policies: |
| 94 | |
| @@ -168,14 +183,18 @@ | |
| 168 | artifacts with SHA3 names, because once you do that your recalcitrant |
| 169 | coworkers will no longer be able to collaborate. |
| 170 | |
| 171 | <h2>A Pure SHA3 Future</h2> |
| 172 | |
| 173 | Fossil 2.10 will change the default hash policy to "sha3" mode. We |
| 174 | decided to make the change since the last known distributor of Fossil |
| 175 | 1.x binaries — Debian 9 — was finally replaced in June 2019 by a newer |
| 176 | version distributing Fossil 2.x. All other known sources of Fossil 1.x |
| 177 | binaries upgraded well before that point. |
| 178 | |
| 179 | Because Fossil 2.x tends to silently upgrade existing repos to SHA-3 |
| 180 | mode unless carefully forced not to, you probably won't even notice the |
| 181 | change. |
| 182 |
| --- www/hashpolicy.wiki | |
| +++ www/hashpolicy.wiki | |
| @@ -6,14 +6,19 @@ | |
| 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 |
| 10 | [./quickstart.wiki#install|upgrade to Fossil 2.1 or later], and the |
| 11 | problem will go away. Everything will continue to work as before. |
| 12 | |
| 13 | * All of your legacy repositories will continue to work, without |
| 14 | needing any changes or upgrades. |
| 15 | * All of your historical check-ins will still have the same historical |
| 16 | SHA1 names. |
| 17 | * Your new check-ins will get more secure SHA3-256 hash names. |
| 18 | * Your workflow will be unchanged. |
| 19 | * Everything will continue as if nothing happened. |
| 20 | |
| 21 | But if you are curious and want a deeper understanding of what is |
| 22 | going on, read on... |
| 23 | |
| 24 | |
| @@ -75,20 +80,30 @@ | |
| 80 | (SHA3-256 is the only variant of SHA3 that |
| 81 | Fossil uses for artifact naming, so for the remainder of this article |
| 82 | it will be called simply "SHA3". Similarly, "Hardened SHA1" will |
| 83 | shortened to "SHA1" in the remaining text.) |
| 84 | |
| 85 | To be clear: Fossil (version 2.0 and later) |
| 86 | allows the SHA1 and SHA3 hashes to be mixed within |
| 87 | the same repository. Older check-ins, created years ago, |
| 88 | continue to be named using their legacy SHA1 hashes while |
| 89 | newer check-ins are named using modern SHA3 hashes. There |
| 90 | is not need to "convert" a repository from SHA1 over to SHA3. |
| 91 | You can see this in Fossil itself. The recent |
| 92 | [9d9ef82234f63758] check-in uses a SHA3 hash where as the older |
| 93 | [1669115ab9d05c18] check-in uses a SHA1 hash. |
| 94 | |
| 95 | Other than permitting the use of SHA3 in addition to SHA1, there |
| 96 | were no file format changes in Fossil version 2.0 relative |
| 97 | to the previous version 1.37. Both Fossil 2.0 and Fossil 1.37 read |
| 98 | and write all the same repositories and sync with one another, as long |
| 99 | as none of the repositories contain artifacts named using SHA3. If |
| 100 | a repository does contain artifacts named using SHA3, Fossil 1.37 will |
| 101 | not know how to interpret those artifacts and will generate various warnings |
| 102 | and errors. |
| 103 | |
| 104 | <h2>How Fossil Decides Which Hash Algorithm To Use For New Artifacts</h2> |
| 105 | |
| 106 | If newer versions of Fossil are able to use either SHA1 or SHA3 to |
| 107 | name artifacts, which hash algorithm is actually used? That question |
| 108 | is answered by the "hash policy". These are the supported hash policies: |
| 109 | |
| @@ -168,14 +183,18 @@ | |
| 183 | artifacts with SHA3 names, because once you do that your recalcitrant |
| 184 | coworkers will no longer be able to collaborate. |
| 185 | |
| 186 | <h2>A Pure SHA3 Future</h2> |
| 187 | |
| 188 | Fossil 2.10 changed the default hash policy to "sha3" mode. So if you |
| 189 | upgrade to the latest version of Fossil, all of your new artifacts will |
| 190 | use a SHA3 hash. Legacy SHA1 artifacts continue to use their original |
| 191 | names but new artifacts will use SHA3 names. |
| 192 | |
| 193 | We decided to make the change pur SHA3 since the last known distributor |
| 194 | of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019 |
| 195 | by a newer version distributing Fossil 2.x. All other known sources of |
| 196 | Fossil 1.x binaries upgraded well before that point. |
| 197 | |
| 198 | Because Fossil 2.x tends to silently upgrade existing repos to SHA-3 |
| 199 | mode unless carefully forced not to, you probably won't even notice the |
| 200 | change. |
| 201 |