On Thu 2003-01-16 at 07:51:16 +0200, Jani Averbach wrote:
> On Thu, 16 Jan 2003, Benjamin Pflugmann wrote:
>
> > On Wed 2003-01-15 at 04:17:10 +0200, Jani Averbach wrote:
> > >
> > > With this arrangement authenticity of repository will be known at any
> > > given moment. And every checkout will be checked against those keys. (This
> > > is of course optional.)
> >
> > Sorry, if I am ignorant, but for the client to verify the check-ins,
> > the client would have to retrieve all changes seperately, which is not
> > the case for subversion.
>
> Here is how I think it would work:
>
> rev #1
>
> You create new file, and commit it with signature. This signature
> have to be done in some canonize format (LF ending, and so on) of file, I
> have wild gues, that repo's internal format is just fine.
>
> checkout of rev #1
>
> You just check out the file and verify it's signature.
>
> rev #2
>
> You have a local mod to file, and you commit it. The signature will be
> generated against "the result what will be the content of repo's versio",
> and it will be stored to repository.
>
> checkout #2
>
> You check out diff, and signature of what the text base will look like
> after patching.
[...]
> Yes but I am interested only about the result. And the server stores
> signature for every current full text what it has. So server has allways
> signature for every past fulltexts what it has had, and delta diff to
> construct those full texts. So authority of every past text base should be
> validateable. Or am I missing something?
Ok. It is not as bad as I thought initially, but still bad.
I presume your target is to ensure content authenticity without having
to trust the repository server itself, i.e. making a troyan horse
introduced on the server side obvious (because ensuring only integrity
of commits can simply accomplished by existing means: user
authentication and MD5 sums).
But if you want only save signatures for created revisions, the server
can inject malicious code into any operation which does not result in
an existing revision, i.e. merge, output of diff, server-side copy and
whatever does not come to my mind.
Of course, one could work around that by letting the client construct
the derived data itself, but that could result in a lot of overhead.
For
svn diff -r500:510
it would have to retrieve one of the revisions, check the sig, apply
the diff and check the sig (originally I thought you would have to
retrieve all delta, which is wrong of course). Depending on the data,
that is orders of magnitude more traffic. The same goes for merge.
Additionally, any operation on the repository itself (like creating a
branch copy), which transfers no content currently, would need to
retrieve the tree to copy in order to verify the sig.
Whereas if not the result, but only the changeset is signed, you'd
only get a file listing for the tree (if at all), create a changeset
for the copy and sign this. That is why I said, this would work better
with changeset-oriented software.
[...]
> Well, I read those OpenCM papers, and I am a little bit confused if this
> add any value against client certificate + SSL connection.
Well, yes. It is changeset based and doesn't sign them but uses a
cryptographic hash instead, which is unique for the content, so the
content cannot be forged either. The advantage is that the hash is
much smaller than a sig, AFAIK. And it does need any special setup for
this. (The setup is for authentication, not for creating the hashes).
I am not sure, but it looks like injecting a trajon via a new
changeset would work (as the most current revision), if you get access
to the server.
> At least one would be that client could validate integrity of wc
> without encrypted connection to the server.
You lost me. That would be possible with signed revision, either,
wouldn't it?
Benjamin.
- application/pgp-signature attachment: stored
Received on Thu Jan 16 08:37:03 2003