Hi, Branko Čibej wrote: > On 08.06.2015 04:19, Ruchir Arya wrote: > > Hello everybody, > > > > I am new to SVN development. I have a question. Why is there no > > implementation of changeset signing in subversion? Suppose if the > > root/admin (who maintains repository) is not trustworthy, > > If your server administrator is not trustworthy, then no amount of > signing is going to help. Anyone with direct access to the repository > storage (which a server admin will have) can modify revision contents > even if they're signed; no cryptographic signature is proof against attack.
Actually, this is *exactly* what a cryptographic signature is. Assuming Ruchir is not free from the influcences of other three letter tools implementing commit signatures, it is very likely that he is referring to committer supplied signatures which, will fail to validate upon subsequent manipulation of the repository history relevant to the signature. This is a separate problem from internal repository consistency checks. To answer the initial question: This was not implemented because it is not an inherent problem of centralized version control systems, where the server is assumed to be under the control of a trusted as well as competent party. The trust anchor is the repository giving out access, rather than distributed repositories exchanging/distributing/propagating change. Rather the artefacts are expected to be signed in real-life applications. Assuming a suitable function to map commits into signable data can be defined, changeset signing could be implemented with storage in revision properties. This would not even need to be part of the core functionality. Andreas
