Re: Only Crypted things in CVS-Repository

[Paul Sander]

Of course, an alternative would be not to encrypt individual deltas but
rather the entire RCS file.  The user would then be required to somehow
supply the key to whatever low-level software performs that function before
having any kind of meaningful access to the data.

It's not difficult to build this kind of capability into RCS; I've modified
RCS to keep its files compressed, which was about three days' effort
programming and testing after the compress program was munged into
something that looks like the stdio library.  (That work remains available
for the old RCS 5.6 at http://www.wakawaka.com/source.html)  Adding the
necessary changes to CVS, especially in server mode, is an additional
challenge.

>--- Forwarded mail from address@hidden

>Thomas Deselaers wrote:

>> I am new to this list, but I have checked the archives and as far as I could
>> see, until now there was nothing similar to my idea discussed.
>> 
>> The situation I have is the following.
>> 
>> Together with some friends of mine I am developing to win a small contest at
>> our university. We are 4 persons and thus we decided to use CVS to manage
>> our sources. For the Repository we used the server of a friend of us who
>> said he would not be taking part in this contest. But now he is taking part
>> an he obviously stole code from our CVS-Repository.
>> 
>> This brought us to the idea if it is possible to store crypted sources in a
>> CVS-Repository without losing the funktionality of diffs etc. Of course it
>> would be absolutely easy to encrypt everything and store them binary.

>This is a no-no from the very beginning.  CVS is mostly about managing
>*text* files.  They're text files because they're constrained to a short
>set of bytes (those for ASCII chars) and because some regularities are
>within (end-line markers separate meaningful textlines).  You want to
>encrypt those which in other words means you want to convert them in an
>special case of high entropy binary files (in any other case your
>"encryption" wouldn't deserve that name).  Well, as anybody would
>accept, and people as Greg A. Woods would even print on you on fire (
>;^P ) if binary files are the rule, not the exception and you are not
>interested *mainly* on the ability to concurrently work on files, then
>CVS is not your tool.

>> I thought about this, and came to the conclusion that this would be possible
>> by only changing the client.
>> 
>> If the source is encrypted line by line, diff will still work and decryption
>> may find place at the client.
>> 

>KISS.
>This remembers me the issue about ACLs within CVS.  It is either a
>matter for CVS or it is not: the only part of it CVS is related to (not
>trying to argue if it *is* useful or not) is about its semantic objects:
>file *revisions*, branches and tags.  Once you are asking for CVS to do
>things on objects not within its direct interest, like files as a whole,
>or directories, then you should go elsewhere (filesystem ACLs ie).

>The same goes about encryption: Are you trying to hide this or that
>revision/branch from this or that user of the repo? Then it *migth* be a
>job for CVS.  But this is not the case here.  You want to hide
>files/file contents on a file system on a box, and you want hide
>files/file contents on transit over a network.  For the later you have
>pretty good solutions, like SSH tunnels or any kind of VPN, for the
>former you *can* have partial solutions on encrypted filesystems, or
>total solutions (just to say, they are probed to be hidden even for a
>malicious power users/administrators for that system) over highly ranked
>secured systems.


>> Does anybody think a solution to this problem would be interesting to other
>> people than to us? If yes, I might try to develop something like this.
>> 

>Don't think so, because it is either not a matter of interest, since
>there are already workable solutions, or they are not a matter of
>interest because that kind of secrecy is not an issue.

>Your case is kindof special one: you use a server controlled by a guy
>you're not confident on.  As I said it is possible although a nigthmare
>to build a B or A class system where nobody is confiable by himself, so
>either he cannot do things or at least cannot do without per-procedure
>audit to go elsewhere.  You have impacted your nose against a wall
>pointed out by B security-class orange book specs: cross-boundaries
>discrectional access.  Though it is usually thougth as regarding spatial
>boundaries (like you can't take these papers or any copy of them out
>*this* very office) it has temporal aspects too: your system (not being
>B classifiable) didn't took this kind of temporal crossboundary into
>consideration and you payed the bill.  "Sensible" material time-crossed
>a security boundary: that from having a server system with a confiable
>sysadmin to having your server under non-confiable hands, and data
>disclosure is the effect of this security breach (what if instead of
>your "friend" cheating you simply the box went out his control because
>somebody else decided to give it a new sysadmin, for instance?).
>To take the example on a more general environment, you could tell us
>your approach migth probe usefull, for instance so you can keep your
>project on freshmeat/sourceforge and still protect the code from
>undesirable eyes, but if you really thing so, you are misunderstanding
>the problem: you can build a secured (to a given standard) system if
>time, knowledge, hands and money are properly provided, but you can't
>and won't manage to have a rated secure system (albeit a low-rated one)
>if the "platform" specs are not at least to that trust level *in
>advance*.  Even if you can manage to client-side encrypt data and still
>have an usable system (remember most CVS work is server-side), still
>your own box can be compromised (hey, my own box is suppoused not to be
>compromisable.  Well then, that's *your* environment, others will
>vary).  On the other hand as long as some "security" process is at
>server side, it will be easily compromisable by server's sysadmin (on
>your case, by reading the files within the repo, in other, reading it
>from memory prior to its encryption, or trojanizing server apps, or...)

>--- End of forwarded message from address@hidden