Yes, hm, specialized classes is probably good. But maybe as derivatives of System.Memory, so it becomes natural to use mprotect? Secure.String, or SecureString, or Crypto.SecureString?
But can the Crypto parts handle objects who imitates strings, especially without making a shared string of the object?
/ Mirar
Previous text:
2003-01-28 22:51: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
I was about to suggest a similar thing: Make a SecretString class that overloads sufficient operators to behave reasonably like a string: Adding a string with a SecretString would produce a SecretString, indexing a substring out of a SecretString would produce a SecretString, indexing a single element out of a SecretString could perhaps produce a plain integer since the amount of "secrecy" in any single element could be considered low, doing sprintf("%O",...) on a SecretString would produce "SecretString(CENSORED)", etc.
Especially that last item would be really good to avoid the common pike mistake to leave e.g. passwords in function arguments, which gets printed out in backtraces.
I can't imagine sensitive data being represented as anything but a string, a bignum, and perhaps as an array of integers. So adding a SecretString and a SecretInteger class would probably be enough. If I were to write a new security related module for Pike, I'd start with those as fundamental building blocks.
/ Martin Stjernholm, Roxen IS