You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philippe Lavoie <ph...@cactus.ca> on 2003/12/10 17:40:45 UTC
Plans to add signing ?
I was re-reading an old article
(http://news.com.com/2100-7344-5117271.html?tag=nefd_hed)
And here is an interesting tidbit of information.
We expect to take measures in the aftermath of the Savannah incident,"
said Eben Moglen, general counsel for the Free Software Foundation,
which maintains the GNU Project, a source of freely available software
for Unix and Linux systems. Among the measures, the project leaders will
force developers to digitally sign any code they submit, and they plan
to introduce additional features to freely available source-code
maintenance systems--the best known being the Concurrent Versions
System, or CVS--to check developers' digital signatures before accepting
changes
Has Subversion taken steps to add some kind of digital signature to
commits? Is this necessary at all?
Sorry if this is out of topic (or was discussed to death, already. I'll
go to the archives then. )
Philippe Lavoie
Cactus Commerce eBusiness. All Business.
Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921
www.cactuscommerce.com philippe.lavoie@cactuscommerce.com
Re: Plans to add signing ?
Posted by Martin Furter <mf...@rola.ch>.
On Wed, 10 Dec 2003, Greg Hudson wrote:
> On Wed, 2003-12-10 at 12:40, Philippe Lavoie wrote:
> > Has Subversion taken steps to add some kind of digital signature to
> > commits? Is this necessary at all?
>
> I think you could check digital signatures with a pre-commit hook. (I'm
> assuming the signature would go into the log message, or into a file
> somewhere, such that you could use svnlook to extract it and verify it
> against the diff.) The trick would be getting the client and the server
> to agree on the precise format of a diff, and making sure that diff
> includes all relevant changes (including changes to binary files, if
> they're allowed).
I'm not an expert for all these things so my idea is prerhaps just crap
but...
I would create hashes of the whole files (not the diffs) store the signed
list of filenames and hashes as a revision property. This could be done by
the client. I think the server should check the signature and add it's own
so only one key is needed to check a whole tree. Ofcourse for a complete
check all keys would be needed so both signatures could be verified.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-12-10 at 12:40, Philippe Lavoie wrote:
> Has Subversion taken steps to add some kind of digital signature to
> commits? Is this necessary at all?
I think you could check digital signatures with a pre-commit hook. (I'm
assuming the signature would go into the log message, or into a file
somewhere, such that you could use svnlook to extract it and verify it
against the diff.) The trick would be getting the client and the server
to agree on the precise format of a diff, and making sure that diff
includes all relevant changes (including changes to binary files, if
they're allowed).
I believe OpenCM has much more sophisticated cryptographic protection of
commits (such that the server operator cannot forge commits as long as
the clients have the proper public keys for the other developers); I
don't think we have any plans to duplicate that functionality, as it
requires a lot of attention at the architectural layer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by John Pybus <jo...@zoology.oxford.ac.uk>.
Greg Hudson wrote:
> On Thu, 2003-12-11 at 13:12, solo turn wrote:
>
>>how does automerge prevent adding "signed directory content hashes" as a directory property?
>
>
> "Automerge" refers to the server-side merging of directory changes which
> we perform before upon commit. I'll illustrate how it conflicts with
> signing directory content.
>
> Repository is at rev 1000. You and I both have working dirs at rev
> 1000.
>
> I add file foo/bar. I sign the file foo/bar, the directory foo, and the
> root directory, and commit, producing rev 1001.
>
> Without first updating, you add file foo/baz. You sign the file
> foo/baz, the directory foo (which does not contain foo/bar), and the
> root directory, and commit, producing rev 1002. But no one has signed
> the contents of directory foo as it appears in rev 1002; what you signed
> was a version of the directory foo which never actually made revision
> status.
>
> If we didn't have automerge, then your attempt to commit would fail, and
> then you would update, generate correct signatures, and commit. But
> developers would find the system rather less convenient to use.
Even this case could be supported, though at the cost of slightly
greater alteration to subversion's workings. When the server at rev
1001 receives the signed foo/baz commit instead of failing it could
return the signed directory containing foo/bar. The client could check
this signature resign an updated directory listing and return it to the
server.
This would occur without the client actually performing an update of the
WC, i.e. it would change only the protocol not the user experience.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-11 at 13:12, solo turn wrote:
> how does automerge prevent adding "signed directory content hashes" as a directory property?
"Automerge" refers to the server-side merging of directory changes which
we perform before upon commit. I'll illustrate how it conflicts with
signing directory content.
Repository is at rev 1000. You and I both have working dirs at rev
1000.
I add file foo/bar. I sign the file foo/bar, the directory foo, and the
root directory, and commit, producing rev 1001.
Without first updating, you add file foo/baz. You sign the file
foo/baz, the directory foo (which does not contain foo/bar), and the
root directory, and commit, producing rev 1002. But no one has signed
the contents of directory foo as it appears in rev 1002; what you signed
was a version of the directory foo which never actually made revision
status.
If we didn't have automerge, then your attempt to commit would fail, and
then you would update, generate correct signatures, and commit. But
developers would find the system rather less convenient to use.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by solo turn <so...@yahoo.com>.
--- Greg Hudson <gh...@MIT.EDU> wrote:
> On Thu, 2003-12-11 at 11:18, John Pybus wrote:
> But, because we auto-merge directory operations, I think it would be
> impossible to sign directory operations (particularly deletions) in a
> way which is verifiable by other clients. In some cases you might be
> able to do damage by forging the deletion or movement of files, e.g.
> disabling security code which would otherwise be compiled in.
> So, it might be worthwhile to sign file contents, but for real
> protection against tampering we'd have to provide a way to disable the
> auto-merge feature so that you could sign whole directories before
> checkin.
how does automerge prevent adding "signed directory content hashes" as a directory property?
signed directory content hashes might be created using:
- directory properties
- hashes of all directory contents (just the top level, not recursive)
do you think signing of operations in an operations log would be necessary, or it is sufficient to
stick with "content signing", be it files, or directories?
__________________________________
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
Re: Plans to add signing ?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-12-11 at 11:18, John Pybus wrote:
> The client certs could be used to sign SHA1 hashes before submitting
> data. The server could validate the hash and signature then store it as
> a property.
Yes... if the contents of each file are signed with a property upon
checkin (something the server could verify in a pre-commit hook), then
clients could verify the contents of each file.
But, because we auto-merge directory operations, I think it would be
impossible to sign directory operations (particularly deletions) in a
way which is verifiable by other clients. In some cases you might be
able to do damage by forging the deletion or movement of files, e.g.
disabling security code which would otherwise be compiled in.
So, it might be worthwhile to sign file contents, but for real
protection against tampering we'd have to provide a way to disable the
auto-merge feature so that you could sign whole directories before
checkin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by John P N Pybus <jo...@zoology.oxford.ac.uk>.
Jani Averbach wrote:
> On 2003-12-11 16:18+0000, John Pybus wrote:
>
>>The client certs could be used to sign SHA1 hashes before submitting
>>data. The server could validate the hash and signature then store it as
>>a property.
>
> Yes, this will bring some extra security, but it will not seal a
> can complitely.
>
> Benjamin Pflugmann wrote:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=220488
This is true, it only protects file contents for known repos revisions.
It doesn't provide full protection for tree changes, nor for server
generated diffs (without recreating both end revisions to check their
hashes).
Still, I think it's strong enough to be useful. It's simple to
implement on top of subversion's model, and a project can achieve a
reasonable level of trust by creating a manifest file storing a list of
the files it comprises. This would allow a WC to be sure that the repos
hasn't had intended files removed.
A design that would protect tree arrangement/rearrangements and be
flexible enough to protect diff/merge operations against a compromised
server is probably difficult to get right, and very difficult to
retro-fit to subversion. I guess you have to hope that a compromised
server wouldn't remain unnoticed for too long :-)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2003-12-11 16:18+0000, John Pybus wrote:
>
> The client certs could be used to sign SHA1 hashes before submitting
> data. The server could validate the hash and signature then store it as
> a property.
>
Yes, this will bring some extra security, but it will not seal a
can complitely.
Benjamin Pflugmann wrote:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=220488
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by John Pybus <jo...@zoology.oxford.ac.uk>.
Greg Stein wrote:
>
> As Greg Hudson points out, if your access to the repository is restricted
> to (say) using just https, then you can also include the use of client
> certificates. That would be quite strong.
>
> But using a signature (client cert) while accessing the repository only
> verifies what comes in over that connection. If somebody hacks into the
> server and modifies the repository, the best you have there [in SVN] is a
> checksum. But that can easily be recomputed by the hacker. Subversion
> repositories are much harder to tweak than a CVS repository, but a
> determined hacker could compromise a repository in an invisible fashion.
<SNIP>
> I suspect that somebody could write a post-commit hook which applies an
> MD5 or SHA1 hash to each file (and/or set of properties) that gets changed
> in a commit, then send those off-system. If a system compromise ever
> occurs, then the hashes could be recomputed and compared to the off-system
> values. I think with some tricks, you might even be able to store them
> on-system in a safe fashion (e.g. such that you can add new hashes, but
> not change existing hashes). Easiest is to send off-site and hope *that*
> system doesn't get compromised too :-)
The client certs could be used to sign SHA1 hashes before submitting
data. The server could validate the hash and signature then store it as
a property.
If the server was later suspected of attack the admin could verify every
version, as long as they have a trustworthy collection of users public
certs (which could be recollected from/verified with the users if
necessary). Individual users could also verify their WCs by checking
signed hashes against the text-base, as long as they also have been
storing users public keys.
Users would have their client certs signed by the project admin as proof
of submit rights. This would allow other users to trust that their
collections of public keys are valid. As with all PKI this is
predicated on all private certs (user and server) remaining uncompromised.
This seems as if it would fit in just fine with svn's architecture, and
would make a worthy post-1.0 extension.
Yours,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Dec 10, 2003 at 12:40:45PM -0500, Philippe Lavoie wrote:
> I was re-reading an old article
> (http://news.com.com/2100-7344-5117271.html?tag=nefd_hed)
>
> And here is an interesting tidbit of information.
>
>
> We expect to take measures in the aftermath of the Savannah incident,"
> said Eben Moglen, general counsel for the Free Software Foundation,
> which maintains the GNU Project, a source of freely available software
> for Unix and Linux systems. Among the measures, the project leaders will
> force developers to digitally sign any code they submit, and they plan
> to introduce additional features to freely available source-code
> maintenance systems--the best known being the Concurrent Versions
> System, or CVS--to check developers' digital signatures before accepting
> changes
Note that it seems possible to read this as "digital signatures are
present while accessing the repository". I don't think it is necessarily
that a signature is stored as part of the metadata of a particular
changeset.
> Has Subversion taken steps to add some kind of digital signature to
> commits? Is this necessary at all?
As Greg Hudson points out, if your access to the repository is restricted
to (say) using just https, then you can also include the use of client
certificates. That would be quite strong.
But using a signature (client cert) while accessing the repository only
verifies what comes in over that connection. If somebody hacks into the
server and modifies the repository, the best you have there [in SVN] is a
checksum. But that can easily be recomputed by the hacker. Subversion
repositories are much harder to tweak than a CVS repository, but a
determined hacker could compromise a repository in an invisible fashion.
As mentioned before, OpenCM would be the system to use if there was a
concern about needing to provide non-repudiation of the contents of the
repository. It prevents hackers and sysadmins from tweaking the repository
in an undetectable fashion. Yes, they *can* do it, but not in a way that
still passes all the crypto validation in OpenCM.
I suspect that somebody could write a post-commit hook which applies an
MD5 or SHA1 hash to each file (and/or set of properties) that gets changed
in a commit, then send those off-system. If a system compromise ever
occurs, then the hashes could be recomputed and compared to the off-system
values. I think with some tricks, you might even be able to store them
on-system in a safe fashion (e.g. such that you can add new hashes, but
not change existing hashes). Easiest is to send off-site and hope *that*
system doesn't get compromised too :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2003-12-10 at 11:58, mark benedetto king wrote:
> On Wed, Dec 10, 2003 at 12:40:45PM -0500, Philippe Lavoie wrote:
> >
> > Has Subversion taken steps to add some kind of digital signature to
> > commits? Is this necessary at all?
> >
>
> svn doesn't have builtin signature support/verification. A wrapper
> that used revision-properties to sign the props and fulltexts would be
> pretty straightforward to implement. Of course, that wouldn't solve
> all the key management/distribution hassle.
>
> Things get more complicated if you want to sign just the changes (clients
> would either need to get things in changeset form, so that each signature
> could be verified, or a much more elaborate cryptosystem would need to be
> put together).
Take a look at 'opencm'. It's an SCM system whose primary design is
centered around cryptographic signatures.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Dec 10, 2003 at 12:40:45PM -0500, Philippe Lavoie wrote:
>
> Has Subversion taken steps to add some kind of digital signature to
> commits? Is this necessary at all?
>
svn doesn't have builtin signature support/verification. A wrapper
that used revision-properties to sign the props and fulltexts would be
pretty straightforward to implement. Of course, that wouldn't solve
all the key management/distribution hassle.
Things get more complicated if you want to sign just the changes (clients
would either need to get things in changeset form, so that each signature
could be verified, or a much more elaborate cryptosystem would need to be
put together).
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Plans to add signing ?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, December 10, 2003 12:40:45 -0500 Philippe Lavoie
<ph...@cactus.ca> wrote:
> I was re-reading an old article
> (http://news.com.com/2100-7344-5117271.html?tag=nefd_hed)
Uh, it came out yesterday. And, spot the SVN developer in that article. =)
> developers to digitally sign any code they submit, and they plan to
> introduce additional features to freely available source-code maintenance
> systems--the best known being the Concurrent Versions System, or CVS--to
> check developers' digital signatures before accepting changes
I think adding digital signatures to CVS is going to be ridiculously hard.
I don't see any easy way to do this. At least with Subversion, there's an
easy way to maintain metadata consistently. *shrug* -- justin
P.S. No, I hadn't heard Eben's comment before. Oh, well...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org