Install setuptools before t-encrypt version resolution

[oleksandrSydorenkoJ]

What:

Fix the t-encrypt Python wheel build so the bundled native libencrypt.so is built against OpenSSL 3 and validated before publish.

Why:

The previously published wheel could depend on libcrypto.so.1.1, which is not available in some Ubuntu environments and causes import t_encrypt to fail at runtime.

The wheel also bundles a native Linux .so, so it must be platform-tagged and must not be published as py3-none-any.

How:

• Added OPENSSL_GIT_REF support in deps/build.sh, while keeping the default OpenSSL version unchanged.
• Set OPENSSL_GIT_REF=openssl-3.0.15 only for the Python t-encrypt wheel build.
• Replaced the OpenSSL checkout with a direct quoted git checkout --detach "$OPENSSL_GIT_REF" instead of eval.
• Marked the t-encrypt distribution as binary so wheels containing libencrypt.so are platform-specific.
• Added wheel validation gates for:
  • rejecting py3-none-any;
  • running auditwheel show;
  • checking that t_encrypt/libencrypt.so is bundled;
  • ensuring the bundled library does not depend on libssl.so.1.1 or libcrypto.so.1.1.
• Updated CI to build one t-encrypt wheel artifact and validate that same artifact on Ubuntu 22.04 and Ubuntu 24.04.
• Installed setuptools before reading the package version because Python 3.13 runners do not guarantee it is available by default.

Checklist:

• Documentation N/A
• Tests
• Ready to be merged

[Copilot]

Pull request overview

Updates the publish workflow to ensure Python packaging tooling is available before resolving the t-encrypt package version, preventing failures on newer runners (e.g., Python 3.13 where setuptools may not be preinstalled).

Changes:

• Install/upgrade pip and setuptools before running the version-resolution step in the publish workflow.

Comments suppressed due to low confidence (1)

.github/workflows/publish.yml:140

• This step mixes python3 and python invocations in the same workflow. On GitHub-hosted runners this is usually the same interpreter, but it’s not guaranteed; using a single interpreter (python) ensures the pip install (setuptools) and the version resolution run against the exact same Python configured by actions/setup-python.

      run: |
        lib_path="${PWD}/build_t_encrypt_python/threshold_encryption/libt_encrypt_python.so"
        echo "T_ENCRYPT_LIB_PATH=${lib_path}" >> "$GITHUB_ENV"
        python3 -m pip install --upgrade pip setuptools

        # Calculate Python package version
        cd python
        BASE_VERSION=$(python3 setup_t_encrypt.py --version)