P.S.
Steffen Nurpmeso wrote in
<20230125002226.WFpe5%steffen@xxxxxxxxxx>:
|As a potentially depressing, disappointing, malicious, bogus
|... comment i want to cry out loud that *if* something is
|
| present for backwards compatibility with OpenSSL prior to
| version 3 and is different to the EVP_CIPHER_fetch()
| function since it does not attempt to "fetch" an
| implementation of the cipher.
|and
...
|then the returned object *should*, in my opinion, have the same
|semantics than it had for a quarter of a century (more or less).
|
|And that direct things like EVP_sha256() also are potentially
|dead-end "hulls" i find even more terrible, especially given that
|they are documented as
|
| These functions return a EVP_MD structure that
| contains the implementation of the message digest.
...
And especially because the actual "fetch" is a one-liner
EVP_CIPHER_fetch(NULL,
cipher->nid == NID_undef ? "NULL" : OBJ_nid2sn(cipher->nid), "");
(unless i am mistaken in the loong way to the concrete thing) and
several functions like PKCS7_encrypt() do not work with
a CIPHER_CTX, and an easy workaround as is possible for digests
#ifdef a_XTLS_CRYPTO_FETCH
a_XTLS__JFETCH:/* C99 */{
EVP_MD_CTX *mdcp;
if((mdcp = EVP_MD_CTX_new()) == NIL)
*mdp = NIL;
else{
if(!EVP_DigestInit_ex(mdcp, *mdp, NIL))
*mdp = NIL;
EVP_MD_CTX_free(mdcp);
}
goto jleave;
}
#endif
is not possible because EncryptInit_ex takes additional parameters
that may not be known (easily).
Maybe irony can be found in words as of postfix
Workaround: OpenSSL 3.x EVP_get_digestbyname() can return
lazily bound handles that may fail to work when one attempts
to use them, because no provider search happens until one
constructs an actual operation context. In sufficiently
hostile configurations, Postfix could mistakenly believe
that an algorithm is available, when in fact it is not. A
similar workaround may be needed for EVP_get_cipherbyname().
Fix by Viktor Dukhovni. Files: tls/tls.h, tls/tls_dane.c,
tls/tls_fprint.c, tls/tls_misc.c.
And, finally, how could anyone write a configurator, as is my
link_check tls_blake2 'TLS: BLAKE2 digests' \
'#define mx_XTLS_HAVE_BLAKE2' << \!
#include <openssl/evp.h>
int main(void){
EVP_blake2b512();
EVP_blake2s256();
return 0;
}
!
when the above is, in fact, totally meaningless, and _running_
this thing (as via run_check()) is not possible in
cross-compilation scenarios?
Wouldn't it make sense to at least say those direct accessors are
guaranteed to return a valid usable object if the above
configuration check succeeds and the standard standard
OSSL_LIB_CTX is in use (aka has not been set explicitly, or been
used explicitily in a _fetch())?
Fine thing with the magic carpet change, but all programs i deal
with (aka use) simply need that "old" behaviour, reliably.
Only my one cent.
So i for myself keep the cipher code "as-is", but then do
...looking up configure-time detected arrays of useful things..
..and (new!) set "cp" to the name of the found thing, and jump..
#if defined mx_HAVE_TLS_ALL_ALGORITHMS && !defined a_XTLS_CRYPTO_FETCH
if((cipher = EVP_get_cipherbyname(cp)) != NIL)
goto jleave;
#endif
#ifdef a_XTLS_CRYPTO_FETCH
a_XTLS__JFETCH:
if((cipher = EVP_CIPHER_fetch(NIL, cp, NIL)) != NIL){
*freeit = TRU1;
goto jleave;
}
#endif
..and do a "re-"fetch. Well it seems to work, and the call tree
is pretty shallow for the new "freeit" parameter.
This is all dynamic now, a.k.a. the Olymp of programming, but
waiting with cheering.
But congratulations for the QUIC implementation again!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
