On Tue, Aug 20, 2013 at 08:43:36PM +0200, Stephan Beal wrote: > On Tue, Aug 20, 2013 at 8:39 PM, John Long <codeb...@inbox.lv> wrote: > > > If you're working on flagging PGP commits then it would be really nice to > > say PGP in red if the signature doesn't verify or green if it does or > > something like that. Otherwise saying "PGP" on a commit does more harm than > > good imho. Personally for hosted projects I'd like to see a feature that > > has an option to verify the signature on commits before committing them as > > a > > protection against unauthorized access to the repo (weak passwords, http > > instead of https etc.) > > > > Yeah, i left the word "signed" in the hopes that it didn't apply > "approved". Patches are of course welcomed for validation, provided they > don't require 3rd-party deps (extern deps mean the feature must be > optional, e.g. SSL).
I don't code in C, not even with a gun held to my head or I would be glad to try to help. fossil is a fantastic project. I believe there is a library put out by the gnupg project that is used specifically for stuff like email clients to interface to gpg (the open source version of PGP) that should have a very simple interface. I think it 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. If a commit is signed and can't be verified, it could be highlited in PGP yellow. Green verified, red doesn't verify. That would be amazing. > What should happen if a sign check fails? e.g. on a rebuild of a db (PGP is > seen at checkin or on rebuild)? I haven't used gpg/pgp with fossil but I use gpg a lot. Thinking out loud one workflow would be something like: get a commit ready and sign each piece of code/whatever push or commit fossil sees the signature field (easily detected by standard header): -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Stephen Beal! -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSE7rJAAoJEPh15eraZbwERKIIAMG6gup+QX0s5of4ovxqjuQA IME1rUexfBxVbi5CQGLuk/SvZYotPzbVPcWBsCVS9FW4kaP/19zP1Wpgm+SGU88/ +yOHrn7QBXNeti7lmyhFFCOoV4PqpNhlklTqASz1Ga9pm4ZhjJ1YYUfPXV0V2LDM 0VugnJCYq/QDLXZXI0z9F2/FULjgv7OfUN0dCsjwRwyzBip1tOoWIseG13en1uLm exm8RLUNbzjE7LcYV/jUwrOzCmnFjIqSb3l6CfhPuBeLonKzO0W+jVy/QHKxY2bE hS4dMu3vM6Op7cOfiB4bdT1jMWyIntyOBvZK0+18jRmfKRHJaSzNeSd5noZrCUI= =xA6W -----END PGP SIGNATURE----- verifies it and commits or fails it and doesn't commit. There are two kinds of signatures, clearsigned like above or detached (separate file). To process a clearsigned object you strip the headers. Otherwise you validate each file in the commit against filename.asc. That would make things a lot simpler because once the commit hits the repo it is a known-good commit. If it gets corrupted it's the same big problem as any corrupted commit. But this is on a single-file level. I do not know how you can sign commits that contain more than one file. > Should it then reject the whole db? i don't think we have a recovery > strategy if they fail. The best we could do is flag them in the timeline > as passed/failed/unchecked, i think. My understanding is you already compute checksums on commits. 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) 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. /jl _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
