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

1. 
   muxator commented at 9:32 am on July 29, 2025: none

   #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, 8ed1d83d92d1 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.

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

   #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, 8ed1d83d92d1 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.

   ff3f12b4fe
3. real-or-random added the label ci on Jul 29, 2025
4. 
   real-or-random commented at 10:28 am on July 29, 2025: contributor

   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.

5. 
   muxator commented at 1:03 pm on July 29, 2025: none

   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!

6. 
   fanquake commented at 8:35 am on July 30, 2025: member

   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.
7. 
   real-or-random commented at 9:35 am on July 30, 2025: contributor

   Okay, closing. Please don’t hesitate to discuss further and disagree with the Concept NACKs above.
8. real-or-random closed this on Jul 30, 2025

   ---

Contributors
muxator real-or-random fanquake

Labels
ci