Verify update packages with ECDSA signatures

[c-kr]

This PR is a feature proposal and a basis for discussion:

• Update packages are signed with ECDSA P-256 during the GitHub release workflow.
• Detached signatures are published alongside the corresponding update artifacts.
• The client verifies the signature before accepting and installing an update.
• The implementation is intentionally minimal on both sides: a small GitHub Action and lightweight client-side verification using only the Go standard library, with no additional dependencies and a low memory footprint.

Example action run with created .sig files: https://github.com/c-kr/snclient/actions/runs/29515430329

If the general concept looks good, it could be introduced in two phases:

1. Deploy only the signing step through the GitHub Action.
2. Add client-side signature verification in a later release once the signing workflow has proven reliable.

Before production deployment, the production key must be provided through the appropriate environment secret. The public key and its SHA fingerprint in the code must then be updated accordingly.

Assisted by: gpt-5.6-sol medium

[sni]

thanks, i will have a detailed look after the next release. I like the idea, from a quick look it doubles the artifact files and that folder already has quite a lot files and makes it even more confusing.
I need to think about it.

[c-kr]

Yes I had the same thought. This approach produces some non standard .sig files that can only be verified manually via a custom openssl command or within the inbuilt logic and that bloats the github release page and also leads to confusion.

Better would be standard gpg .asc files per release, but I did not find a native way of validating these in go.

If we stick to to format from this PR maybe we could write all validation files to a single manifest.sig file and extract from there. More code but less bloat for the release page.

But nothing that needs to be done immediately, lets thing about it after next release.

[sni]

right, i think this is way more common to have one manifest file containing checksums for the artifacts, then adding one signature for the manifest file.