> My concern about regexps is that it's hard to move back
> once it's in production.

> Let's say we add the fix with the regexps now and release
> a version of kata with the fix. Once it's done there's no
> way to move back to block regexps without breaking
> compatibility with a previous release version. However,
> if we don't take this approach, we can add it later without
> any issue.

The concern is legitimate. However, let's consider two worlds.

In world A, someone actually uses annotations in production today with unpredictable values, e.g. /build/qemu-$DATE for hypervisor.path.

In world B, people use annotations with a small set of values that can be predicted ahead of time, e.g. /usr/bin/qemu and /opt/kata/bin/qemu

In world C, nobody uses annotations


My worldview right now is we don't know if we are in world A, B or C. Maybe someone else does know, that would easily change my mind on what the correct fix is.

Now, we submit a fix. We have four approaches so far, that I will call P, P', F and D:
P : We whitelist annotations with a flag that whitelists everything
P': We whitelist annotations names
F : We whitelist annotations values with strings
D : We whitelist annotations values with regexps

I hope that I represented our respective positions correctly.

Now, my question is: what do we recommend to users once the fix is deployed. How do we write the release note?

P only works for world C. If we are in world A and B, your release note reads like: "If you are using annotations today, then set enable_annotations to true, but please be mindful that this will allow any user to remotely execute any pre-existing binary on your host." To me, it's a no-brainer that we would have to walk back this one pretty quickly if we are in world

P' is only marginally better. In world A and B, the release note now reads like: "If you are using annotations today, then set enable_annotations = [ "hypervisor.path" ], but please be mindful that this will allow any user to remotely execute any pre-existing binary on your host.". Again, it's a no-brainer that we will have to walk this one back quickly if we happen to be in world A or B.

F works for world B and C. However, if there is a chance we are in world A, then the release note must read: "If you are in case C, this feature has been disabled, sorry". It's not nearly as bad as cases P and P', but it's still a loss of functionality that I don't know how to evaluate.

D works for world A, B and C. The release note reads: "If you need annotations in case B, then whitelist the binaries with [hypervisor] path_list = [ "/path/a", "/path/b" ]. If you need annotations in case A, then whitelist the binaries with [hypervisor] path_list = [ "/most-restrictive-path-regexp" ] but please read the SECURITY WARNING section carefully as you may open your host to binary execution attack with an improperly chosen pattern."

Now, if after discussing with the list, we realize that we are in world B, then walking back the fix is not a problem. If, however, it would be difficult to walk it back, then it means that we are actually in world A, in which case walking it back would be a net loss in functionality.

I understand that my hypothesis that world A may be the one we are in is based on no data at all, it's just a risk analysis. If you can convince me that we are in world B, then approach F is less risky. If you can convince me that we are in world C, then approach P is better since it is indeed simpler.

I hope that I correctly summarized the discussion so far.