On 10/12/11 3:26 PM, Chris Angelico wrote:
On Thu, Oct 13, 2011 at 8:10 AM, Kristen J. Webb<kw...@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: kw...@teradactyl.com
VISIT: http://www.teradactyl.com
Home of the
True incremental Backup System
--
http://mail.python.org/mailman/listinfo/python-list
