On Friday, January 22 2021 at 00:58:06 +0100, Tim Düsterhus wrote: > Bertrand, > > Am 22.01.21 um 00:45 schrieb Bertrand Jacquin: > >> The strcmp converter is not binary safe. It uses strncmp internally. > > > > It is not indeed, what do you think of improving current related strcmp > > documentation and example to add an hex conversion to achieve the same > > goal? This would be pretty slow, I'd be happy if you have something more > > efficient to offer for this use case. Also, CRYPTO_memcmp() is > > Do you have a specific use-case in mind? Where would you / one need to > compare binary data outside something like hash comparisons?
I don't have a specific use case in mind, the idea was to reduce the feature set gap from the underlying lib being used and so remove confusion for the user. However I initially though this was introduced in 1.0.2 when it technically was introduced within a patch release. I don't believe it is legit for haproxy to carry on burden for old release of OpenSSL by backporting some feature used by a very few users and instead encourage them to upgrade if they really need this constant time binary comparison. > I'd say that users can figure out how to combine strcmp with the hex > converter themselves. If performance is desired it might make sense to > add a memcmp() converter that nicely complements strcmp and > secure_memcmp. It's just that I did not yet have a need for this (and > apparently no one else did). Good to me. > > relatively simple and could be rewritten in openssl compat as an inline > > function too. > > I prefer to defer to a "known good" implementation. Getting this right > across compilers is non-trivial to prevent the compiler from optimizing > it. OpenSSL specifically includes Assembler implementations. IMO If > users actually need secure_memcmp in HAProxy they should upgrade their > OpenSSL. I concur on this. Cheers, -- Bertrand
