Can anyone elaborate on this? I find the wording a wee bit alarming. If someone as knowledgeable as gmaxwell is hazy on exactly what consensus changes might be caused by running with different versions of a dependency, then isn't there something wrong in how the software is put together?
The only sensible design choices are (I would think) to either roll your own stuff or to only call third-party libraries through carefully designed wrappers to prevent (minimize, more likely) unwanted consensus changes from sneaking in. Or is this a matter of older versions getting this wrong and newer versions getting it right?
The latter: recent versions don't use OpenSSL at all (or didn't last I checked), and it hasn't been used for consensus since 0.12 in 2016.
Back when Bitcoin was written OpenSSL had been very stable for a looong time and had a good track record of preserving legacy interfaces and behaviors when it changed. Satoshi could be forgiven for thinking it was sufficiently stable, particularly because it was far from clear how tricky consensus consistency was. Your use of the word "minimize" makes it clear you know, but it wasn't always quite so obvious how truly difficult it was.
In 2015/2016-ish a number of concerning vulnerabilities were found in OpenSSL and a lot of attention was put on the project massively reworking things, making incompatible interfaces changes, and putting out giant updates (I seem to recall one of their diffs was like 400k lines...). They managed to make changes in signature validation that would have been utterly consensus breaking for Bitcoin, and did so without even release note-ing the change.
Fortunately by then Bitcoin had mostly completed the move off of it and had deployed a soft-fork to restrict the set of accepted signatures going forward enough that their consensus break wouldn't matter for newly created blocks, as a result of
an openssl consensus consistency vulnerability we'd discovered. Though there is a window of openssl versions + bitcoin versions where it will compile and run without issue then reject some older blocks due to openssl's changes, this footgun is mostly avoided due to the fact that openssl broke their api a number of times around the same time.
It could have been quite a mess, had the openssl behavior changed before bitcoin devs realized it was a potential source of issues. Today AFAIK bitcoin uses no external dependencies in consensus beyond the programming language itself. Maybe some small amount of boost usage still exists in consensus, though there was a long term effort to eliminate it, simply because the authors of external code can't be expected to manage the very special requirements of consensus consistency.
The patches people use to use modern openssl with old bitcoin code paper over the major known consensus change in openssl, but there isn't any guarantee that there haven't been other ones or that its a complete fix (since even at the time openssl made those changes the 'fix' was to upgrade to bitcoin that didn't use it for consensus). Not that I think it's too likely that there will be extra issues, but if the exercise is to tell if old versions would work, you should reconize that if you use an inauthentic openssl you're only getting an approximate answer.
Because post-BIP66 bitcoin is very exacting in the signature encodings it will accept, I think it's unlikely that any new signatures have been accepted that really old openssl would reject-- though not impossible: we did also find bugs in openssl's bignums, just none that we could find a way to exploit for a consensus split. It's more likely that if there were issues it would be of the form of more modern openssl being even more picky and rejecting the chain when old openssl wouldn't have.
