Nay

[Steffen Nurpmeso]

P.S.

Steffen Nurpmeso wrote in
 <20230125002226.WFpe5%steffen at sdaoden.eu>:
 |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)