Optional signature verification

[3TUSK]

We migrated from our home-brewed mod-updater to packwiz-installer for our new iteration of online convention event this year.

Everything works as expected, except one feature missing: mandatory PGP signature verification.

As some background information: ever since 2020 when we started our convention event, we requires all submitted mods to be built on our own. Since 2021, we streamlined this process by leveraging GitHub Actions, and added a signing step after build, so that everyone with correct tooling can verify that those jars are from us.
To make the verification easier, as well as to make mod updates faster, I rolled out the said home-brewed mod-updater. From a high-level point of view, this home-brewed updater:

1. Fetch PGP public key with specific ID/fingerprint from key servers;
2. Download mod list from given URL;
3. Download mods and their detached signatures according to the mod list;
4. Do the signature verification; refuse to load the mod if signature verification fails, and give clear error message in logs.

This home-brewed updater has many flaws, however; I will not list them here to make this ticket less wordy. To address these flaws, we decided to drop our own tooling entirely in favor or packwiz, which, according to our initial testing earlier this year, is satisfactory.

... except the absence of PGP signature verification. Whilst in the last two years, we did not suffer from incidents akin to the Fractureiser, the Fractureiser incident itself is nonetheless a reminder that we need some kind of defense.

Therefore, I am writing this ticket to request such a feature. There are at least two ways to approach this, however:

1. Verify executables (i.e. mod jars) only.
2. Verify everything, from jars to tweak scripts to plain-text config files.

I anticipate that both approaches involve changes to the existing packwiz format. Also, it is also worth noting that, the signature does not have to be PGP. We chose PGP because it was probably the most obvious choice when we were thinking about authenticity check.

Signature verification should be optional - that is, if a pack creator does not want to use it, the workflow is the same as what we have now; however, if a pack creator enables signature verification, the pack update should fail when signature verification fails.
Further, if a file does not have its accompanying detached signature, either the installer should skip verification for that file, or give some sort of warning about the absence of signature.

[comp500]

Git already has PGP signing for repositories - that could be integrated once Git support is implemented, and would allow signing the entire contents of the repo. Of course, this wouldn't be able to verify the PGP signatures of files packwiz-installer itself downloads, but you could implement signature verification when you create the pack and have everyone trust that you verified those files, without any extensions to the actual packwiz format (as the hashes ensure that the files you verified haven't been tampered with).

Reducing points of compromise is beneficial to security though, so verifying signatures in packwiz-installer seems like a good idea particularly if you want to link the trust to the original authors/builders of JARs. The following are my main concerns:

• How large would a PGP library be - would it add significant bulk to the install size of packwiz-installer?
  • Would a different signing mechanism be better for a lightweight install, assuming the PKI/trust infrastructure that is used works with it?
• How would the signatures themselves be transmitted - a detached signature file? part of the .pw.toml? retrieved from an external server?
• Should the packwiz CLI obtain these signatures, and if so how?
• Who keeps track of which keys/certificates are valid, and who should be allowed to sign JARs? (i.e. key servers)
  • This looks like a problem the MMPA is trying to solve...
• (possibly out of scope for this issue since such a filter could be useful without PGP) If an external authority provides certification to validate that executable files are "safe", how does packwiz-installer determine which files are "possibly dangerous" and require a signature from the authority?
  • For the most part this would be solved with a .jar filter, but some mods might use native code or unsandboxed scripting that could be modified by a malicious modpack

[3TUSK]

I will give my perspective on these concerns based on my/our experiences.

How large would a PGP library be

We used BouncyCastle to implement PGP verification. The jar is fairly large, though (~6 MiB). Using shadow with minimization may reduce the size, but we didn't try that before we dropped the project as a whole.

How would the signatures themselves be transmitted

For us, signatures were shipped separately.
In fact, our convention was to put them at the same location. For example: if a mod jar is at https://example.com/foo.jar, then we provide its signature at https://example.com/foo.jar.asc.
Out old tooling only asks for a URL pointing to the signature.

Should the packwiz CLI obtain these signatures, and if so how?

I personally think only packwiz-installer should care about signatures. However, that leaves a question of "where should packwiz CLI obtain those URLs to signatures when serving the pack". Honestly speaking, I ran out of ideas on this one. Unless major players in mod hosting (namely CurseForge and Modrinth) will provide some conventions regarding this.

It may be a good idea to allow packwiz CLI to generate these signatures (either through BouncyCastle, or invoking gpg installed on the OS) when serving the pack.

Who keeps track of which keys/certificates are valid, and who should be allowed to sign JARs? (i.e. key servers)

As online convention organizers, there is only one source of mods: us the organizers. Thus, in our specific case, only we were signing the mods.
We disclose our public key information through our community spaces, and we upload our public key to two key servers:

• https://keyserver.ubuntu.com/pks/lookup?search=contact%40teacon.org&fingerprint=on&op=index
• https://pgp.mit.edu/pks/lookup?op=vindex&search=0xC953B268F78463CE

Visitors/players to our event only need to pay attention to this specific key.

Of course, this setup won't work well when a lot of people start to signing things… I would leave this question to MMPA as well.

how does packwiz-installer determine which files are "possibly dangerous" and require a signature from the authority?

To me, it sounds like another topic that should be left to MMPA. Valid signature is not a sign of safety, only authenticity.

For we the event organizers, we only need to audit all the mods we used in the convention. With audit, we assure our visitors/players that, if you have this jar, and the signature shows that this jar is from us, then it is safe to use; if a vulnerability is discovered at a later time, a valid signature will hold us responsible.
Still, audit is unrelated to signing. It is antivirus software's, or otherwise dedicated malware scanner's job to determine if a jar is "possibly dangerous". Certainly, a malware dev can sign malware.

[3TUSK]

A follow-up:

Who keeps track of which keys/certificates are valid, and who should be allowed to sign JARs? (i.e. key servers)

MMPA has decided that P2I approach was not worth collaborating.

Do note that PGP does not require a P2I, though. PGP can operate on the Web of Trust, but that also requires effort.