Fossil

Check-in [c5461fb5]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Relaxed the "enforcing" language around the planned change of hash policy from "auto" to "sha3" in Fossil 2.10 within section 2.8 of the fossil-v-git.wiki doc, and clarified what will actually happen with that release as compared to the current release.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: c5461fb599b20002a48e7ddf9228e6022ee47f9109f079bba26ccab4cb654e5c
User & Date: wyoung 2019-08-16 03:33:43.723
Context
2019-08-18
00:59
Include forum artifact statistics on the /artifact_stats page. ... (check-in: e2f2a05e user: drh tags: trunk)
2019-08-16
03:33
Relaxed the "enforcing" language around the planned change of hash policy from "auto" to "sha3" in Fossil 2.10 within section 2.8 of the fossil-v-git.wiki doc, and clarified what will actually happen with that release as compared to the current release. ... (check-in: c5461fb5 user: wyoung tags: trunk)
01:57
Another spell check pass on www/* using a different dictionary than in the prior pass. ([79c2cb083152]) ... (check-in: 0996347d user: wyoung tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/fossil-v-git.wiki.
︙︙
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482

to take, which amounts to the same thing.) But if you are a professional
software developer, we want you to ask yourself a question: "How do I
get paid more by mastering arcane features of my DVCS?" Unless you have
a good answer to that, you probably do not want to be choosing a DVCS
based on how many arcane features it has.

The argument is similar for other types of users: if you are a hobbyist,
how much time do you want to spend mastering your DVCSs instead of on
the hobby supported by use of that DVCS?

There is some minimal set of features required to achieve the purposes
that drive our selection of a DVCS, but there is a level beyond which
more features only slow us down while we're learning the tool, since we
must plow through documentation on features we're not likely to ever
use. When the number of features grows to the point where people of








|








468
469
470
471
472
473
474
475
476
477
478
479
480
481
482

to take, which amounts to the same thing.) But if you are a professional
software developer, we want you to ask yourself a question: "How do I
get paid more by mastering arcane features of my DVCS?" Unless you have
a good answer to that, you probably do not want to be choosing a DVCS
based on how many arcane features it has.

The argument is similar for other types of users: if you are a hobbyist,
how much time do you want to spend mastering your DVCS instead of on
the hobby supported by use of that DVCS?

There is some minimal set of features required to achieve the purposes
that drive our selection of a DVCS, but there is a level beyond which
more features only slow us down while we're learning the tool, since we
must plow through documentation on features we're not likely to ever
use. When the number of features grows to the point where people of
︙︙
601
602
603
604
605
606
607
608
609


610

611
612
613
614
615
616
617
618

collisions were now practical to create. Two weeks later, the creator of
Fossil delivered a new release allowing a clean migration to
[https://en.wikipedia.org/wiki/SHA-3|256-bit SHA-3] with
[./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based
repositories.

Here in mid-2019, that feature is now in every OS and package repository
known to include Fossil so that the next release as of this writing
(Fossil 2.10) will default to enforcing SHA-3 hashes by default. This


not only solves the SHAttered problem, it should prevent a reoccurrence

for the foreseeable future. Only repositories created before the
transition to Fossil 2 are still using SHA-1, and then only if the
repository's maintainer chose not to switch them into SHA-3 mode some
time over the past 2 years.

Meanwhile, the Git community took until August 2018 to announce
[https://git-scm.com/docs/hash-function-transition/2.18.0|their plan]
for solving the same problem by moving to SHA-256 (a variant of the








|
|
>
>

>
|








601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621

collisions were now practical to create. Two weeks later, the creator of
Fossil delivered a new release allowing a clean migration to
[https://en.wikipedia.org/wiki/SHA-3|256-bit SHA-3] with
[./hashpolicy.wiki|full backwards compatibility] to old SHA-1 based
repositories.

Here in mid-2019, that feature is now in every OS and package repository
known to include Fossil so that the next release
(Fossil 2.10) will begin using SHA-3 hashes even on repos currently
limited to SHA-1 for compatibility with Fossil 1.<i>x</i>,
effectively upgrading them to require Fossil 2.1 or newer. This
not only solves the SHAttered problem, it should prevent a reoccurrence
for the foreseeable future. With the current release (Fossil 2.9) only
repositories created before the
transition to Fossil 2 are still using SHA-1, and then only if the
repository's maintainer chose not to switch them into SHA-3 mode some
time over the past 2 years.

Meanwhile, the Git community took until August 2018 to announce
[https://git-scm.com/docs/hash-function-transition/2.18.0|their plan]
for solving the same problem by moving to SHA-256 (a variant of the
︙︙