Procedure for validating system libsecp256k1 library

[sorenstoutner]

I am working on updating the Debian package to 4.4.5. For some time Debian has maintained a patch to change the so name of the expected libsecp256k1 file because the version included in Debian had a different number. I see that the current version of ecc_fast.py now tries to detect any installed so file. This is a really nice change and allows us to drop the patch that was hardcoding our file name.

But before I went on my merry way I thought it would be a good idea to test to make sure everything was working. I read over all the libsecp256k1 issues I could easily find to see if there were instruction for how to test to make sure everything is working. However, it seems the topic is more complicated that I had originally anticipated, so I thought it might be best if I just ask the following two questions:

1. What are the testing procedures to make sure that Electrum can find the system libsecp256k1 (Debian's file is currently named libsecp256k1.so.1)?

2. libsecp256k1 library found but it was built without required module (--enable-module-recovery) #6465 indicates that, at least at one point, the version of libsecp256k1 in Debian was built without an optional but important module. Is there a procedure I can use to test if this is still the case? (If so, I would be willing to put forth some effort to get it included in the Debian package, but first I need a way to test for it.)

For reference, the current Debian package is 0.2.0-2.

[SomberNight]

1. What are the testing procedures to make sure that Electrum can find the system libsecp256k1 (Debian's file is currently named libsecp256k1.so.1)?

Not sure I understand the question. Do you mean how you can manually test if it is working? Just try to run electrum, it will try to dynamically load the .so at runtime, and exit if it failed. Basically if the python library import succeeds (or e.g. the GUI appears), it worked.
A better check would be to run the unit tests, e.g. $ pytest electrum/tests -v (which needs some additional dependencies:)

electrum/setup.py

Line 47 in c851390

'tests': ['pycryptodomex>=3.7', 'cryptography>=2.6', 'pyaes>=0.1a1'],

Or are you asking for some easy script you can add as an assert into the packaging framework?

2. libsecp256k1 library found but it was built without required module (--enable-module-recovery) #6465 indicates that, at least at one point, the version of libsecp256k1 in Debian was built without an optional but important module. Is there a procedure I can use to test if this is still the case? (If so, I would be willing to put forth some effort to get it included in the Debian package, but first I need a way to test for it.)

Same as above. When we try to load the .so dynamically, we test if the relevant symbols exist.

electrum/electrum/ecc_fast.py

Line 119 in c851390

# --enable-module-recovery

[sorenstoutner]

Thanks for the quick response.

I thought I had read something about how Electrum would downgrade to using less efficient mechanisms if libsecp256k1 was not available. Perhaps that was just for an older version of Electrum. Anyway, knowing that an error message will be produced on start if libsecp256k1 is not correctly detected or is missing an important module is very helpful. Currently in Debian there is no error message when Electrum is run, so that would indicate that we have the libsecp256k1 issues sorted out.

In case anyone else is interested, this is the result of running the tests:

======================================================================= warnings summary =======================================================================
electrum/tests/test_network.py::TestNetwork::test_can_connect_during_backward
electrum/tests/test_network.py::TestNetwork::test_chain_false_during_binary
electrum/tests/test_network.py::TestNetwork::test_fork_conflict
electrum/tests/test_network.py::TestNetwork::test_fork_noconflict
  /home/soren/Desktop/electrum/electrum/interface.py:410: RuntimeWarning: coroutine 'Interface.run' was never awaited
    task = await self.network.taskgroup.spawn(self.run())
  Enable tracemalloc to get traceback where the object was allocated.
  See https://docs.pytest.org/en/stable/how-to/capture-warnings.html#resource-warnings for more info.

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
==================================================== 633 passed, 3 skipped, 4 warnings in 76.95s (0:01:16) =====================================================

Nothing there mentions libsecp256k1, nor does any of it appear to be too serious.