[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] one more feature needed for signing
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] one more feature needed for signing |
Date: |
Sat, 13 Dec 2003 13:41:32 -0800 (PST) |
[Rob: hold on before moving your changes down to pfs.c level --
it may be better to keep them in archive-pfs.c:]
> From: Andrew Suffield <address@hidden>
> On Sat, Dec 13, 2003 at 08:33:41AM -0800, Tom Lord wrote:
>> All files in the archive should be signed including =meta-info files,
>> CONTINUATION files,
>> .listing files,
> No point signing those. They have only one correct value and are
> trivial to verify directly; furthermore, they're acutely vulnerable to
> replay attacks, so signing it accomplishes nothing.
That's true but:
a) there's no good reason to _not_ sign them _if_ they are generated
client-side _and_ the signing mechanism is low enough in pfs that
it isn't distinguishing .listing from any other kind of file.
However:
b) we've actually missed something:
I was going to leave it up to users to write their own scripts to
crawl over an archive and validate signatures. Actually -- that
script needs a little bit more help from arch and the signing
mechanism needs just a bit more to it.
As proposed and built so far (modulo the need to sign a few files
that aren't being signed yet) we can:
1) detect un- or improperly-signed files in the archive
2) detect changes to or removals of previously checked parts
of the archive
what we can't do is:
3) detect illegitimate new adds of revisions or archive-cached
revisions constructed by copying files from legitimate
revisions
For example, here's an exploit:
a) project commits patch-X which, due to a bug, creates a
security risk in the project.
b) project commits patch-Y which reverts patch-X
c) attacker creates patch-Z which is a copy of patch-X
it's easy to detect that patch-Z is bogus -- but not by looking
at the existing .sig files alone.
A simple fix is:
i) when creating a revision directory, create and store
an additional file containing the lines:
<fully-qualified revision name>
<hash of CONTINUATION, if present>
<hash of changeset, if present>
<hash of full-text, if present>
<hash of log>
and sign that.
ii) when creating an archive-cached revision, create
and store an additional file containing the lines:
<fully-qualified revision name>
<hash of archive-cached tar bundle>
and sign that.
iii) supplement the signature checker with a tool that
verifies the contents of those files: both that
the hashes are correct and that the fully-qualified
revision name is the right one.
-t