RPM signing in SDK3.5

In the SDK3.5 announcement RPM signing was mentioned as a new feature.

Is this

a) proper code signing like Windows with a traceable certificate, where the signature is actually checked by the system automatically?

or

b) is it the (totally useless) gpg signature using a key you made up, that no one will ever bother to manually check?

If (A) is there any information on how to do it?

I don’t really understand how do you came to the conclusion that a particular type of signature would imply the need for manual checking, especially when you are talking about GPG, the de facto standard for securing software distribution in the Linux world. The only option I see is to attribute this to a lack of understanding to the issue of securing software distribution in general, which is well covered with countless resources freely available on the web, so I will left that part open and directly jump to the how-to.

Inside Sailfish IDE, package signing may be enabled with Projects → Build → Sailfish SDK Settings → Sign packages. The initial setting can be changed globally under Options → Sailfish OS → General → RPM Signing with GnuPG.

With sfdk, the CLI tool, package signing may be enabled with the --sign switch to either the build or package command. Check the “SIGNING PACKAGES” section of sfdk --help-building to learn how to choose the signing identity.

As a side note on signature verification on Sailfish OS side, trusted keys may be imported with the standard rpmkeys command. It is on the roadmap to enable RPM key management from the Settings application.

4 Likes

I’ll be using the same pgp key that I encrypt mail with. my personal key. that doesn’t, of course work with all project types and some people are sloppy, but still gnupg does the job.

And Windows and proper in the same sentence? Which CA is responsible? Do you trust the PKI at Microsoft ( I don’t!).

In my case, the pubkey, once I’ve started using it here, will be tied to my person.

Well, the best practise is to create a different sub-key (pair) for every purpose. Many people even create different sub-keys for email signing and email enryption, though others argue this is nitpicking.
While all these schemes work technically (including the simple approach “one key pair for everything”), using different sub-keys is much more resilient against failures / compromises and fat-fingering, plus eases key changes a lot.

Proper signing in Windows, like this? That’s an outlier, but still.

PGP or X.509, I don’t really mind. For cases like this, I think it’s more about store apps that can validate downloads, and stores that can validate submissions to said store.

I’m aiming for ease of use for the recipient. If the pub key is signed, web of trust style, it becomes a bit difficult to see, who is who in the zoo with sub-keys. But I haven’t gotten the key cross-signed by anyone yet so it’s all open.