info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Only Crypted things in CVS-Repository


From: Jesus Manuel NAVARRO LOPEZ
Subject: Re: Only Crypted things in CVS-Repository
Date: Tue, 09 Oct 2001 18:25:34 +0200

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
***
address@hidden
***


reply via email to

[Prev in Thread] Current Thread [Next in Thread]