Class UpdateSignature
- Namespace
- McServerLauncher.Services
- Assembly
- McServerLauncher.dll
Checks that an update package was signed by whoever publishes this project, with a key that does not live on GitHub — and that the signature is for this version of this package.
public static class UpdateSignature- Inheritance
-
UpdateSignature
- Inherited Members
Remarks
The checksum next to a package comes from the same release as the package, so it only catches a damaged download: whoever can upload the one can upload the other. This is the half that does not depend on GitHub being safe. The private key stays on the maintainer's machine; what is here is only the public half, and a package without a signature made by it is not installed.
What is signed is not the package alone but a short message that also names the version and the file (see SignedMessage(string, string, string)). Signing only the bytes would leave an old release, signed correctly in its day, valid for ever: somebody able to publish could offer it again under a newer tag, and it would pass. With the version inside the message, the signature of 1.21.1 does not verify as 1.99.0, and the .dmg's does not verify as the .exe's.
ECDSA over P-256 with SHA-256, because it is what .NET ships (so the update path pulls in no
package of its own) and what openssl produces. The .sig2 asset is the DER signature,
written in base64 so it is plain text.
Several keys are trusted at once so one can be replaced without stranding anyone: a release
signed with the new key ships in an app that already trusts it, and the old key is dropped a
version later. See docs/articles/signing.md.
Methods
Verify(string, string, string, string?, IEnumerable<string>?)
Whether signatureBase64 is a valid signature, by any of
keys (the built-in ones by default), of the file at
packagePath as version's fileName.
public static bool Verify(string packagePath, string version, string fileName, string? signatureBase64, IEnumerable<string>? keys = null)Parameters
Returns
Remarks
Anything wrong with the input — bad base64, a signature of the wrong shape, a key that is not P-256 — is "not valid", never an exception: the caller's answer is the same either way, and a crash here would be a way to skip the check by feeding it garbage.