Dennis Lee Bieber wrote:
This is after they'd made an 11x14 enlargement of the stolen
print, cleaned it up with a marker, reduced to life size, and etched
onto printed circuit board to form a mold for making a latex skin.
Which, BTW, also fooled the lock.
[Aahz]
Assuming you're talking about CPython, strings don't really participate
in garbage collection. Keep in mind that the primary mechanism for
reaping memory is reference counting, and generally as soon as the
refcount for an object goes to zero, it gets deleted from memory.
[Les
Les Schaffer wrote:
i am working on a python application that uses encryption as part of its
security features. so then at some point someone has to enter a
passphrase into the system and passed into a decryption functions (we
are using gpg via subprocess).
so i am curious. so long as i
Fredrik Lundh wrote:
a time (if that's possible; if not, you may need to write a custom
extension that builds a command string in a C-level buffer, runs the
command, and then overwrites the buffer before returning).
on the other hand, subprocess seems to support the buffer interface, so
Fredrik Lundh wrote:
Les Schaffer wrote:
i am working on a python application that uses encryption as part of its
security features. so then at some point someone has to enter a
passphrase into the system and passed into a decryption functions (we
are using gpg via subprocess).
so i
Paul Rubin wrote:
GC simply releases the memory for other uses in the application. It
doesn't necessarily zero the memory.
release is followed by some probability of eventual overwrite; check.
Just what attack are you trying to protect against, if swap space is
less of a problem than
Tim Peters wrote:
Purely accidental -- nothing guaranteed -- details can ( do) change
across releases. Read obmalloc.c for a tour of the accidents du jour.
cool. thanks for the pointer!
Not true, so be glad to forget it.
forget what??? ;-)
A curious possibility: if you do a debug
Fredrik Lundh wrote:
Fredrik Lundh wrote:
a time (if that's possible; if not, you may need to write a custom
extension that builds a command string in a C-level buffer, runs the
command, and then overwrites the buffer before returning).
myself, i enjoy building C extensions, but would
Les Schaffer [EMAIL PROTECTED] writes:
keys are on a USB drive key ring. gpg accesses the key ring as needed,
but in a separate process. and gpg is done with its work early on in our
app lifetime. comes back at end to encrypt and then app is done.
gpg is fairly careful about passphrases. Why
Paul Rubin wrote:
gpg is fairly careful about passphrases. Why are you collecting the
passphrase in the Python app instead of letting gpg handle it?
as i recall we did that because we needed the passphrase more than once,
and didnt want to have to make the users type in something that long
Les Schaffer [EMAIL PROTECTED] writes:
i forget whether gpg can be given a list of files to decrypt. but cuz of
what we are doing, i still believe we would need to call gpg more than
once.
Yes, gpg --batch if I remember correctly.
Fred Lundh's scheme for blanking the passphrase looks good
Dennis Lee Bieber [EMAIL PROTECTED] writes:
This is after they'd made an 11x14 enlargement of the stolen
print, cleaned it up with a marker, reduced to life size, and etched
onto printed circuit board to form a mold for making a latex skin.
Which, BTW, also fooled the lock.
I remember
i am working on a python application that uses encryption as part of its
security features. so then at some point someone has to enter a
passphrase into the system and passed into a decryption functions (we
are using gpg via subprocess).
so i am curious. so long as i drop all reference to the
2006/8/30, Les Schaffer [EMAIL PROTECTED]:
is there a best practice way to do this?
I'm not a cryptographer, but you should really try the function
collect() inside the gc module.
--
Felipe.
--
http://mail.python.org/mailman/listinfo/python-list
Les Schaffer [EMAIL PROTECTED] writes:
so i am curious. so long as i drop all reference to the passphrase
string(s), eventually it gets garbage collected and the memory recycled.
so before long the phrase is gone from memory.
is there a best practice way to do this?
You can't rely on
Paul Rubin wrote:
You can't rely on anything like that, either on the Python GC side or
from the OS (which might have long since written the passphrase out to
the swap disk) without special arrangement.
we offered to disable swap for this app (its not memory intensive) but
this level of
In article [EMAIL PROTECTED],
Les Schaffer [EMAIL PROTECTED] wrote:
so i am curious. so long as i drop all reference to the passphrase
string(s), eventually it gets garbage collected and the memory recycled.
so before long the phrase is gone from memory.
Assuming you're talking about CPython,
Aahz wrote:
Assuming you're talking about CPython, strings don't really participate
in garbage collection. Keep in mind that the primary mechanism for
reaping memory is reference counting, and generally as soon as the
refcount for an object goes to zero, it gets deleted from memory.
ok so
Les Schaffer [EMAIL PROTECTED] writes:
understood, i meant best practice in terms of the less rigorous garbage
collection. if the collect() function hastens garbage collection for
unreferenced strings like a passphrase, it costs us nothing and buys us
a wee bit.
GC simply releases the memory
19 matches
Mail list logo
