On 06/19/2012 05:05 AM, Robert Collins wrote:
> A few quick thoughts:
> - We'd love patches that make squid explicitly aware of e.g. FIPS
> mode, so that we can enforce it ourselves. We've no idea today when we
> change something whether its going to impact on such external needs,
> and frankly, tracking it is going to be tedious and error prone,
> leading to the sort of flip-flop situation you have.
I've attached a first patch. Note that I have not been able to test the
helpers yet.
Since the md5 functions are called in void functions that cannot return
errors up the chain, I had to go up the call chain a little bit. I did
put in an assert() in case I missed a callchain somewhere.
I've added some comments in the patch on how you can test this without
actually running fully in fips mode.
Let me know if this is something along the lines of what you were
thinking of.
> That said, if the FIPS standard doesn't like MD5, there is no need for
> use to use it at all, we could use sha1 as a build time option for
> cache keys (or take the first N bits of sha1), if that helps: that
> would allow us to be entirely MD5 free when desired.
I thought about doing that, but it would also require some tricks when
people update squid with a cache based on md5. For now I added another
entrance function into the MD5 code that you call when you know there is
no fips issue. This is what the store_key/MemObject code now calls.
I'm interested in feedback and would love something like this to get
merged into upstream
Paul
This archive was generated by hypermail 2.2.0 : Wed Jun 20 2012 - 12:00:09 MDT