Security patch is now available.
(1.1) Originally by Richard Hipp (drh) with edits by Stephan Beal (stephan) on 2021-06-15 09:57:56 from 1.0 [source]
It has been discovered that the client-side TLS implementation in Fossil was often failing to verify that the hostname of the server matched the hostname contained in the TLS certificate. Hence, an "https" connection would always work as long as the server returned any valid certificate, even if that certificate did not match the hostname.
This problem has now been patched on trunk, and on the 2.15 and 2.14 branches.
Fresh downloads are available on the download page. Though not a crisis, upgrading is recommended. Make sure you are using one of the following versions of Fossil (in order of preference):
- Builds from any check-in dated 2021-06-15 or later
- Version 2.15.2
- Version 2.14.2
(edited by Stephan to correct version number.)
(2) By ravbc on 2021-06-15 09:35:34 in reply to 1.0 [link] [source]
- Version 2.15.1
Shouldn't this be 2.14.2 ?
(3) By Stephan Beal (stephan) on 2021-06-15 09:58:33 in reply to 2 [link] [source]
Shouldn't this be 2.14.2 ?
Correct. Fixed!
(4) By sean (jungleboogie) on 2021-06-15 13:20:00 in reply to 1.1 [link] [source]
May we know if an anonymous passer-by told you this or it was discovered 'in-house'?
(5) By Richard Hipp (drh) on 2021-06-15 14:00:50 in reply to 4 [link] [source]
It was discussed in the developers' chatroom.
(6) By anonymous on 2021-06-16 02:33:38 in reply to 1.1 [link] [source]
Hi,
I package fossil for OpenBSD and updating our port for 2.15.2. It seems tarballs are no longer being uploaded to https://fossil-scm.org/home/uv/ like with previous releases.
I'm guessing the new /home/tarball/ urls are generating the tarballs on the fly which is never a good idea for those of use who create ports that ship checksums. Also I've noticed https://fossil-scm.org/home/tarball/fossil-2.15.2.tar.gz?r=version-2.15.2 and https://fossil-scm.org/home/tarball/fossil-2.15.2.tar.gz yield different size packages.
(7.1) By Stephan Beal (stephan) on 2021-06-16 02:42:23 edited from 7.0 in reply to 6 [link] [source]
I package fossil for OpenBSD and updating our port for 2.15.2. It seems tarballs are no longer being uploaded to https://fossil-scm.org/home/uv/ like with previous releases.
This was being fixed right about the time you posted. Please try again.
Edit:
I'm guessing the new /home/tarball/ urls are generating the tarballs on the fly which is never a good idea for those of use who create ports that ship checksums.
Based on a comment in the chatroom, that is now exactly what is happening in order to avoid having to retain X copies of old, large binaries as unversioned state. The tarballs should be byte-for-byte identical on each rebuild. The metadata for the included files, including their timestamps, is based on their repo-side state.
Also I've noticed https://fossil-scm.org/home/tarball/fossil-2.15.2.tar.gz?r=version-2.15.2 and https://fossil-scm.org/home/tarball/fossil-2.15.2.tar.gz yield different size packages.
They are different. One of the side effects of building from a tag (the first link) is that you get the latest version of that tag:
$ cat f2/manifest.uuid f1/manifest.uuid
e0ebe6f0338825affb13e19d3f9c2af96c292ca73308a5d7dc38d7e9ec03cfbd
7cfd58d771e77123dcccfce67da9da633fdba912b6e7019a84912146aa8f06ba
(8) By anonymous on 2021-06-16 02:40:41 in reply to 7.0 [link] [source]
Thanks, I see the uploaded tarball now!
(9) By Richard Hipp (drh) on 2021-06-16 02:57:18 in reply to 7.1 [link] [source]
The tarballs should be byte-for-byte identical on each rebuild.
The tarball content should be identical. But, if we recompile fossil with an updated version of zlib, does that mean that the compression might be a little different, and thus the compressed tarball might not be byte-for-byte the same?
Does that matter?
In the SQLite README.md file, near the bottom, I have a paragraph that describes how to verify the integrity of an SQLite source tarball by referencing the SHA1 and SHA3 hashes in the "manifest" file. Should we perhaps provide a utility program, or a new Fossil command, or both, that verifies the integrity of a tarball or ZIP archive based on the manifest file contained within that archive?
(10) By Richard Hipp (drh) on 2021-06-16 03:01:52 in reply to 9 [link] [source]
Maybe we need a "sha3sum" type of program that operates directly on a tarball or ZIP archive, but instead of blindly hashing the bytes of the archive, instead hashes the archive content. Such a "content-hash" would always be the same, even if the archive is recomputed using a different version of zlib.
(11) By ravbc on 2021-06-16 08:01:17 in reply to 10 [link] [source]
This won't help distributions - they keep a checksum of a source package on their side, just to be sure that whenever (and wherever) a given version of packaged software is build, it is always compiled from exactly the same source. And they probably wouldn't want to change own packaging framework to accommodate just to fossils packaging "quirks". Especially when providing static tarball isn't very tedious. Just my $0.03. ;-)
(12.1) By Richard Hipp (drh) on 2021-06-16 13:43:45 edited from 12.0 in reply to 9 [link] [source]
The links to the source tarballs on the download page were originally coded like this:
/tarball/filename?r=tag
For example:
/tarball/fossil-src-2.15.2?r=version-2.15.2
But with that encoding, anything tagged as "version-2.15.2" might be downloaded. Any developer could add the tag "version-2.15.2" to any check-in and that would case the tagged check-in to be downloaded.
We prefer that the Download page only deliver the official release. To enforce this, the download link for the source tarballs has been changed to follow this template:
/tarball/full-SHA3-hash/filename
For example:
/tarball/7cfd58d771e77123dcccfce67da9da633fdba912b6e7019a84912146aa8f06ba/fossil-2.15.2.tar.gz
This causes check-in 7cfd58d771e77 to be delivered always. It is not possible to surreptitiously change the deliverable by adjusting tags.
(13) By anonymous on 2021-06-16 13:17:47 in reply to 12.0 [link] [source]
Thank you.