add proposal for streamlined public identity

[getchoo]

this is a proposal to change up the public identity plan a fair bit. i won't be saying much about it here as i think i got most ideas already covered in the document itself

i would also like to say again: though i am a maintainer for prism launcher, these opinions are my own and are not indicative of prism declining to be a part of the current proposal. i am only speaking as myself here for an alternative i believe in

[Redblueflame]

So, I finally got the time to get to this, sorry for the delay '^^
Let's get started point by point:

Giving root trust to many organizations increases the risk of compromisation and misuse of keys

In any implementation this will be an issue. To validate signatures, you either have a truely de-centralized infrastructure (each user chooses who to trust based on connections) where it is bothersome to add a new modder, or you have centralized boards (modrinth / CF in your example), where the issue of trust arises again.

Proper review of mods should not be dependent on groups who are not active in or have expereience with reviewing and distributing mods

The objective of this working group is not to validate whether or not a mod is to be trusted (a certificate authority delivers keys, and never touches the artifact themselves) but instead authenticates a given modder, and allow to revoke that trust when the need arises.

The system is overly complicated

Sometimes, a more complicated solution, but where all the pieces have been field-tested is better than a custom-made one.

Too much control is bested in this organization

Then we are back to a PGP like solution, that has never taken off outside of select circles, mainly due to the difficulty of getting in with the decentralized aspect.

Proposed solutions

Mod platforms continue to be the ones reviewing and approving of mods

This will never stop happening. The objective is to prevent supply chain attacks, not ensure that mods are free of malware. A layered approach is way more powerful than a single point of failure, and the proposal allows to alleviate some of the issues.

Minisign

The issue with that solution is that the validation step is only done on the server-side, that cannot be easily user-validated. There's also the issue of revocation, and availability (we cannot block launches when modrinth is down for example)

Mods would be going unreviewed when signed

Agreed, and I should make this as clear as possible.

[znewman01]

Drive-by comment by someone with no skin in the game for the Minecraft community so feel free to ignore me :) I'm just a researcher interested in package repo security.

I'd encourage interested parties to check out the OpenSSF's Securing Software Repositories Working Group, as this is an organization aimed at solving many of the same problems as the MMPA, but in a way that's reusable across repositories.

---

I'm a little concerned that signing isn't sufficiently well-motivated to know how to make tradeoffs here.

The way I see it, signing for a software repo should have three things (somewhat intertwined):

1. Semantics/policy: what does it mean to sign for package foo?
2. Meta-policy: how do I figure out who is supposed to sign for package foo
3. PKI: if user-alice is the owner of package foo , how do I check that a signature is from user-alice?

Each aspect can be quite tricky. For instance, this PR has the operator of the software repo running the PKI. That means that a compromise of the repo itself would allow publishing malware. In that case, why have signing?

I have a preferred stack for addressing these three problems (by no means should you just adopt this stack without investigating further, but I do believe you want to address all three of these issues):

1. in-toto for semantics/policy: instead of "signing a package", entities sign an attestation about a package. So now you can express things like "package foo is good if user-alice signed the source and trusted-build-machine-1 claims they built package foo from that source". This plays nicely with the "reproducible builds" story that's also happening in that MMPA repo.
2. TUF for "meta-policy": one root of trust (which can involve a threshold of signers) delegates ownership of individual packages to different individual in-toto policies. TUF has a couple of nice bonus properties: it defends against a number of subtle attacks (like serving old metadata to make people install a since-yanked package) and it provides for delegations that can't be revoked by the repository itself (the actual security guarantee is a little more subtle, but basically you don't want the repo to be able to say "never mind user-alice, the owner of this package is now evil-hacker).
3. Sigstore for PKI. (An alternative is "no PKI": Sigstore/TUF delegate to public keys instead of identities. I actually don't like this, because developers (myself included) are terrible at managing these keys, and you wind up needing to be able to have the repo rotate keys, which attenuates some of the benefits of signing). Sigstore supports both human identities (Gmail account) and machine identities (GitHub Actions job).

These don't solve malware—an evil user can make a good signatures for a malware package. But you can fold in things like "malware scan attestations" and "reproducible build attestations" very easily.

[getchoo]

In any implementation this will be an issue. To validate signatures, you either have a truely de-centralized infrastructure (each user chooses who to trust based on connections) where it is bothersome to add a new modder, or you have centralized boards (modrinth / CF in your example), where the issue of trust arises again.

i don't see how decentralized infrastructure makes it very bothersome to add a new modder, especially compared to the current proposal. the most you would have to do is add it to a db to some kind, which could just be done by the modder; this is in comparison to a system much more bothersome for the modder themselves to go to a group and wait to get verified, along with more work being put on members of organizations to actually review each mod developer. for modrinth/cf - like i said in the proposal - are already trusted enough to be the primary distributor of mods. letting them verify mods sever side, while also providing public keys for individuals or launchers to verify, would not be putting much more trust in them imo

The objective of this working group is not to validate whether or not a mod is to be trusted (a certificate authority delivers keys, and never touches the artifact themselves) but instead authenticates a given modder, and allow to revoke that trust when the need arises.

this was due to a bit of confusion, which was thankfully cleared up in another pr. however, i would still argue that one group "authenticating" a modder wouldn't do much more than say, linking a github account to an already existing modrinth/cf account, or using a service such as keyoxide - though, both of these solutions fall to the pgp key signing party problem where you can't be 100% sure without actually meeting the person, but obviously it's the best we can do /shrug

Sometimes, a more complicated solution, but where all the pieces have been field-tested is better than a custom-made one.

technologies such as minisign have been field tested, along with the general concept of uploading a public key to verify other uploaded content server side (see the site we're using right now)

Then we are back to a PGP like solution, that has never taken off outside of select circles, mainly due to the difficulty of getting in with the decentralized aspect.

would "select circles" be most of the foss community? nearly every linux distribution including enterprise? pgp never failed to take off because of it being decentralized (modern solutions like i have mentioned have gone a long way to prove this), it failed because it's grossly overcomplicated, especially to your average person. i believe the same thing can be said of centralized CAs here, which also haven't really taken off outside of enterprise for similar reasons

The issue with that solution is that the validation step is only done on the server-side, that cannot be easily user-validated. There's also the issue of revocation, and availability (we cannot block launches when modrinth is down for example)

minisign (and similar solutions) do not make it hard to validate mods as a user; all you need is a public key. this could easily be hosted on websites, similar to how it is on github. a good example would be if i sign a commit with my ssh key, someone else could go to https://github.com/getchoo.keys, grab my public key, and verify it. there's nothing very complicated about this

revocation is an issue, but i wouldn't say it's exclusive to cf/modrinth. the CRLs for TR's and CA's could also go down, and risk revocations not being used for affected certificates after all. furthermore, making a small, separate infrastructure could also reduce the likelihood of this issue drastically, along with launchers making sure mods are signed when downloaded so in the event of cf/modrinth going down, there's a very high chance all locally downloaded mods were verified.

[getchoo]

Each aspect can be quite tricky. For instance, this PR has the operator of the software repo running the PKI. That means that a compromise of the repo itself would allow publishing malware. In that case, why have signing?

this is a good point. i disagree that signing would be worthless in the event a repo is compromised, since individual modders would hopefully have their keys available externally (which would prevent say, a fake key being presented to users from a compromised repo) and if the risk is manageable for some of the biggest software repos on the planet (such as rhel, debian, gentoo, etc), i think it would be fine here. overall though, i probably pushed the example of cf/modrinth too much. my main issue is just having a bit of barrier to actually getting a key - especially when it's under the scrutiny of individuals where accountability can be made difficult - since just having these services manage them wouldn't be the only way to solve that, and something external could bring a lot more benefits

1. in-toto for semantics/policy: instead of "signing a package", entities sign an attestation about a package. So now you can express things like "package foo is good if user-alice signed the source and trusted-build-machine-1 claims they built package foo from that source". This plays nicely with the "reproducible builds" story that's also happening in that MMPA repo.
2. TUF for "meta-policy": one root of trust (which can involve a threshold of signers) delegates ownership of individual packages to different individual in-toto policies. TUF has a couple of nice bonus properties: it defends against a number of subtle attacks (like serving old metadata to make people install a since-yanked package) and it provides for delegations that can't be revoked by the repository itself (the actual security guarantee is a little more subtle, but basically you don't want the repo to be able to say "never mind user-alice, the owner of this package is now evil-hacker).
3. Sigstore for PKI. (An alternative is "no PKI": Sigstore/TUF delegate to public keys instead of identities. I actually don't like this, because developers (myself included) are terrible at managing these keys, and you wind up needing to be able to have the repo rotate keys, which attenuates some of the benefits of signing). Sigstore supports both human identities (Gmail account) and machine identities (GitHub Actions job).

i had actually mentioned sigstore as an alternative privately with some friends, and i can't believe i forgot to put it here! anyways, out of these, i'm most familiar with sigstore, so here i might pick your brain a bit on the first two. from what i've read, sigstore integrates a lot of similar principals as TUF with cosign, and since that's already used in a lot of places, i think it might be better to use that than integrate them separately. cosign/sigstore could also solve some of the aforementioned issues where developers can have more control of their keys + have less of a barrier to entry, as it's from a neutral third party, uses a simple openid login and, and mostly self managed (be it ephemeral or with a traditional public/private key setup). it's also more likely developers would at least know of it given it's wide usage, and it could throw worries of revocation out the window with such short lived certs.

the only thing i am a bit confused about here is with in-toto since i haven't heard of at all up until this point. i feel like that with sigstore could introduce a bit more complexity than needed, but i'm probably missing something so maybe a more indepth explanation of it could help :)
from a first glance though, it doesn't look too bad. a lot of it could be automated with scripts and the templates other working groups are creating, so i would be more than open to adding it with a bit more information (the docs are a little...iffy)

and before i forget, thanks! this is honestly great input and i'll be adding chunks of it into this soon 👍🏻

[znewman01]

i disagree that signing would be worthless in the event a repo is compromised, since individual modders would hopefully have their keys available externally (which would prevent say, a fake key being presented to users from a compromised repo)

This relies on verifiers knowing to go check those keys from e.g. github.com/foo-user.keys though—so now GitHub is part of your PKI (not necessarily a bad thing, but needs to be called out explicitly).

My point here is mostly that teasing out (1) foo-user signs package bar from (2) how do I check for a signature from foo-user is useful for thinking through all these cases.

and if the risk is manageable for some of the biggest software repos on the planet (such as rhel, debian, gentoo, etc), i think it would be fine here.

My personal mission is to make it so that those repos no longer have those kinds of single-points-of-failure 🙂 but I take your point—it's all a tradeoff. I still think articulating what benefit you're getting out of signing will make the case more compelling.

my main issue is just having a bit of barrier to actually getting a key - especially when it's under the scrutiny of individuals where accountability can be made difficult - since just having these services manage them wouldn't be the only way to solve that, and something external could bring a lot more benefits

Warning: opinion ahead. I think I mostly agree, though.

I think that for a software signing system to be successful, the following must be true:

1. It should be invisible to end-users. That is, they shouldn't notice it unless there's an attack and it says "couldn't verify package."
2. It should be almost-unnoticable to developers. Developers maybe need to do some setup as part of registering a package, and tap a smart-card everytime they publish, but that should be it.
3. Recovery should be possible, but secure: developers will lose keys, so plan for that (and have good backups). It's subtle to do this in a way that doesn't give some support desk the ability to take over any account.

The only way to achieve this IMO is with really good tooling. A lot of software repos have package managers that can handle almost every aspect of signing and verification.

from what i've read, sigstore integrates a lot of similar principals as TUF with cosign, and since that's already used in a lot of places, i think it might be better to use that than integrate them separately.

Yup! The project hasn't been terribly clear about some of its terms, so for posterity:

• Sigstore: the umbrella project
• Cosign: the Sigstore "Swiss army knife." It was originally supposed to be an OCI container-focused signing/verification tool, but now signs arbitrary blobs.
• Ephemeral ("keyless") signing: issuing certs to link signatures to authentication events (like OIDC logins) so you can "sign with your example.com account."

Sigstore uses a TUF repo to distribute its root key material used to verify signatures.

cosign/sigstore could also solve some of the aforementioned issues where developers can have more control of their keys + have less of a barrier to entry, as it's from a neutral third party, uses a simple openid login and, and mostly self managed (be it ephemeral or with a traditional public/private key setup).

I really like this for reducing the burden of key management for developers 👍

it's also more likely developers would at least know of it given it's wide usage, and it could throw worries of revocation out the window with such short lived certs.

Kind of—you have to worry about revocation at a few levels:

1. What if Sigstore is compromised? Sigstore's use of TUF to distribute its top-level key material allows for revocation at that level. It can even have associated time intervals to say "stop trusting certs from this CA after time T."
2. What if the key used for signing is compromised? Doesn't matter in Sigstore, as the cert will probably have already expired!
3. What if the account used to sign the key is compromised? You still have to worry about this—I consider it a question of policy. So instead of saying "trust [email protected] to sign package bar" you say "trust [email protected]to sign packagebar` except from time T to time T'."

the only thing i am a bit confused about here is with in-toto since i haven't heard of at all up until this point.

The motivation for in-toto is basically: what does it mean to sign a package? In a typical software signing scheme, a signature over an artifact means, roughly, "I say this artifact is good."

What does "good" mean? If it's a binary release, I probably didn't hexdump the binary and inspect every byte. So I'm saying something like "the source is good (maybe I wrote it? maybe I reviewed it?) and I built it on my laptop."

in-toto is about teasing apart the meanings here. So instead of signing the software, I sign statements about the software. Then, I need a language for saying what combinations of statements from what parties I require. So something like: package bar is good if [email protected] signs a claim that they wrote the source @ SHA256:abcdef, and GitHub Actions signs a claim that they built package bar from source @ SHA256:abcdef.

in-toto provides layouts—what combinations of statements are required—and data formats for writing and signing these statements.

i feel like that with sigstore could introduce a bit more complexity than needed, but i'm probably missing something so maybe a more indepth explanation of it could help :)

IMO it's all about tradeoffs. I think on first glance just using minisign is the simplest solution. But it starts to hide a bunch of complexity: who is trusted to sign what packages? how do I kick someone out of a project?

The "complex" solutions are complex because they force you to answer these questions.

from a first glance though, it doesn't look too bad. a lot of it could be automated with scripts and the templates other working groups are creating, so i would be more than open to adding it with a bit more information (the docs are a little...iffy)

That's the hope—that tools and scripts can abstract the complexity from developers producing signatures and end-users verifying them.

and before i forget, thanks! this is honestly great input and i'll be adding chunks of it into this soon 👍🏻

Glad it was helpful! You also managed to nerd-snipe me right before my weekend so enjoy an extra text dump 😄