On Tue, Aug 20, 2013 at 9:03 PM, John Long <[email protected]> wrote:
> is called gpgme (gpg made easy) IIRC. I think it's not something you have > to > link and you should be able to tell if it's present or not. > i can't personally commit to it, but maybe someone who's listening can. > 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. Fossil only does PGP plaintext signing, btw, unless i'm sorely mistaken. 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. > 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. 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 :/. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
