design issue ? ? ?

[Peter]

Hi
Hi my company is developing a program like sourcesafe. I don't know
people will accept this design or not. Please let me know your idea?

After check-in the files. All the file will be encrypted, store in
harddisk. But the filename is not encrypted. So use can still see it
direcotry structure by using a "window explorer".

thanks
from Peter ([email protected])

 

[Chris Smith]

Hi my company is developing a program like sourcesafe. I don't know
people will accept this design or not. Please let me know your idea?

After check-in the files. All the file will be encrypted, store in
harddisk. But the filename is not encrypted. So use can still see it
direcotry structure by using a "window explorer".

Is such encryption an important part of your product's feature set? Who
are your target customers? What are their goals in encrypting their
source code? Without that, no one could begin to answer your question.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrew Thompson]

| Hi
| Hi my company is developing a program like sourcesafe. I
don't know
| people will accept this design or not. Please let me know your
idea?
|
| After check-in the files. All the file will be encrypted, store
in
| harddisk. But the filename is not encrypted. So use can still
see it
| direcotry structure by using a "window explorer".

If you are doing this for source code, I
cannot see the point of it. It'd be easier
for the users to decompile/reverse engineer
the classes themselves..

Why bother attacking the encrypted source?

Is your source that bad?

 

[Derek Clarkson]

Hello Peter,
My interpretation of you note is that you are encrypting the code you are
storing. I would suggest that this is not a good idea.

Firstly, source control systems are generally used within a enclosed
environment, so there are not issues of people seeing it who should not
have access.

Secondly, encrypting it can make it impossible to access you you have a
major system failure. Basically a client using your software will tend to
be rather peeved if they have a failure which they cannot recover from and
then find that the last year or mores work, is is in-accessable because it
is encrypted.

Thirdly, if the source is not stored in encrypted form, it means that the
client has access to it to easily perform tasks on it that you may not have
envisaged. This is important because as good as your software may be, you
cannot predict everything that a client may wish to do.

If you are sure about this, then I would suggest you read material on linux
programs, the how and why of the designs and techniques used to develope
them. ESR's latest books has a lot of discussion in this area.

 

[nos]

Hi
Hi my company is developing a program like sourcesafe. I don't know
people will accept this design or not. Please let me know your idea?

After check-in the files. All the file will be encrypted, store in
harddisk. But the filename is not encrypted. So use can still see it
direcotry structure by using a "window explorer".

thanks
from Peter ([email protected])

Who are you protecting? Don't you trust your fellow
employees? Put it on a floppy and stick it in your pocket then.

 

[Andrew Thompson]

....
| Who are you protecting? Don't you trust your fellow
| employees? Put it on a floppy and stick it in your pocket then.

_Then_ put yourself, your pocket, the disk,
and anyone who has ever seen the program,
(or has acces to the executable) into a triple
lock safe and drop it into the Marianas Trench.

That is still not completely secure,
but it's gettting close. ;-)

 

[Peter]

Hello Peter,
My interpretation of you note is that you are encrypting the code you are
storing. I would suggest that this is not a good idea.

Firstly, source control systems are generally used within a enclosed
environment, so there are not issues of people seeing it who should not
have access.

Secondly, encrypting it can make it impossible to access you you have a
major system failure. Basically a client using your software will tend to
be rather peeved if they have a failure which they cannot recover from and
then find that the last year or mores work, is is in-accessable because it
is encrypted.

Thirdly, if the source is not stored in encrypted form, it means that the
client has access to it to easily perform tasks on it that you may not have
envisaged. This is important because as good as your software may be, you
cannot predict everything that a client may wish to do.

If you are sure about this, then I would suggest you read material on linux
programs, the how and why of the designs and techniques used to develope
them. ESR's latest books has a lot of discussion in this area.

Thanks for you great advise.
Linux cvs doesn't encrypt the source code too. But as a commerical
product. Will people mind it?
If it sell only $20 USD, how many % of programmer in world would
buy this product you think?

thanks again
from Peter ([email protected])

 

[steve]

Thanks for you great advise.
Linux cvs doesn't encrypt the source code too. But as a commerical
product. Will people mind it?
If it sell only $20 USD, how many % of programmer in world would
buy this product you think?

thanks again
from Peter ([email protected])

I don't see this as a useful product.

what you are basically saying is that they can access the csv system, and
down load the source( they must be able to see un-encrypted source, to
program), but they cannot directly access the system to read off the source.
sounds like you just need to secure the server, and get log-on control.

steve