[Bug] GPG verification fails

[craigraw]

I've tried verifying the download by downloading the following files:

krux-v23.09.1.zip
krux-v23.09.1.zip.sha256.txt
krux-v23.09.1.zip.sig

On MacOS, running gpg --verify krux-v23.09.1.zip.sig krux-v23.09.1.zip.sha256.txt gives me:

gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.

The manifest also seems to be non-standard, missing the filename of the file being hashed.

[odudex]

Please download Selfcustody's openssl public key:
You can then verify the signature using openssl:
openssl sha256 <krux-v23.09.1.zip -binary | openssl pkeyutl -verify -pubin -inkey selfcustody.pem -sigfile krux-v23.09.1.zip.sig

We use openssl for signatures because this way we can sign releases and binary files in a airgapped workflow, using a Krux device to sign, with a BIP39 mnemonic key.
The same type of signatures are also used to perform airgapped firmware updates on devices. We move a binary and its respective signature to a SD card and Krux will check the signature to allow the update.

For next releases I will add the filename to the txt hash file.

[odudex]

I hope you have(edit) an Amigo with you. Here are some other info that might be relevant:
Flashing from MacOS can be tricky, some users reported they had to use a USB dock for the driver be able to detect the device.
Unfortunately non of us have an Apple device to improve the flashing tools.
Recently created features, like signing messages from Sparrow at a derived address, are not available on the official release yet. I have it working on beta only. I'm working on tests and docs to make a new release with them ASAP.

[craigraw]

We use openssl for signatures because this way we can sign releases and binary files in a airgapped workflow, using a Krux device to sign, with a BIP39 mnemonic key.

Although of course you are free to sign releases in any way you want (and I understand the requirement for on-device verification), I would encourage you to sign in the same way that all other Bitcoin-related software projects do, using GPG. Getting users to verify downloads is already difficult - using a non-standard verification process is going to make things that much harder. This could be done in addition to the openssl method.

I think your second reply here was intended for another issue.

[odudex]

I'll discuss with other contributors the idea of creating (and managing) a PGP key and using it to sign release packages and other apps we may eventually release.
I agree PGP is the standard, but as you may wonder, we love QR code airgapped signatures.

The second reply was for you, I thought you could be in the process of flashing a Krux device. Please ignore it if it's not the case.