ci: pin the lief version in linux-debian.Dockerfile

[muxator]

#1359 introduced a new script (tools/symbol-check.py), which is meant to be run in CI and catch symbol visibility issues. The script depends on lief (https://lief.re/), in its python incarnation.

On 2025-03-10, 8ed1d83 installed lief in linux-debian.Dockerfile via pip install lief, without pinning its revision. This would introduce a covert dependency on time in a CI run: the lief version would slowly drift as new versions (potentially breaking) would be released.

At the time the latest lief version was 0.16.4, released on 2025-02-23 (source: https://pypi.org/project/lief/#history).
The latest version as of today is 0.16.6, which is also the version the CI pipeline has been using.

This commit pins the version to 0.16.6, so that future upgrades to the library will need to be explicit.

[real-or-random]

Concept NACK

I think we want LIEF updates in general. And then we'll need to deal with breakage from time to time anyway. Pinning just creates more work because we need to bump from time to time.

At least, this is true as long as we LIEF updates are not annoying. And so far, they're not. We haven't seen any breakage so far.

[muxator]

I just want to suggest that, when it comes to dependencies and external tools, it could be responsible to exclude as many sources of uncertainties as possible:

• a dependency might change in unpredictable ways: from incompatibilities, to attacks (this is a high profile cryptographic library, after all);
• reproducibility would be harder, because two runs performed at different times could always give different results.

I think that accepting to do the explicit work of bumping the LIEF version when needed would buy more robustness to the project, even if there were no problems until today.

However, I understand that these are general considerations: they might not be true for secp256k1, given its current resources and priorities.

As long as the choice is explicit I see no problem if secp256k1 decides to keep the CI container as-is.

Thanks for the project, anyway!

[fanquake]

Think I agree with @real-or-random. Leaving this unpinned seems fine, the risk of breakage seems low, and generally, being made aware of the breakage immediately just means we can fix it faster.

[real-or-random]

Okay, closing. Please don't hesitate to discuss further and disagree with the Concept NACKs above.