Hi, Thomas: Thomas Deselaers wrote: > > Hello, > > 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...) -- SALUD, Jes�s *** [EMAIL PROTECTED] *** _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
