The OpenSSL/LibreSSL shuffle

Two and a half years ago, someone tried using my UUID (Universally Unique Identifier) library with a modern version of OpenSSL (Secure Socket Layer) [1]. At the time I rejected the patch because I couldn't use it (I was, and still am, using an older version of OpenSSL). Then today, I was notified that someone else tried to do the same [2], and I figured it was time to actually adress the issue.

It used to be that you could do:

#include <openssl/evp.h>

unsigned char hash[EVP_MAX_MD_SIZE];
EVP_MD_CTX    ctx;

EVP_DigestInit(&ctx,EVP_md5());
EVP_DigestUpdate(&ctx,data,len);
EVP_DigestFinal(&ctx,hash,&hashsize);

The context variable declaration changed and you no longer could do that. Instead, you now have to:

#include <openssl/evp.h>

unsigned char  hash[EVP_MAX_MD_SIZE];
EVP_MD_CTX    *ctx;

ctx = EVP_MD_CTX_new();
if (ctx != NULL)
{
  EVP_DigestInit(ctx,EVP_md5());
  EVP_DigestUpdate(ctx,data,len);
  EVP_DigestFinal(ctx,hash,&hashsize);
  EVP_MD_CTX_free(ctx);
}

It's an annoying change and yet, I can understand why the change was made—future updates of hash functions could use more space than what you statically allocate which could lead to a buffer overrun. It also changed what used to be an error-free path (well, buffer overruns aside) to a path that could fail. The reason I put off making the change was trying to find the version of OpenSSL where the change was made. After downloading over a dozen versions of OpenSSL and checking each one, I found the change in version 1.1.0.

This also prompted me to spend the time to update my TLS (Transport Layer Security) Lua module [3] to the latest version. This also involved downloading over a dozen versionf of LibreSSL and checking each one. There was only one minor change involved, and that was adding a new call to the module.

I have yet to profile LibreSSL [4] though.

[1] https://github.com/spc476/SPCUUID/pull/3

[2] https://github.com/spc476/SPCUUID/issues/4

[3] https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c

[4] /boston/2020/12/28.1

Gemini Mention this post

Contact the author