Cosigned policies interpreted as regex by default

[znewman01]

Unrelated to this PR but it's a regex??? That's a surprise

Does this open up an attack where someone passes zjn@mail.example.com and I go register mailqexample.com and can pass the check?

Originally posted by @znewman01 in #1869 (comment)

I don't think this is necessarily a problem except users shouldn't be surprised by it or do the wrong thing by default. So maybe: make it loudly warn, or make regex behavior configurable? Or support globs instead?

[znewman01]

CC @vaikas

[hectorj2f]

@znewman01 i am working on using globing and remove regex from the image pattern. There is already an issue

[znewman01]

I see #1834...I'm not convinced that this is a dupe, it seems to be a different regex unless I'm misunderstanding something. Would that change make it so that an escaping step happens before we compile it as a regex in verify.go?

[hectorj2f]

@znewman01 You are right! It is related to https://github.com/sigstore/cosign/blob/main/pkg/apis/cosigned/v1alpha1/clusterimagepolicy_validation.go#L200. For a moment, i believed it was related to #1834.

[hectorj2f]

@znewman01 @vaikas Should the subject be a non-regexp instead ? Or you can see use cases here. If so, i am wondering if we should do the same for issuer.

[znewman01]

My main concern is that users will accidentally enter something like an email (including .) which will then be validated in a surprising way.

I'm okay with users being able to specify a regex, and it seems useful. Maybe if it's opt-in? Or really obvious (users have to type r"foo@example.com" or similar)? I'm not 100% familiar with the context.

[vaikas]

Ok. How do folks feel if for v1beta1, we add something like a prefix, r: that indicates it's an regex? It's a bit goofy I suppose, but thoughts?

[znewman01]

How do folks feel if for v1beta1, we add something like a prefix, r: that indicates it's an regex? It's a bit goofy I suppose, but thoughts?

I have one escaping concern long-term: r:foo@example.com is a valid email. Though I suppose you could do r:r:foo@example\.com—still the same problem of "now r:foo@example.com accidentally matches foo@example.com. My preference is always going to be to fix this "at the type level".

But yeah something like that would be fine for v1beta1 :)

[hectorj2f]

Yeah, let's solve it for v1beta1.

[vaikas]

Just bringing this back. So, I think we have couple of options (I'm sure I missed some), but I think I'd rather tackle this hopefully in a more 'final' form sooner rather than later.
Here's few options:

• Use a re: or some other prefix on the string
• Create a 'flag' on the Identity that controls whether fields are interpreted as RE or not
• Add SubjectRE and IssuerRE as parallel fields to Subject/Issuer so it's crystal clear that the user is wanting the RE

As I said I'm sure there are others, but I think I kind of like the last option for clarity and therefore no confusion on it.
@znewman01 @hectorj2f Thoughts?

And of course, the last option is that we do not allow any regexp at all, but I think it's useful. Maybe I'm wrong :)

[znewman01]

Just bringing this back. So, I think we have couple of options (I'm sure I missed some), but I think I'd rather tackle this hopefully in a more 'final' form sooner rather than later. Here's few options:

• Use a re: or some other prefix on the string
  I can live with this, but what if my email is "re:foo@example.com"?
• Create a 'flag' on the Identity that controls whether fields are interpreted as RE or not
  Kinda awkward
• Add SubjectRE and IssuerRE as parallel fields to Subject/Issuer so it's crystal clear that the user is wanting the RE
  SGTM, this is my favorite. Just need to document what happens if both are provided

As I said I'm sure there are others, but I think I kind of like the last option for clarity and therefore no confusion on it. @znewman01 @hectorj2f Thoughts?

And of course, the last option is that we do not allow any regexp at all, but I think it's useful. Maybe I'm wrong :)

I agree it would be useful!

[hectorj2f]

I definitely agree it is useful, I am just concerned about the prefix re: but I don't have a better proposal.