Fossil SCM
Updated the discussion of SHA-3 support in Fossil within the fossil-v-git.wiki doc now that Fossil 2.10 is out. Basically, it changes the tense on all SHA-1 text to past tense.
Commit
d887a6d74d7958c069a2da22345e8bd4b0c33a4bbb6ff62b01e2882192ce9642
Parent
21c7f1f8a3b971c…
1 file changed
+12
-14
+12
-14
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -516,12 +516,12 @@ | ||
| 516 | 516 | |
| 517 | 517 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 518 | 518 | of changes, but Git tends to focus more on individual branches of |
| 519 | 519 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 520 | 520 | |
| 521 | -For example, the default "sync" behavior in Git is to only sync | |
| 522 | -a single branch, whereas with Fossil the only sync option it to | |
| 521 | +For example, the default behavior in Git is to only synchronize | |
| 522 | +a single branch, whereas with Fossil the only sync option is to | |
| 523 | 523 | sync the entire DAG. Git commands, |
| 524 | 524 | GitHub, and GitLab tend to show only a single branch at |
| 525 | 525 | a time, whereas Fossil usually shows all parallel branches at |
| 526 | 526 | once. Git has commands like "rebase" that help keep all relevant |
| 527 | 527 | changes on a single branch, whereas Fossil encourages a style of |
| @@ -710,11 +710,11 @@ | ||
| 710 | 710 | currently 41 lines long, to which you want to add the 600 lines of |
| 711 | 711 | [./branching.wiki | the branching document]. The equivalent |
| 712 | 712 | documentation in Git is the aggregation of the man pages for the above |
| 713 | 713 | three commands, which is over 1000 lines, much of it mutually redundant. |
| 714 | 714 | (e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get |
| 715 | -described three different times, each time differently.) Fossil's | |
| 715 | +described three times, each time differently.) Fossil's | |
| 716 | 716 | documentation is not only more concise, it gives a nice split of brief |
| 717 | 717 | online help and full online documentation. |
| 718 | 718 | |
| 719 | 719 | |
| 720 | 720 | <h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> |
| @@ -726,21 +726,19 @@ | ||
| 726 | 726 | Fossil delivered a new release allowing a clean migration to |
| 727 | 727 | [https://en.wikipedia.org/wiki/SHA-3|256-bit SHA-3] with |
| 728 | 728 | [./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based |
| 729 | 729 | repositories. |
| 730 | 730 | |
| 731 | -Here in mid-2019, that feature is now in every OS and package repository | |
| 732 | -known to include Fossil so that the next release | |
| 733 | -(Fossil 2.10) will begin using SHA-3 hashes even on repos currently | |
| 734 | -limited to SHA-1 for compatibility with Fossil 1.<i>x</i>, | |
| 735 | -effectively upgrading them to require Fossil 2.1 or newer. This | |
| 736 | -not only solves the SHAttered problem, it should prevent a reoccurrence | |
| 737 | -for the foreseeable future. With the current release (Fossil 2.9) only | |
| 738 | -repositories created before the | |
| 739 | -transition to Fossil 2 are still using SHA-1, and then only if the | |
| 740 | -repository's maintainer chose not to switch them into SHA-3 mode some | |
| 741 | -time over the past 2 years. | |
| 731 | +By mid-2019, that feature arrived in every software package repository | |
| 732 | +shipping Fossil, the last mover being Debian's stable package repo, | |
| 733 | +which has a highly conservative policy on upgrading to new versions. | |
| 734 | +With that hurdle run, we were able to change the default hash mode in | |
| 735 | +Fossil 2.10 (released 2019-10-04) to require SHA-3 support both for new | |
| 736 | +repositories and to create SHA-3 hashes in existing repos, effectively | |
| 737 | +upgrading them if they were created with Fossil 1.<i>x</i>. This not | |
| 738 | +only solves the SHAttered problem, it should prevent a reoccurrence of | |
| 739 | +similar problems for the foreseeable future. | |
| 742 | 740 | |
| 743 | 741 | Meanwhile, the Git community took until August 2018 to announce |
| 744 | 742 | [https://git-scm.com/docs/hash-function-transition/2.18.0|their plan] |
| 745 | 743 | for solving the same problem by moving to SHA-256 (a variant of the |
| 746 | 744 | [https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until |
| 747 | 745 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -516,12 +516,12 @@ | |
| 516 | |
| 517 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 518 | of changes, but Git tends to focus more on individual branches of |
| 519 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 520 | |
| 521 | For example, the default "sync" behavior in Git is to only sync |
| 522 | a single branch, whereas with Fossil the only sync option it to |
| 523 | sync the entire DAG. Git commands, |
| 524 | GitHub, and GitLab tend to show only a single branch at |
| 525 | a time, whereas Fossil usually shows all parallel branches at |
| 526 | once. Git has commands like "rebase" that help keep all relevant |
| 527 | changes on a single branch, whereas Fossil encourages a style of |
| @@ -710,11 +710,11 @@ | |
| 710 | currently 41 lines long, to which you want to add the 600 lines of |
| 711 | [./branching.wiki | the branching document]. The equivalent |
| 712 | documentation in Git is the aggregation of the man pages for the above |
| 713 | three commands, which is over 1000 lines, much of it mutually redundant. |
| 714 | (e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get |
| 715 | described three different times, each time differently.) Fossil's |
| 716 | documentation is not only more concise, it gives a nice split of brief |
| 717 | online help and full online documentation. |
| 718 | |
| 719 | |
| 720 | <h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> |
| @@ -726,21 +726,19 @@ | |
| 726 | Fossil delivered a new release allowing a clean migration to |
| 727 | [https://en.wikipedia.org/wiki/SHA-3|256-bit SHA-3] with |
| 728 | [./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based |
| 729 | repositories. |
| 730 | |
| 731 | Here in mid-2019, that feature is now in every OS and package repository |
| 732 | known to include Fossil so that the next release |
| 733 | (Fossil 2.10) will begin using SHA-3 hashes even on repos currently |
| 734 | limited to SHA-1 for compatibility with Fossil 1.<i>x</i>, |
| 735 | effectively upgrading them to require Fossil 2.1 or newer. This |
| 736 | not only solves the SHAttered problem, it should prevent a reoccurrence |
| 737 | for the foreseeable future. With the current release (Fossil 2.9) only |
| 738 | repositories created before the |
| 739 | transition to Fossil 2 are still using SHA-1, and then only if the |
| 740 | repository's maintainer chose not to switch them into SHA-3 mode some |
| 741 | time over the past 2 years. |
| 742 | |
| 743 | Meanwhile, the Git community took until August 2018 to announce |
| 744 | [https://git-scm.com/docs/hash-function-transition/2.18.0|their plan] |
| 745 | for solving the same problem by moving to SHA-256 (a variant of the |
| 746 | [https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until |
| 747 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -516,12 +516,12 @@ | |
| 516 | |
| 517 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 518 | of changes, but Git tends to focus more on individual branches of |
| 519 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 520 | |
| 521 | For example, the default behavior in Git is to only synchronize |
| 522 | a single branch, whereas with Fossil the only sync option is to |
| 523 | sync the entire DAG. Git commands, |
| 524 | GitHub, and GitLab tend to show only a single branch at |
| 525 | a time, whereas Fossil usually shows all parallel branches at |
| 526 | once. Git has commands like "rebase" that help keep all relevant |
| 527 | changes on a single branch, whereas Fossil encourages a style of |
| @@ -710,11 +710,11 @@ | |
| 710 | currently 41 lines long, to which you want to add the 600 lines of |
| 711 | [./branching.wiki | the branching document]. The equivalent |
| 712 | documentation in Git is the aggregation of the man pages for the above |
| 713 | three commands, which is over 1000 lines, much of it mutually redundant. |
| 714 | (e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get |
| 715 | described three times, each time differently.) Fossil's |
| 716 | documentation is not only more concise, it gives a nice split of brief |
| 717 | online help and full online documentation. |
| 718 | |
| 719 | |
| 720 | <h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> |
| @@ -726,21 +726,19 @@ | |
| 726 | Fossil delivered a new release allowing a clean migration to |
| 727 | [https://en.wikipedia.org/wiki/SHA-3|256-bit SHA-3] with |
| 728 | [./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based |
| 729 | repositories. |
| 730 | |
| 731 | By mid-2019, that feature arrived in every software package repository |
| 732 | shipping Fossil, the last mover being Debian's stable package repo, |
| 733 | which has a highly conservative policy on upgrading to new versions. |
| 734 | With that hurdle run, we were able to change the default hash mode in |
| 735 | Fossil 2.10 (released 2019-10-04) to require SHA-3 support both for new |
| 736 | repositories and to create SHA-3 hashes in existing repos, effectively |
| 737 | upgrading them if they were created with Fossil 1.<i>x</i>. This not |
| 738 | only solves the SHAttered problem, it should prevent a reoccurrence of |
| 739 | similar problems for the foreseeable future. |
| 740 | |
| 741 | Meanwhile, the Git community took until August 2018 to announce |
| 742 | [https://git-scm.com/docs/hash-function-transition/2.18.0|their plan] |
| 743 | for solving the same problem by moving to SHA-256 (a variant of the |
| 744 | [https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until |
| 745 |