shipping python

[Kristen J. Webb]

On 10/12/11 3:26 PM, Chris Angelico wrote:
> On Thu, Oct 13, 2011 at 8:10 AM, Kristen J. Webb<kwebb at teradactyl.com>  wrote:
>> My main motivation to use .pyc is to keep end users from changing scripts,
>> breaking things, and then calling us.  Tamper proofing may be an
>> alternative approach if anyone has suggestions.
>>
>
> I wouldn't bother; if you're worried about that, try a tamper-evident
> system rather than tamper-proof - for instance, MD5 checksums of
> everything:
>
> $ md5sum *>checksum.txt
> $ md5sum checksum.txt
> 123412341234123412341234 md5sum
>
> Save that meta-checksum and have an easy way to read it back - that
> way, you can be sure they haven't just rebuilt the checksum file. If
> that one checksum has changed, you know something else has; to find
> out which:
>
> $ md5sum -c --quiet checksum.txt
>
> No need to restrict what you send out that way, and you can still get
> a guarantee that they haven't fiddled with anything.
>
> ChrisA
So you could think of the meta-checksum as a script wide version control
of what is installed.  Then, at key entry points, take the hit
and re-generate the meta-checksum and compare.  If bad, you
have a major version control error, do not process further.

Makes sense, so long as the user does not bother to regenerate
the meta-checksum as well.

Would be more extensible if in debugging, users can disable
this feature. or have a tool that updates the meta-checksum
so that they can run one-off code to fix problems.  Oddly,
this feature would make it easier to change code and still
keep things running.  But we could use the value in the support
chain to say, "something changed, what's going on?".

Thoughts?
K
-- 
Mr. Kristen J. Webb
Teradactyl LLC.

PHONE: 1-505-242-1091
EMAIL: kwebb at teradactyl.com
VISIT: http://www.teradactyl.com

  	Home of the

  True incremental Backup System