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
Received on Fri Aug 19 19:29:51 2005