crypto.h: info leak / reproducibility issue via public header in 4.1.0

[vszakats]

openssl/crypto.h in 4.1.0 has this:

#define OPENSSL_malloc(num)>CRYPTO_malloc((num),OPENSSL_FILE,OPENSSL_LINE)
#define OPENSSL_strdup(str)>CRYPTO_strdup((str),OPENSSL_FILE,OPENSSL_LINE)
#define OPENSSL_free(addr)<>CRYPTO_free((addr),OPENSSL_FILE,OPENSSL_LINE)

whereas in 4.0.0 these lines were:

#define OPENSSL_malloc(num)>CRYPTO_malloc((num),NULL,0)
#define OPENSSL_strdup(str)>CRYPTO_strdup((str),NULL,0)
#define OPENSSL_free(addr)<>CRYPTO_free((addr),NULL,0)

It means that LibreSSL dependencies using these APIs are now affected by
__FILE__ and __LINE__ containing private/local paths and also broken
reproducibility unless built with OPENSSL_NO_FILENAMES, like LibreSSL itself.

I expected OPENSSL_NO_FILENAMES to be a private macro, and LibreSSL
public headers not use to __FILE__ (and __LINE__).

Ref: #761

[botovq]

This matches what OpenSSL do?

https://github.com/openssl/openssl/blob/934086fb9161e2f4967ad8577a1f3e489cff73d2/include/openssl/crypto.h.in#L102-L103

[botovq]

Your diff also exposed these names in public headers, so I don't get the issue. Isn't it up to the application to build with OPENSSL_NO_FILENAME if they don't want these to "leak"?

[botovq]

I think we match what OpenSSL says this does: https://docs.openssl.org/master/man3/OPENSSL_FILE/

The macros OPENSSL_FILE and OPENSSL_LINE typically yield the current filename and line number during C compilation. When OPENSSL_NO_FILENAMES is defined they yield "" and 0, respectively.

[vszakats]

Maybe OpenSSL reflects the build-time OPENSSL_NO_FILENAMES setting in their public headers?

(I haven't made tests with OpenSSL recently, but also haven't seen this issue there, before switching to LibreSSL.)

If "leak" is problematic wording for some reason, we can stick with "breaks reproducibility".

[vszakats]

Maybe OpenSSL reflects the build-time OPENSSL_NO_FILENAMES setting in their public headers?

OpenSSL (3.5.0) seems to be doing that:

openssl/configuration.h:

# ifndef OPENSSL_NO_FILENAMES
#  define OPENSSL_NO_FILENAMES
# endif

[botovq]

I see. My OpenSSL builds don't have this since I don't set this option -- I build software from /usr/ports from publicly known paths, so I don't have this problem in the first place.

So... This whole thing was added on your request. As far as I understand it, you can solve your issue with -DOPENSSL_NO_FILENAMES for now, so unfortunately your concern wasn't quite addressed. Sorry about that.

I plan on removing the public *err() and I am not at all married to keeping the files and lines in OPENSSL_malloc/free/etc, so hopefully we can address this problem for good in the next release. Does that sound good?

[vszakats]

Sound perfect to me, thanks a lot for making this happen. Just kicked off a curl build with the small workaround.

(I'm not sure why it turned out this complicated in OpenSSL. Maybe for compatibility? It'd be easier if the __FILE__ use would be the non-default behavior needing a debug option.)