Work in FIPS enabled environments about chameleon

[jamadden]

The base template already uses hashlib.sha1 in digest(). Could that be used in the ZPTTemplate if it's FIPS compliant (I'm assuming it must be)? That seems simpler.

The only consequence I can think of is that on-disk template caches would be invalidated, but that doesn't seem significant because it happens anyway when you change the installed package versions.

This is really a question for @malthe

[frapell]

@jamadden Yeah, makes more sense, I just tried it and worked fine, so I have changed it

[malthe]

I suppose that it makes sense to switch to SHA256 – perhaps with an option to provide a salt using an environment variable CHAMELEON_CACHE_SALT. That would provide some additional security in the case where we can have user-contributed templates.

[jamadden]

I'm probably missing something, but it's not clear to me that being able to provide a salt in the environment adds much/any benefit. As I understand it, the main purpose of a salt is to keep two identical inputs from having identical hash outputs; for that to work, the salt has to change based on some function.

Take password hashing; you might, for example, use the username as the salt. In that way, hash('password', salt='joe') is never the same as hash('password', salt='alice'), and no one that compromises Joe's password (or knows its hash) can see that Alice's hashed password is actually the same and transitively compromise her password.

But if the salt is hardcoded, or a single environment variable set for the life of a process, that goes away: hash('password', salt=CHAMELEON_CACHE_SALT) == hash('password', salt=CHAMELEON_CACHE_SALT). The extra dimension of mixing in the username (context) is lost.

It seems that we'd at least need a way to distinguish salts for "application provided" templates vs "user provided" templates, and I don't know how that could be generalized at this level.

If you're worried about some sort of on-disk cache poisoning, wouldn't it be easier to just delete the cache? Or make different processes use different cache directories (already possible with environment variables)?

[jamadden]

Besides the (probably negligible) speed impact, something to consider about using SHA256 vs SHA1 is that the former adds 24 characters to the hex form, which would result in longer filenames. (Going from md5 to sha1 already adds 8 characters.) In an old Chameleon disk cache I have laying around, the longest filename is 79 characters; adding 8 + 24 brings that to 111.

I know that in the past, some operating systems had pretty tight limits on the length of path segments and the total path (cough Windows); I don't know if that's true anymore, but it's something to think about.

[malthe]

@jamadden yes, you're right – adding salt doesn't make sense here.

On the length of the hash, there is no requirement to use the full hash value. AFAIK SHA256 is often truncated to 128 bits without a significant loss in cryptographic properties.

[frapell]

@malthe @jamadden I have no preference on which algorithm to use, as far as I understand, this part of the code is used to generate the filename for cached templates, so has no security implications whatsoever, right?

it might make sense though, to use SHA256 to avoid this same issue in the future...