yubico-authenticator: update to 7.3.0

[palto42]

Summary

• Release notes here
• Corrected the package license

Test Plan

Installed locally, viewed accounts and passkey and added/removed a certificate.

Checklist

• Package was built and tested against unstable
• This change could gainfully be listed in the weekly sync notes once merged

[palto42]

I'm not fully sure about the approach to install uv which is now required to build the helper app.
I added the uv install script to the list of source codes so that the checksum of it will be verified. As far as I an see the script itself automatically verifies the checksum or the downloaded binary.

[EbonJaeger]

I don't think using the build_helper.sh script is what we want to be doing, and we definitely do not want to be installing uv in the middle of building another package. Does the existing way of building the package not still work? Their script isn't really doing anything special.

[palto42]

The old way didn't work anymore, but I haven't looked into the new build script yet.

[EbonJaeger]

It looks to be failing during the Flutter build; the helper builds fine with the old method.

[palto42]

In my first try with the old helper build the package was built successfully, but the app failed loading the helper.

The helper script is now developed using uv and has an uv.lock file.
I don't think that building it with poetry makes sense, since this is not how the script was tested by the developer. The old build in the Solus package used poetry, which will ignore the uv.lock file and provide a different result.
In my view we need to use uv for the build in order to ensure that the produced code is accurate.

We can avoid using the provided helper install script, although I'm not clear what the benefit would be. For other code build we also rely on the recommended build instructions and use the provided make commands.

[palto42]

I tried extracting the helper build command from the helper install script, which works in principle.
But changing it to avoid using uv without risking that the resulting code differs looks challenging.

I recognized that the old Solus package was missing the helper license files, which could be a license violation (but I'm not an expert in this topic).

build      : |
    # First, build the Python authentication helper
    # Extract from build-helper.sh
    export OUTPUT="$PWD/build/linux"
    pushd helper
    uv sync --locked
    uv run --no-sync pyinstaller authenticator-helper.spec --distpath $OUTPUT
    # Fixup permissions (should probably be more strict)
    find $OUTPUT/helper -type f -exec chmod a-x {} +
    chmod a+x $OUTPUT/helper/authenticator-helper
    # Generating license files...
    uv build
    VENV="$OUTPUT/helper-license-venv"
    uv run python -m venv $VENV
    $VENV/bin/pip install --upgrade pip wheel
    $VENV/bin/pip install dist/authenticator_helper-0.1.0-py3-none-any.whl pip-licenses
    $VENV/bin/pip-licenses --format=json --no-license-path --with-license-file --ignore-packages authenticator-helper zxing-cpp --output-file ../assets/licenses/helper.json
    popd

...

[EbonJaeger]

If we want to build it with uv, then we should package uv at the very least, instead of running its install script in the build container.

[palto42]

Would installing uvvia pip be an alternative to packaging it? I could pin it to a specific release with hash verification.
Currently uv is getting quite frequent updates, so that it may cause significant effort to maintain that package, if we want to keep it up to date.
I will try packaging uv. Converted this PR to draft until this is all clarified.