i always assumed adding "signing" is basically a non-issue as
subversions design allows to just add it with little effort?
as i understand a signature, it is a thing that proves that the
content is ok (and not the delivery of the content):
- you have a file f and properties p
- you own a secret (private) key sk
and publish the corresponding public key pk
- generate a hash h from f,p
- use your sk to sign h and get
signed hash sh
- transmit f and sh to server
(authentication is an independent issue
as this is delivery)
- on checkout, update you get a revision of
f with the corresponding sh.
if i'm not wrong this allows:
- signing of single files
- therefor mixed revision working copies
- prevents serverside tampering
- verifying the signature at any time,
given that you somehow are able to
access the (committers) public key.
the main challenges for subversion would then be:
- storing the signed hashes,
as you cannot compute them
- add commands to handle these hashes
on client side (i.e. create, check).
not relevant to subversion project would be:
- key management:
this is a more general thing, i.e. choosing a network
of trust (i.e. who signs your keys), and any "authority"
using svn can adress it (like savannah).
- signing diffs, change sets, ..:
can be computed.
- authentication (like opencm):
automatigically via ssh, or apache ssl certs,
and not relevant to signatures.
therefor you often do not use the same certificate
for authentication, and signing.
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 17:19:57 2003