Fossil Forum

Fossil version 2.12.1 - update recommended
Login

Fossil version 2.12.1 - update recommended

Fossil version 2.12.1 - update recommended

(1) By Richard Hipp (drh) on 2020-08-20 14:50:04 [source]

New Fossil patch releases are available on the download page. Upgrading your Fossil client is recommended. The available releases are:

  • 2.12.1 ← your best choice
  • 2.11.2
  • 2.10.2

These patch releases fix problems in Fossil whereby a collaborator whom you trust can cause harm to your system. The attacks can only be carried out by a site administrator or by someone with check-in privileges on the repository, not by random passers-by on the internet. Nevertheless, these are important vulnerabilities that need to be addressed. You should upgrade at your earliest opportunity.

The patches work exactly the same as prior versions, except that the allow-symlinks property is no longer on by default on unix systems and is no longer a versioned setting. This change is not strictly necessary to fix the problem, though it seems a prudent security precaution. The uncommon user who actually makes use of the legacy behavior can recompile using the -DFOSSIL_LEGACY_ALLOW_SYMLINKS compile-time option, or can run the one-time command:

    fossil setting allow-symlinks on --global

Source code for the patch releases is provided. However, the dozens of check-ins that went into preparing these patches, and tickets describing the problems addressed, will be embargoed for a few days, to give everyone an opportunity to update their clients.

(2) By Sylvain Beucler (beucnet) on 2020-08-20 16:27:54 in reply to 1 [link] [source]

I am confused: does that mean there is no way to securely use symlinks in a Fossil repository?
By comparison, git appears to manage it (doc).
(candid question, no trolling intended)

(3.2) By Richard Hipp (drh) on 2020-08-20 20:00:38 edited from 3.1 in reply to 2 [link] [source]

We believe that activating "allow-symlinks" (and thus turning on the versioning of symlinks) is secure. Nevertheless, the use of symlinks is risky, as the code is complex. Who knows what undiscovered bugs might yet be lurking in the convoluted code needed to manage symlinks safely. So, if you do not need symlinks, it is safest to leave them turned off. Most people do not use symlinks in their repositories. (Some people argue, persuasively I think, that symlinks in a source repository are an abomination.) And so why should we expose the majority of people who do not use symlinks to potential bugs when it is so much safer and easier to just to turn them completely off.

The "allow-symlinks" option was made non-versioned in order to prevent a hostile committer from turning them on without you knowing. If you want to enable symlinks, that's fine. But you, the developer, should make that choice for yourself. Some other collaborator from whom you pulled should not be able to override that choice without your knowledge.

Summary:

  • Using symlinks in Fossil is secure, as far as we know.

  • Nevertheless, they are now off by default, since they are seldom used and there is a risk of undetected bugs. In other words, symbolic links are disabled by default for defense in depth.

  • Future versions of Fossil will include further safety measures to help ensure that symlinks are not abused. Hence future versions of Fossil make the use of symlinks even safer.

(4) By sean (jungleboogie) on 2020-08-20 20:46:21 in reply to 1 [link] [source]

Source code for the patch releases is provided. However, the dozens of check-ins that went into preparing these patches, and tickets describing the problems addressed, will be embargoed for a few days, to give everyone an opportunity to update their clients.

Is this what's preventing has 40feec3291 from being seen on the timeline?

(5) By Stephan Beal (stephan) on 2020-08-20 20:50:04 in reply to 4 [link] [source]

Is this what's preventing has 40feec3291 from being seen on the timeline?

Yes.

It is hilarious that you (of all people) point that out, because i said to someone a couple days ago that if the site is running a version which is not in the timeline, Sean is going to notice the mysterious hash number and ask about it.

(6) By sean (jungleboogie) on 2020-08-20 20:54:12 in reply to 5 [link] [source]

haha. Your prediction came true!!

(7) By Richard Hipp (drh) on 2020-08-22 17:03:55 in reply to 1 [link] [source]

How Long Should The Source Code Be Embargoed?

The dozens of individual check-ins that went into the security patch, and the tickets that describe the security patch, have been embargoed for a while to prevent miscreants from easily finding the vulnerabilities until after everyone has had a chance to update. The question is, how long should that embargo last.

In particular, I observe that people are building and using the Fossil from trunk, which lacks the security patches. Which is better?

  1. Release the source code now, so that people who build from trunk can have immediate access to the security patches

  2. Delay releasing source code, giving people who use precompiled binaries more time to update before the vulnerabilities become easily discoverable?

(8) By John Rouillard (rouilj) on 2020-08-22 19:40:49 in reply to 7 [link] [source]

I would say wait a week from the announcement, so on the 27 unembargo.

I assume there is a CVE on this so people who get their info on security updates via that mechanism will be alerted and perform their updates.

I am interested in how you are embargoing the changes and tickets. I didn't know you could do that. Code wise, I assume a private branch could do that but how do you embargo tickets?

(10) By Stephan Beal (stephan) on 2020-08-22 19:49:55 in reply to 8 [link] [source]

There is no CVE, but Openwall hosts a public announcement list for this sort of thing which all of the distro maintainers supposedly subscribe to, and it was announced there:

https://www.openwall.com/lists/oss-security/2020/08/20/1

(9) By anonymous on 2020-08-22 19:41:33 in reply to 7 [link] [source]

I would argue it is easier for most scriptkiddies to diff two tarballs than to learn how to use Fossil. I mean, really, wget two tarballs, untar two tarballs, diff -Nru. It is that easy. I just did that and yeah, it is immediately obvious what was changed - it's not a long diff. Embargoing only creates a false sense of security, while people using trunk are unpatched. Given how trivial it is to diff, embargoing does more harm than good.

(11) By John Rouillard (rouilj) on 2020-08-22 20:26:04 in reply to 9 [link] [source]

Well they don't need to know how to use fossil, just click on two items on the timeline.

However if you have published the tarball with the required changes, then the cat's out of the bag. No need to embargo the changes as they have already been published.

(12) By sean (jungleboogie) on 2020-08-22 23:58:52 in reply to 7 [link] [source]

Good question. I think I like John's approach of waiting a week, but that's really just arbitrary date.

FWIW, James committed a change for OpenBSD. Looks like FreeBSD is running with 2.11.2.

I have no idea how to check other packages for the Linux OS's.

I am interested in how you are embargoing the changes and tickets. I didn't know you could do that. Code wise, I assume a private branch could do that but how do you embargo tickets?

Yes, once the embargo is lifted at your discretion, could you explain what the heck you did?

(13) By Stephan Beal (stephan) on 2020-08-23 00:50:03 in reply to 12 [link] [source]

I am interested in how you are embargoing the changes and tickets. I didn't know you could do that. Code wise, I assume a private branch could do that but how do you embargo tickets?

Yes, once the embargo is lifted at your discretion, could you explain what the heck you did?

As to the first half of the question...

An embargo is the easy part: keep in mind that each clone is a standalone copy of the original. If you change the project code on a clone you can even prohibit accidental syncing back to the original, while the --project-code flag to the the pull command allows the original to be pulled from if/when needed. So long as the copy doesn't commit directly to the same branch names being used by the parent, there will be no unintentional forks when/if the original is pulled back in.

There's also the closely-related concept of child projects, in which case the --from-parent flag to pull would be useful.

You're probably saying, "of course! It's so obvious now!" However...

As for the other way around (the "unembargo"), that's something i'm eagerly waiting to see. It won't simply be a pull --project-id ... is about all i know.

Hypothetically it could be done by using deconstruct on two repos, moving the "interesting" artifact from the clone to the original copy, and then using reconstruct to reassemble it, but that would be exceedingly tedious for more than a small handful of artifacts. A script could build a list of artifacts the clone has which the parent doesn't, which could then be filtered out by type to allow re-import of, say, only wiki changes or only commits or only tickets, but it's still somewhat tedious. (The bundle command could be used for commits, but not tickets, wiki pages, attachments, forum posts, ...)

We'll soon see what wizardry Richard invokes.

(14) By Warren Young (wyoung) on 2020-08-23 01:00:44 in reply to 13 [link] [source]

If you change the project code on a clone....

Wouldn't a private branch been simpler yet just as effective?

I dimly anticipate that playing games with the project code is the only way to keep some things private (e.g. wiki posts, for which there is no such thing as "private wiki") but assuming this embargoed change was all code, wasn't this a perfect use for this Fossil feature?

(15) By Stephan Beal (stephan) on 2020-08-23 01:13:48 in reply to 14 [link] [source]

Wouldn't a private branch been simpler yet just as effective?

Possibly, with the usability caveat that everyone involved would have to explicitly use the --private flag when syncing and --private applies to all private branches. Autosync does not support that flag, so private branches would not be honored for autosync purposes when using update or ci. That could, of course, be overcome by disabling autosync and explicitly passing --private to all pull and push invocations, but that would get old really quickly and would break down if one participant had their own unrelated private branches which they didn't intend to publish.

I dimly anticipate that playing games with the project code is the only way to keep some things private

So long as the repo is never pushed to the original and its URL is never published, it's "private" regardless of its project code. Changing the project code is only a "hardening" step, to prevent an accidental sync back to the original.

but assuming this embargoed change was all code, wasn't this a perfect use for this Fossil feature?

If the assumption were correct, then possibly so, aside from the usability annoyances of the --private flag in a multi-user setup.

(19) By Richard Hipp (drh) on 2020-08-23 01:36:02 in reply to 12 [link] [source]

Barak Pearlmutter tells me that 2.12.1 is uploaded to Debian. I haven't heard anything from any of the others. But based on the limited reports I've received, it seems that package maintainers follow Openwall closely and respond to vulnerability reports quickly. I'll probably release the development sources on Monday night or Tuesday morning.

(20) By anonymous on 2020-08-23 05:51:09 in reply to 12 [link] [source]

Looks like FreeBSD is running with 2.11.2.

FreeBSD is not running with 2.11.2, it has 2.11,2 (the comma stands for port epoch, so this is still 2.11). I'm a regular FreeBSD user and I am wondering why the port hasn't been updated yet :/

(21) By sean (jungleboogie) on 2020-08-23 05:59:58 in reply to 20 [link] [source]

That's right. I had forgotten about that. I'd suggest emailing the maintainer asking if they'd be willing to update the port. Additionally, request they use the tagged changes page. What I saw was pointing to an artifact (or something to that effect) of the changes.wiki page.

https://fossil-scm.org/fossil/doc/trunk/www/changes.wiki#v2_11 vs https://fossil-scm.org/home/doc/4df919803b6716ec/www/changes.wiki

If you're able, you can compile the released version and use that locally. Compiling isn't difficult.

(22) By anonymous on 2020-08-23 06:18:04 in reply to 21 [link] [source]

If you're able, you can compile the released version and use that locally.

Yes I already did that, I manually updated the port Makefile to 2.12.1 . I think I will send the maintainer an email asking for official update of the port.

(23) By Andy Bradford (andybradford) on 2020-08-23 15:28:24 in reply to 7 [link] [source]

> The question is, how long should that embargo last.

I believe the  answer to that question depends largely  on the risk that
it presents to individuals and teams using Fossil.

If  the  majority  of  Fossil  usage is  found  in  small  groups  where
individuals inherently trust one another, then that risk seems minimal.

But if Fossil  is being adopted more widely into  environments where the
individuals are less likely to be trusted, then the risk is greater.

It's hard to  answer this question---seems that only  those using Fossil
in their own environments can know.

Andy

(24) By Richard Hipp (drh) on 2020-08-23 17:13:01 in reply to 23 [link] [source]

If the majority of Fossil usage is found in small groups where individuals inherently trust one another, then that risk seems minimal.

That's how I use Fossil. But I don't know whether or not my usage is typical of others. I have no data on that.

(16) By sean (jungleboogie) on 2020-08-23 01:27:36 in reply to 1 [link] [source]

Just for posterity, are we sure Max is who reported the problem?

(2.12.1): Fix client-side vulnerabilities discovered by Max Justicz.

from the changelog

I think Chris is the one who first posted about it.

(17) By Stephan Beal (stephan) on 2020-08-23 01:32:07 in reply to 16 [link] [source]

Just for posterity, are we sure Max is who reported the problem?

That one (cross-repo localStorage sharing) was unrelated and turned out not to be a security issue at all, just an unsightly bug.

(18) By sean (jungleboogie) on 2020-08-23 01:33:09 in reply to 17 [link] [source]

AH! Sorry about that...got the issues mixed up. Thank you.

(25) By Roy Keene (rkeene) on 2020-08-25 16:36:33 in reply to 1 [link] [source]

ChiselApp.com has been upgraded to Fossil 2.12.1 !

(26) By ㎝ (_cm) on 2020-08-25 16:44:01 in reply to 25 [link] [source]

🎉 W00t!!!1 🎊