When I said flag, I meant a _shared_ flag. If I set the flag on "foo", all strings "foo" anywhere in the program would be treated as secret by %O. One needs a function to set the flag, but normal programs should never try to clear it.
If a function is supposed to print "foo" (a string which is not secret) and suddenly starts printing "CENSORED", then this leaks the information that another part of the program has a secret string which also happens to be "foo". If there is only one part of the program that sets the flag, and it sets it on keys, they you will have exposed the fact that the key is "foo". That's pretty bad, woudln't you say?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-30 15:40: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
When I said flag, I meant a _shared_ flag. If I set the flag on "foo", all strings "foo" anywhere in the program would be treated as secret by %O. One needs a function to set the flag, but normal programs should never try to clear it.
As for objects, a C module that wants to operate on strings need a way to dig out a char * from the internal representation. You don't want to support more than one internal representation. Typical examples may be Stdio.file->write and Crypt.md5()->update (both may well be invoked with sensitive information as input).
For the general case, the C code would have to allocate a new char (or wchar_t, or whatever) array, probably on the stack, and then copy the contents of the general string object character by character using the `[] operator. You can't do it the easy way by casting the object to a normal pike string, as that defeats the entire purpose of SecretString.
And in the paranoid case, it should of course clear its copy again before it's deallocated. That's one of the uglier aspects: You'd like to put the knowledge that a string should be wiped from memory after it's used in the SecretString class, but still every single C module that handles strings will need to know about that.
/ Niels Möller ()