Fossil Chat

> How is the security with Fossil? I'm always leery of hosting (niche) web facing services written in C.

Fossil's been available for nearly 14 years now and we've had to make only a single security-relevant release in that time (in late Summer 2020).

Fossil's primary architect, Richard Hipp (edit: HN user "SQLite"), is no stranger to code hardening and continues to add security-related APIs to all levels of the code, from how we internally build SQL queries or encode URL arguments to the recent (late 2020) ability for the db to lock down regions of the db until/unless that protection is toggled off for the brief blocks of code which need to modify those regions, ensuring that other areas of the code cannot modify parts of the database which they aren't directly responsible for. Security against malicious inputs has never been treated as an afterthought in fossil.

I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.

The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A transaction is created by the "commit" command. Git and Fossil make no record of the stuff that happens in between two commits. They only record what is in each commit. So you can backspace and edit and change all you want to before typing "commit". But once you type "commit", all that you've done since the previous commit becomes part of the permanent record. Rebase violates that constraint. It changes the permanent record. Rebase makes the repository say that the sequence of commits is different from the order in which they actually happened.

You can call that whatever you like. "Telling a compelling story." "Generating a clean history." I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.

It is useful to have a simplified overview of project history, to aid the reader's comprehension. There is no sin in this as long as you are truthful to state that the simplified history is in fact a simplification that skips or revises some of the messy details of reality. The alternatives to rebase that Fossil provides do exactly that - they suppress the unimportant details of the history to provide a simplified and more readable history. The difference is that the original, truthful history is still provided, for auditing and for those who care. In other words, the repository reports both "what we should have done" and/or "the best way to think about what we did" in addition to "what actually happened".

I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative. But I think that a source code repository should be a true history of a project. If you view a source repository as a true history, as I do, then rebase is a tool for lying about the history.

My philosophy is that the true transaction event and accurate immutable history of the project is the artifact built for release (in our process, the merge to master drives this and therefore commits to it map to the transaction event). The stumbles and trips along the way are irrelevant keystrokes that get backspaced / rebased out.

>Then the core members don't need to have a dedicated channel somewhere else.

But isn't that "a replacement"?

I use Fossil for my own projects. However, I do not use the forum feature, chat feature, etc. They don't belong there in my opinion, nor do I like the implementation much; I use external software.

There are a few other things I dislike about the design of Fossil; it doesn't have very good low level access, for one thing (there are other concerns too, although rebase isn't one of them). I have started to make my own implementation, which I intend to support the Fossil protocol and deconstruction format. Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, while I consider it important (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it). As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.