Signed Releases

[StandingPadAnimations]

Some addons like MCprep Kaion have signed releases as an added security measure. It would be nice if these signatures could be checked and verified.

Most of the time GPG is used to sign the releases, so this would mean an extra Python module has to be installed by the addon (at least from my quick google searching), so perhaps this could be something optional so developers wouldn't have to forcefully installing extra packages

[StandingPadAnimations]

Here's an MCprep Kaion release as an example: https://github.com/StandingPadAnimations/MCprep-Kaion/releases/tag/3.4.1.3

We use a separate file with the signature, and have GPG compare it with the original file to verify the original has not been edited with the command gpg --verify Signature-MCprep_addon.sig MCprep_addon.zip. Specifically we used a detached signature (Of course this is just one way, but it is the most common for space reasons. A normal signature would copy and compress the data in the signature file itself, whereas a detached signature doesn't copy and compress the data). More info can be found on the GPG website

If I run GPG in the command line (using MCprep Kaion as an example), I get the following output:

$ gpg --verify Signature-MCprep_addon.sig MCprep_addon.zip
gpg: Signature made Wed 08 Feb 2023 05:43:53 PM CST
gpg:                using RSA key 7F6A0E6FA332BAD0EC9E76B383C7F596A88BE583
gpg: Good signature from "Mahid Sheikh <[email protected]>" [ultimate]

Here GPG verified the signature is good, which means the file wasn't tampered with. If I download the previous release and then compare, I get the following:

$ gpg --verify Signature-MCprep_addon.sig MCprep_addon.zip
gpg: Signature made Wed 08 Feb 2023 05:43:53 PM CST
gpg:                using RSA key 7F6A0E6FA332BAD0EC9E76B383C7F596A88BE583
gpg: BAD signature from "Mahid Sheikh <[email protected]>" [ultimate]

Since the zip file is different from the zip file used to make the signature, GPG considers it modified and thus says the signature is invalid.

[TheDuckCow]

Thanks for starting this topic thread, and I agree it's an important one to put some attention too. It is certainly a risk that a bad actor could take over a github account and compromise people's systems by putting bad code into a release build that people then get notified to one-click update.

I suppose a key question on the breakdown of where things can go wrong, and how those surface areas for attacks can be reduced. In this particular case, what is GPG signing for solving? If bad actor is able to change the zip on github for downloaded, they are just as easily able to update the signing too right (albeit, it's a fair extra step they'd have to go through). Other question is on where gpg is supported, would this create compatibility issues.

Now to be clear, I'm all for incremental improvements even if bigger issues still remain to be solved. Just want to first understand how the sequence would work in practice if we were to adopt this feature option. Curious to hear back @StandingPadAnimations! And thanks again for opening this topic

[StandingPadAnimations]

what is GPG signing for solving? If bad actor is able to change the zip on github for downloaded, they are just as easily able to update the signing too right (albeit, it's a fair extra step they'd have to go through).

A bad actor would have to make a new key, with its own public and private key pair. Sure, they could change the public key in future releases, but not for previous releases (at least not in an effective way). In this case, previous releases would fail to update, since the signatures would not match.

If for example my account were to get hacked, and the hacker made a new key pair, then (assuming there's a signature check) previous releases would fail to update, as they would check if new versions are signed with a specific key or not. They would have to convince users to manually update and ignore any warnings the updater might give regarding security. While some users may fall for this, the vast majority would most likely feel uncomfortable with ignoring a security warning.

In addition, the key check isn't just important for hacked accounts, it's important to verify that the release truly came from Github/Gitlab/whatever, and not some different source pretending to be Github.

Other question is on where gpg is supported, would this create compatibility issues.

GPG is preinstalled on most Linux systems, but is also supported on MacOS and Windows.

[TheDuckCow]

Thanks for sharing that. This Signature-MCprep_addon.sig, this ships with the addon right? And would need to remain the same for all builds, or if it were ever updated, all existing installs would not be able to fetch new releases? Though I suppose in that scenario, if you know you need to transition to a new key, you could have one build which is zipped and signed using the old key, but containing the .sig of the new key. Let me know if I got this right. Just noting I'm wearing of inadvertently cutting off the entire updating system from working, but if someone signs up to using signing, I suppose they should understand these potential consequences anyways.

For this to work, would an addon developer need to then package a copy of GPG binaries (since it's not installed, only supported, on MacOS and Windows)? That also introduces a decent chunk of complexity, needing to package an executable (or telling developers how to package it, if it's an optional functionality we don't force all users of this repo to leverage).

[StandingPadAnimations]

Thanks for sharing that. This Signature-MCprep_addon.sig, this ships with the addon right? And would need to remain the same for all builds, or if it were ever updated, all existing installs would not be able to fetch new releases?

The actual file changes with each release (since the contents of the zip file change) but it's signed with the same key

For this to work, would an addon developer need to then package a copy of GPG binaries (since it's not installed, only supported, on MacOS and Windows)?

There is a Python module that does this, but looking into it further it does require the binaries to be installed, so I'll have to see if there's a way to verify signatures without shipping binaries