Sorry for the delay. I've been swamped with work. On Wed, Aug 21, 2013 at 02:30:10PM +0200, Stephan Beal wrote: > On Wed, Aug 21, 2013 at 1:58 PM, John Long <[email protected]> wrote:
> > 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 > > happen. 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 > flaw in the "check sig and forget" approach): > > a manifest (checkin record) is read/processed at three different points: > > 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. Then I wrote: > > 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 > > my > > updates and check in updates and their detached signatures. Now I can > > verify > > 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. /jl _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
