On Wed, Aug 21, 2013 at 1:58 PM, John Long <codeb...@inbox.lv> wrote:
> If I understood what you wrote, the checkin manifest is some kind of meta
> data about the commit
Correct. It tells us what blobs (stored separately) belong to the commit
and hold some metadata for it (comment text, user name,...)
> 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.
>
Exactly - the second ("R-card") checksum is a checksum of a _part of_ the
manifest _plus_ the data referenced by that part of the manifest. If any
byte gets corrupted anywhere, the whole thing fails on multiple levels.
> 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.
>
i can't speak to this, i can only say how fossil currently does it - it
signs the manifest (the list/metadata) but not the files. Because the
manifest holds the SHA1 hashes of all files in the commit, a change to any
of them is detectable, which (in theory) means that if the manifest is
signed and untampered, so are the files it refers to by SHA1 (a.k.a. UUID
in fossil terminology).
> 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.
>
i can't say - i only happen to know these code bits because i recently
ported them from fossil(1) to fossil(3). The exact significance (or not) of
them... i've left most of that thinking for later on (or others more
qualified in the topics, as you clear are regarding cryptography!).
> 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.
> binaries. And if I can guess what you're thinking it's probably not worth
> it
> I might be inclined to agree.
Almost - i was thinking, "there are probably people out there for whom this
would be worth it, but i can't personally name one" ;).
> If all this is accurate then I don't understand how it works in practice
> today. Is fossil signing metadata? Who is signing it?
>
Fossil can sign it at commit-time (it's an option) on the client side, but
in the main repo it is seldom (if ever) still used. i recently saw it used
on another repo, but AFAIK none of the fossil devs currently signs their
commits. If Fossil were a higher-profile platform that might need to
change, but so far we're a fairly small/manageable team and we haven't had
(thankfully!) any bad experiences which have forced us into more rigid
behaviours.
So basically fossil doesn't sign: it gives the client the option to sign
and then just carries that signature around in the metadata without placing
any meaning on it.
> > 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.
>
Exactly - a much more concise description than mine.
> 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.
>
Correct, but because the PGPs we have inserted to far have _never_ been
validated, it "might" happen that there are one or more which are not
valid. Fossil only does a very rough syntactic check on the envelope, so
it's completely possible to insert PGP signatures with hand-crafted junk in
them.
> 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.
>
Agreed, but fossil contains PGP sigs which were never verified, so we're in
kind of a philosophical pickle here.
> 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.
Interesting idea, and it wouldn't be too far leap for the current parser
code (i'm _assuming_ that pgp validation is relatively easy to do).
> 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)
lol
> 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.
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).
> 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."
>
"support" is a bit overstated - it was added way back when and not touched
since then.
> * Associate a pgp public key with each fossil user id
>
That only works if a user has a single key across all machine. Maybe that's
normal practice for PGP keys (i'm far more familiar with ssh, where that is
doable but uncommon).
> * All components of a commit have to be signed
>
...when the given user has a key on file.
> * 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
>
"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.
Those are all 3 the same routine, but it gets triggered at various times.
One of the pieces of metadata here would be the signature, and this
signature would have to go through the confirmation process on each of
these steps. The runtime for a rebuild could (but probably wouldn't) grow
significantly.
If we strip the PGP on the first arrival (the initial commit at the dev's
workstation) then we no longer have it for verification in the sync or
rebuild cases.
> * 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
>
If the builtin signatures don't match, fossil won't do much of anything
except complain and fail fatally. So far we've never seen such a case
(because sqlite as storage is unbelievably reliable).
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.
>
i suspect that's the only realistic option available to fossil, in terms of
backwards compatibility.
> 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.
>
i can't speculate how much effort that would involve and what the
side-effects might be.
> This second approach is kind of nifty because I can more or less do this
> myself, right now, without writing a line of code.
>
Almost, except that fossil doesn't carry around the keys and the detached
signatures.
> 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 ;).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
