Sorry for the delay. I've been swamped with work.
Digital signing means "I certify that I wrote this." This thing itself, and
not something derived from it.
Being one of those who doesn't place all that much worth on digital
security (that's going to bite me one day), i would almost suggest that the
different is splitting hairs in this case because the SHA1s of the files we
are "indirectly" signing are just as valid as any PGP signature we might
wrap around them. We then sign the SHA1s, in effect, as opposed to the
content. Obviously, SHA1 "can" be attacked, but i have yet to see it
Couple things to mention here. One, SHA1 has been broken since 2005. It's
not longer recommended for deployment in new cryptosystems. Since 2010 a
practical attack was demonstrated.
If you give fossil a PGP key and a keyphrase to enable signing then I don't
disagree with your observation that the difference between SHA1 and PGP
signing could be viewed as hair splitting. But that is because giving fossil
a PGP key and keyphrase is an abuse of what it means to digitally sign
something as we talked about earlier. A hash is a way to assign a token to
some data. In theory, if the data is altered the hash will change. This
guarantees (again in theory) integrity of the data. It doesn't have
anything to do with *who is asserting* the data is valid. There are two
"value added" things digital signing provides over hashing in this specific
example when fossil uses SHA1. One, a person is taking responsibility for a
commit and saying "I did this". Two, PGP can use much stronger hashes than
SHA1. What problem are we trying to solve? If we're worried about detecting
inadvertant data corruption, then SHA1 is very likely good enough. If we're
worried about malicious data corruption then SHA1 is not good enough on
paper. If we want to know with virtual certainty "who did this?" then a PGP
signature helps. If fossil signs everything with one key, then yes, it
doesn't add much value beyond a hash because we know fossil did the actual
update even though a person supplied the data to be committed.
That is only really enforeable for network access. Once someone has local
access they have full access to the repo. Local access to a fossil repo
always uses ignores any credentials checks because it assumes that 1 copy
of a repo belongs to 1 user (which is the normal/expected workflow).
This is another "value added" item for PGP signing over a hash since the
data could be completely replaced and rehashed (in theory, I don't know
fossil) and the corruption couldn't be detected. This would be detected with
digital signing because the attacker can't re-sign bad data. BTW, if I
understood correctly and fossil does sign with somebody else's key, then
this is a significant weakness in this attack (local access to repo) also
since the attacker gains access to the private key which was in the repo.
* Fossil notes and records for each commit component that the signature was
verified successfully. Fossil does this once, upon commit
"once" is kind of a misnomer here (and i just accidentally discovered a
a) when the checkin happens.
b) when the manifest arrives via a sync
c) when doing a rebuild - that effectively feeds all of the existing
manifests back through the db to rebuild metadata.
If the rebuild can change previously signed contents then yes, it's seem
problematical. In that case a signature isn't meaningful any more.
When I check in a project one of the things I check in is my PGP public
key and a detached signature of my PGP public key. Then I detach-sign all
updates and check in updates and their detached signatures. Now I can
any time in the future that any file in the repo was signed by me. I don't
even need fossil to give me a place to store my pubkey because I simply
check it in. This won't protect me against someone hacking my repo if he
obtains my userid and password but I will be able to know if that happened.
Sounds like way overkill to me, but i've been told that i am (by far) not
as paranoid as i should be ;).
But unless I missed something then it's a very simple way for people who
want digitally-signed commits to use fossil, without any changes at all, to
get the full benefit of signed commits, all using fossil's current
capabilities to manage data of all kinds, not just program source.
The only thing I might add is a cross-signature on the pubkey I check in.