Export BuiltinDefaultPolicyPath

[rhatdan]

This field is duplicated in containers/common/pkg/config and is being vendored into bindings, just because it is not exported from containers/image.

[rhatdan]

@mtrmac @Luap99 PTAL

[Luap99]

LGTM

[mtrmac]

NAK; if the goal is to handle #1726 , this is going in the wrong direction, motivating users even more to hard-code specifics of the logic (in this case, exporting the system-wide path motivates users to reimplement the per-user path).

If c/common intends to use the c/image default, it should not be setting the path in SystemContext at all, and the whole need for this goes away. (That can’t immediately happen because the two implementations have already diverged. Also maybe c/image needs some special knowledge of rootless operations .)

---

There is pkg/trust, which writes to the config files, and that one really needs to know a path, not a policy accessor. So c/image should probably export something — but it wouldn’t be systemDefaultPolicyPath; it would be defaultPolicyPath or maybe a separate “system-wide primary policy config path” / “per-user primary config path”.

[rhatdan]

Well how do we move forward on that then?

[mtrmac]

I don’t immediately know; the way the code has already diverged, maybe there is some neat elegant solution which is compatible enough, maybe we will have to live with a gross hack forever. Someone needs to figure that out.

---

For the purpose of trimming containers/podman#23857 (comment) , the bindings should not be including the whole implementation in pkg/trust in the first place; AFAICS they just need the trust.Policy data type. That can either be split into a subpackage; or the domain/entities/types subpackage could define a separate RPC-only type, separate from the implementation type; or maybe pkg/trust should be importing the type from domain/entities/types — I don’t know what is the general Podman approach to RPC-only types duplicated with implementation types, vs. sharing the two, and where the definitions live.