On Tue, 19 Jun 2001, Toby Dickenson wrote:
However, I dont think encrypting user passwords is enough. Data.fs may contain plaintext passwords for relational databases, and in many cases it contains arbitrary confidential information.
True. The RDBMS passwords are probably more sensitive than user passwords, and you certainly can't encrypt the RDBMS passwords.
Would it make more sense to encrypt whole storages?
Probably not. The idea is to encrypt them irreversibly, a scheme that doesn't work for most other kinds of data.
The risk is incompatibility with HTTP digest auth, which I imagine nobody is using right now.
And incompatability with almost all other not-yet-invented authentication schemes.
What I had in mind, though, is that people would be allowed to turn off encryption in the UI. They would just have to then reset their passwords to use the new authentication scheme.
2) If cPickle were to do something similar to "intern"-ing strings when loading objects from the ZODB, Zope might consume significantly less RAM on busy servers. ZODB uses lots of strings. ZODB caches cannot be shared among threads. But strings, being immutable, can be safely shared. We couldn't just intern the strings since that would make them immortal, but if we used weak references it could work.
I like this alot.
Can the idea be extended to other objects which Zope treats as immutable? For example, DTMLMethod objects hold a dtml parse tree made up of cvlass instances. This must have a significant memory footprint.
Good idea. I think such a thing could only be applied at the application level (that is, DTMLMethod would have to be intimately aware of sharing). It would be difficult to apply at the cPickle level. Shane