On Tue, Aug 20, 2013 at 09:28:00PM +0200, Stephan Beal wrote: > On Tue, Aug 20, 2013 at 9:03 PM, John Long <codeb...@inbox.lv> wrote:
> > My understanding is you already compute checksums on commits. > > > At a lot of places. "Blob content" is referenced by its content SHA1, so > any change there invalidates it. A commit contains two checksums: one is > the checksum of the content of the checkin manifest (basically: the formal > list of changes, but not the changes themselves, similar to a PGP > signature). The second one is a checksum of the names/sizes/content of each > file in the commit manifest (basically: each file that changed). Fossil > ignores/skips over/elides the PGP wrapper for purposes of checksums. > and > If that's > > true I would say if you verify any signed commit (and again it's not clear > > how multiple files are handled unless every file is signed individually) > > > > The signing happens at the commit level, and a commit contains N files. If I understood what you wrote, the checkin manifest is some kind of meta data about the commit and the "second one" above is *one* checksum on the list [a file of?] of names/sizes/content of each file in the commit manifest? Which also sounds sortof like metadata and data combined. >From a digital signature view I would say each user component of a checkin (each source file and everything I want to include in this commit) ought to be signed individually if only for the practical reason there isn't any meaningful alternative. If I got what you wrote then the signature you have today is on meta-data, which is derived from the commit components. That seems to be a suboptimal or even "wrong" way to employ digital signing because nobody is responsible for this, it's done in software, on some metaobject that I have no direct control over- as if the key owner is assigning perfect trust to fossil to do the right thing. That means fossil is authenticating the checkin, which is not useful or meaningful. Digital signing means "I certify that I wrote this." This thing itself, and not something derived from it. It might be clumsier for fossil, but it seems to me that if you choose to employ digital signatures on a project they ought to be required and verified individually on all components of a checkin. This will have to be a detached signature in the case of binaries. And if I can guess what you're thinking it's probably not worth it I might be inclined to agree. It is something that doesn't scale when a commit is at a higher level than one piece of source code. This is heavy-duty stuff to be used when you need to know with virtual certainty that person X updated a specific file. If you don't need to know that then this is overkill and a lot of work. If you do need to know it there isn't any other practical way to accomplish it. If all this is accurate then I don't understand how it works in practice today. Is fossil signing metadata? Who is signing it? > > then you should not have to do anything further, maybe not even note that > > it's PGP signed. The PGP signing is about authenticating that some user X > > is > > really the guy who did this update. Once that has been established it goes > > into the repo and nothing more has to happen. > > > > There's the problem for the current architecture: "when it goes in the > repo." Let's say for a second that one of the signed commits in Fossil's > repo is currently invalid. Now we add this feature. The next time fossil is > rebuilt, it would have to reject that commit, which would break the whole > rebuild, effectively leaving us with a repo we can't upgrade because PGP > decided we shouldn't. >From a practical standpoint it's exactly the same as a bad checksum. Whatever you do in that case is what you should do for a bad PGP signature. Saying "PGP decided we shouldn't" is the same as saying your SHA1 algorithm decided you shouldn't. This stuff is heavily used and if you're going to use it you have to rely on it. If you can't rely on it you shouldn't be using it in the first place. Any code can break. In practice, we don't see that gpg or PGP signatures have bugs any more than SHAx implementations do. > Fossil has no useful recovery strategy there other than to not let you > rebuild the db (==update its schema to a newer version, which also > rebuilds all derivable/calculable data contained in the repo). i think > "flag and accept" would be the best Fossil could sanely do. > > What i can envision is, assuming validation has hypothetically been added: > > a) show yellow/green/red in the timeline, and something similar in CLI > b) a 'pgp' command which takes a list of UUIDs to verify. > > But i don't think Fossil is capable of rejecting failures without seriously > endangering backwards compatibility in the case of an age-old signature > (==predating this feature) which is invalid. Maybe it could, or maybe it > could offer an option/flag to allow failed sigs or not. i'm not in any way, > shape, or form a cryptographer, i'm just thinking out loud here :/. I hear you. But accepting a bad signature is at least as bad as accepting a bad checksum. Both are situations that require a human to decide what to do next. Otherwise you are better off using neither checksums nor digital signatures. Just a thought, if fossil verifies signatures as part of accepting a commit, then once the commit is in the repo the signature has been verified, the signature could be discarded. If people trust fossil to do this (sounds like they're trusting it do to a lot more than that at the moment but I may have misunderstood) then at least then there is only the issue of verifying a signature once and not having to worry about not being able to verify it again some time in the future. I guess if I were implementing this from scratch I would consider one of the following high-level approaches. I'm not qualified to be talking about this stuff and these are just high level suggestions for the sake of discussion. But something like: Fossil takes responsibility for securing against unauthorized updates to the repo. This is sort of a userid/password + steroids approach to making sure the guy pushing or committing is really really authorized to do it. In that way it's like 3 factor authentication. And this is what I had ASSumed was already the way it was done in fossil, simply out of total ignorance when I heard "fossil has PGP support." * Associate a pgp public key with each fossil user id * All components of a commit have to be signed * Signatures on all components of a commit are verified or the commit is disallowed * Fossil notes and records for each commit component that the signature was verified successfully. Fossil does this once, upon commit * Signatures are themselves committed and carried as part of the commit process so they can be manually verified in the future, but the repo itself is in assumed-good status as long as normal checksums verify. If they don't, then it's a manual process to decide what happens next Or, you could take a passive approach as in I want to be able to personally verify that updates were done by such and such a person but using the repo day to day shouldn't demand the high level of authentication provided above. Fossil carries data that can be used for integrity verification, but is not responsible for ensuring integrity: * Fossil provides a bucket for each fossil user id to contain a public key as above * User is responsible to sign each component of a commit or not, and for those components that are signed, it is done by detached signature that is part of the commit. This second approach is kind of nifty because I can more or less do this myself, right now, without writing a line of code. 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. /jl _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
