You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Tyler <jo...@yahoo.com> on 2005/08/19 17:15:10 UTC
Watermarking checkouts
We have a desire/requirement:
- to be able to determine which checkout a particular
binary was built from
- that this occur without the knowledge of the user
who did the checkout
- that any changes required to make this occur be
server-side, not client-side
Clearly such a mechanism is going to be fragile; a
user who has worked out that such a mechanism is in
use is probably going to be able to find the change
and undo it (or at least mangle it to frustrate
correct identification). Its intended use is solely to
increase the odds of being able to catch out a user
who has disclosed confidential information (sourcecode
to unpublished software in this case), should this
occur.
I suspect that this request will cut against the grain
for many developers, open-source or otherwise, and
apologise for any offense that the it causes.
Nonetheless, the situation that we are in is what it
is, any assistance is appreciated.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Watermarking checkouts
Posted by William Nagel <bi...@stagelogic.com>.
On Aug 20, 2005, at 9:03 PM, Jamie Lawrence wrote:
> Honestly, I'd suggest replacing
> whomever is making your coding standards.
>
> Basically, if you don't trust your coders, you can't trust your code,
> and source-code disclosure is the least of your worries.
If only it were that simple. Unfortunately, greed can be a big
motivator and it's rarely easy to identify the people who are going
to sell you out just by talking with them (or in many cases even
working closely with them on a daily basis).
Personally, I probably wouldn't implement something like this just
because I think the difficulty of implementing something that works
correctly outweighs any potential benefit. On the other hand, I can
see how someone might look to perform this sort of watermarking,
especially if code theft has been a problem in the past.
-Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Watermarking checkouts
Posted by Jamie Lawrence <ja...@jal.org>.
On Sat, 20 Aug 2005, Matthew L Daniel wrote:
> > I don't believe that there are any hook scripts available to filter a
> > file's contents as it is being checked out though.
>
> I believe (with an Apache-hosted svn repo) a well-crafted mod_filter
> could accomplish this task. Whether the files would be marked as "dirty"
> in the WC would depend on the exact mechanism svn uses for determining
> such a detail. In my head, so long as the file svn uses for the "revert"
> command matches the "checked out" copy, it wouldn't be dirty.
>
> As far as the actual watermarking (in a non-intrusive way, and there's
> the rub), sequentially altering local variables to construct a "bible
> code" (sorry, I don't have the actual cryptographic glossary in front of
> me, but when you take the 2nd letter of word 1, the 4th letter of word
> 3, etc, and it spells out a message) is one idea. Conceptually, one
> would only need to replace 33 tokens to be able to represent a GUID in
> the code.
>
> I responded because I like the challenge of this question, but I feel
> it's a terrible idea to try and solve this problem using an SCM tool.
Look, this sort of watermarking is a hard problem. Whitespace
modification will obviously not fix it - you're presuming a compiler.
This probably does not intersect well with version control - after all,
the goal of VC is to establish how things difer from one another, and
record them. If you give everyone a different version, I'm sure you
could figure out some custom way to keep that straight, but that's
simply not how the software's built.
If this is a hard rule, I'd suggest a branch for each client,
pre-procesed to embed patterns in things like loops, or modify constants
here and there, or alter logic in some way. Of course, this kills VC
methodology, if you allow check ins. Honestly, I'd suggest replacing
whomever is making your coding standards.
Basically, if you don't trust your coders, you can't trust your code,
and source-code disclosure is the least of your worries.
-j
--
Jamie Lawrence jal@jal.org
I celebrated Thanksgiving in an old-fashioned way. I invited everyone in my
neighborhood to my house, we had an enormous feast, and then I killed them and
took their land.
- Jon Stewart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Watermarking checkouts
Posted by William Nagel <bi...@stagelogic.com>.
On Aug 19, 2005, at 11:08 PM, Matthew L Daniel wrote:
>> I don't believe that there are any hook scripts available to filter a
>> file's contents as it is being checked out though.
>>
>
> I believe (with an Apache-hosted svn repo) a well-crafted mod_filter
> could accomplish this task. Whether the files would be marked as
> "dirty"
> in the WC would depend on the exact mechanism svn uses for determining
> such a detail. In my head, so long as the file svn uses for the
> "revert"
> command matches the "checked out" copy, it wouldn't be dirty.
I'm pretty sure this will work as long as the user never performs a
diff of the modified file against a specific revision on the
repository. At that point the watermark will be clearly
highlighted. The only way I can see to get around this would be to
craft the mod_filter to also apply the watermark to the data sent by
diff, but that would require your mod_filter to have intimate
knowledge of the entire history of the file that it's watermarking.
Another (probably easier) solution would be to just make sure the
watermarked file is one that is unlikely to ever get diffed. For
instance, you might watermark a comment in some extremely stable
interface code that no one is allowed to touch (well I guess a
comment wouldn't work if you want the binary to be watermarked, but
you get the idea). Since it won't change over time, no one is likely
to have any interest in performing a comparison of that file. Of
course, you'll also have to make sure it's appropriately segregated
from the active development code to ensure that it's unlikely to get
caught in a diff of the whole directory.
>
> As far as the actual watermarking (in a non-intrusive way, and there's
> the rub), sequentially altering local variables to construct a "bible
> code" (sorry, I don't have the actual cryptographic glossary in
> front of
> me, but when you take the 2nd letter of word 1, the 4th letter of word
> 3, etc, and it spells out a message) is one idea. Conceptually, one
> would only need to replace 33 tokens to be able to represent a GUID in
> the code.
Since there is presumably a single point of generation for the
watermark you probably don't need anywhere near 33 tokens. Assuming
you use upper and lower-case letters in your substitutions (to ensure
that the result is still compilable), that's 52 possibilities for
each modified character. That gives you a little more than 7 million
possibilities with just 4 tokens, which is a sufficiently high number
to create a unique watermark for every coder/revision pairing in all
but the largest projects.
>
> I responded because I like the challenge of this question, but I feel
> it's a terrible idea to try and solve this problem using an SCM tool.
This is a terrible problem to have to solve using any tool, because
source code is such an inherently difficult item to watermark.
Watermarking works in things like images or sound files because
there's a lot of noise where unique data can be easily hidden.
Source code on the other hand contains almost zero noise, so the only
way to hide something is to put it where no one will look (since if
they do look they'll probably see it). That said, if you have to
solve the problem I don't know of any way to do it without involving
the SCM tool. Since the whole purpose of the SCM tool is to not
allow anonymous random changes to get into the code, you pretty much
have to let the SCM know at least something about random changes that
you do want to allow in. For instance, the watermark would be pretty
useless if its introduction were listed in the log for a given file.
-Bill
>
> -- /v\atthew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Watermarking checkouts
Posted by Matthew L Daniel <md...@scdi.com>.
> I don't believe that there are any hook scripts available to filter a
> file's contents as it is being checked out though.
I believe (with an Apache-hosted svn repo) a well-crafted mod_filter
could accomplish this task. Whether the files would be marked as "dirty"
in the WC would depend on the exact mechanism svn uses for determining
such a detail. In my head, so long as the file svn uses for the "revert"
command matches the "checked out" copy, it wouldn't be dirty.
As far as the actual watermarking (in a non-intrusive way, and there's
the rub), sequentially altering local variables to construct a "bible
code" (sorry, I don't have the actual cryptographic glossary in front of
me, but when you take the 2nd letter of word 1, the 4th letter of word
3, etc, and it spells out a message) is one idea. Conceptually, one
would only need to replace 33 tokens to be able to represent a GUID in
the code.
I responded because I like the challenge of this question, but I feel
it's a terrible idea to try and solve this problem using an SCM tool.
-- /v\atthew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Watermarking checkouts
Posted by Erik Anderson <er...@teamworkgroup.com>.
Actually, it sounds like this "watermarking" needs to be something less
visible to the user. If the user has 99% of the source code but needs
that last 1% to compile it, he can still release that 99% of the source
code.
It sounds like what is being requested is something like movie scripts do
sometimes. I know that some Star Trek scripts had one starbase change its
number in every script, so that if one was leaked they could go check the
starbase number in that particular copy of the script and figure out about
where it came from.
I don't believe that there are any hook scripts available to filter a
file's contents as it is being checked out though.
-----Original Message-----
From: Russ Lewis [mailto:webmaster@villagersonline.com]
Sent: Friday, August 19, 2005 10:24 AM
To: John Tyler; users@subversion.tigris.org
Subject: Re: Watermarking checkouts
Perhaps you release a copy of the code that won't build (or perhaps not
run) without a single, key component. Then you distribute that
component through a non-SVN mechanism. Perhaps a private/public key
pair, with the private key buried in a precompiled .o?
As you noted, this won't help you find the serious, dedicated,
knowledgable hacker, but it will discourage casual release and/or help
you track down accidental releases.
John Tyler wrote:
>We have a desire/requirement:
>
>- to be able to determine which checkout a particular
>binary was built from
>
>- that this occur without the knowledge of the user
>who did the checkout
>
>- that any changes required to make this occur be
>server-side, not client-side
>
>Clearly such a mechanism is going to be fragile; a
>user who has worked out that such a mechanism is in
>use is probably going to be able to find the change
>and undo it (or at least mangle it to frustrate
>correct identification). Its intended use is solely to
>increase the odds of being able to catch out a user
>who has disclosed confidential information (sourcecode
>to unpublished software in this case), should this
>occur.
>
>I suspect that this request will cut against the grain
>for many developers, open-source or otherwise, and
>apologise for any offense that the it causes.
>Nonetheless, the situation that we are in is what it
>is, any assistance is appreciated.
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Watermarking checkouts
Posted by Russ Lewis <we...@villagersonline.com>.
Perhaps you release a copy of the code that won't build (or perhaps not
run) without a single, key component. Then you distribute that
component through a non-SVN mechanism. Perhaps a private/public key
pair, with the private key buried in a precompiled .o?
As you noted, this won't help you find the serious, dedicated,
knowledgable hacker, but it will discourage casual release and/or help
you track down accidental releases.
John Tyler wrote:
>We have a desire/requirement:
>
>- to be able to determine which checkout a particular
>binary was built from
>
>- that this occur without the knowledge of the user
>who did the checkout
>
>- that any changes required to make this occur be
>server-side, not client-side
>
>Clearly such a mechanism is going to be fragile; a
>user who has worked out that such a mechanism is in
>use is probably going to be able to find the change
>and undo it (or at least mangle it to frustrate
>correct identification). Its intended use is solely to
>increase the odds of being able to catch out a user
>who has disclosed confidential information (sourcecode
>to unpublished software in this case), should this
>occur.
>
>I suspect that this request will cut against the grain
>for many developers, open-source or otherwise, and
>apologise for any offense that the it causes.
>Nonetheless, the situation that we are in is what it
>is, any assistance is appreciated.
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org