I wonder what is the reason why clearsign was enabled by default, and then disabled by default.

I see several possibilities but I am not clear about the real reason.

1. Fossil is designed to be self-contained, so by default we don't want a dependency on another binary (PGP)

2. PGP is no more used to sign commit of Fossil or SQLite

3. PGP signing commits is basically useless (but why?)

4. There are better alternatives (store digital signature somewhere else?)

5. Signing was a wrong good idea (but why?)

Finally, is PGP signing still a good practice or not?

PGP signing could be useful in a scenario where a business or agency needed to be able to prove who was responsible for each commit. But for such proof to be possible, it would be necessary to have an exact specification for how Fossil uses PGP and how it stores the signatures so that a 3rd party could independently verify the signatures - outside whatever verification Fossil might provide.

The file format is defined here: https://fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki

Artifacts are PGP clearsigned. Here is an example:

https://fossil-scm.org/fossil/artifact/10fb90fcae08a311

Compare the example against an unsigned check-in:

https://fossil-scm.org/fossil/artifact/cb13b611005b9f0a

Does PGP support require Manifests to be turned on?

No - fossil always generates a manifest, that option simply says (IIRC) that fossil should save a copy of the manifest to the checkout directory.

When that option is turned on, does the copy of the manifest in the check out include the PGP header and suffix (assuming the commit was signed) ?

Yes.

You can verify this by grabbing a copy of check-in [10fb90fcae08a311] and looking at the manifest file.

Thanks.

So, to manually verify a PGP/GPG signature, I can either enable the manifest option to have the manifest in the checkout or I can retrieve the signed manifest with

fossil artifact COMMIT-HASH

Then use pgp/gpg to verify that document has a valid signature.

If this could be put in a document (other than the file formats document), that would be helpful to those who decide to use this feature.

I have no idea about the development of Fossil, but perhaps it would be an idea to wait with changes on the PGP behavior until the Thunderbird team is done with its PGP changes and get inspiration from them?

Or an idea how not to do it, depending on the outcome.

Is there any documentation on fossil's PGP support? I couldn't find anything. Does it need to be built with some kind of flag to enable it?

Somewhat related, I use S/MIME to sign instead of PGP since it is more widely supported for other types of signing of messages.

How do you sign your commits -- is this done with an external tool? And is it possible to sign any artifact, such as forum posts?

fossil setting --global clearsign on to set up signing for all commits. It uses your installed GPG and can be configured with the pgp-command setting. AFAIK signing is for commits only. It affects the manifest (see example).

I took a quick look at the code and it also seems to be used in the branch_new function, so i guess branches can also be signed. But i wonder if the lack of signing in other areas is just due to lack of demand for the feature.

The reason i bring it up is because i'm curious about using fossil in a p2p system where there is no authoritative server. Without signing every artifact, it would be pretty chaotic since people with commit privileges can spoof any name they want.

Name spoofing is only as much of a problem as it is in Git, if I understand Git's signing model properly. Perhaps I'm missing the point and you're looking for something with stronger guarantees. Fossil does keep a log of where artifacts came from, which gives you a little bit more information, but ultimately it seems that any content-addressing system is going to struggle with verifying authorship in similar ways.

Right, i didn't mean that as a comparison to git -- it would have the same problem. What i'm thinking about doesn't exist yet :D I want a system where fossil push doesn't just go to one server, but to a p2p network where any node "subscribed" to my repo would receive it. I'd also like to allow some people to push to my repo through the same network (commits, forum comments, etc).

That's obviously way outside the purview of fossil's current design but it's fun to think about. That's why i ended up down this rabbit hole; if there is no authoritative server, the list of people with push access would need to include public keys, and every artifact that is pushed would need to be signed. At least, that's my current thought...

There was a long discussion about this several years ago and it indeed boiled down to the problem of verification. It seems that there's no feasible way for fossil to actually make any guarantees based on a signature, so it does not, e.g., bother showing in the timeline that a commit is signed.

This is one advantage of S/MIME, Fossil already links to OpenSSL for TLS and could thus match the certificate of the commit to the commiter if some mapping scheme were used (such as using email addresses as Fossil usernames)