We currently allow any verified email address to sign a gem, which means that anyone may sign any gem. At signature verification time, a gem consumer would reasonably only consider signatures from actual maintainers (see #58).
In the future, we may support different kinds of signatures (I build this gem, I reviewed it, I tested it, etc.), and those attestation types would appear as part of the signature (i.e., the Rekor log entry). Since we're only using basic rekords for now, with no additional fields, we can't really qualify signatures.
Let's look at what email was used to authenticate the signer, and reference it against the list of emails in the gemspec. If it's not listed (emails field?), then don't bother acquiring a fulcio certificate.
The two OpenID implementations produce an access token, and this token contains an email field. It may make sense to make this check as part of the GemSigner bit, before we call Fulcio.
We currently allow any verified email address to sign a gem, which means that anyone may sign any gem. At signature verification time, a gem consumer would reasonably only consider signatures from actual maintainers (see #58).
In the future, we may support different kinds of signatures (I build this gem, I reviewed it, I tested it, etc.), and those attestation types would appear as part of the signature (i.e., the Rekor log entry). Since we're only using basic rekords for now, with no additional fields, we can't really qualify signatures.
Let's look at what email was used to authenticate the signer, and reference it against the list of emails in the gemspec. If it's not listed (
emailsfield?), then don't bother acquiring a fulcio certificate.The two OpenID implementations produce an access token, and this token contains an email field. It may make sense to make this check as part of the GemSigner bit, before we call Fulcio.