You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pingora edge policy: 'dockerfile'/'containerfile' in RUNTIME_PATH_NAMES are unreachable, so the documented runtime-form guarantee overstates what is enforced #2210
RUNTIME_PATH_NAMES (scripts/ci/pingora_edge_policy.py:103) lists four names, but only two can ever match:
RUNTIME_PATH_NAMES=frozenset({"dockerfile", "containerfile", "nginx.conf", "nginx.service"})
...
iflower_nameinRUNTIME_PATH_NAMESand"nginx"inlower_name: # line 404return"nginx_runtime_artifact"
The second condition requires "nginx" in the file name, so dockerfile and containerfile are unreachable through this branch. Verified against current main (91be64429):
path
_runtime_path_rule
src/runtime/nginx.conf
nginx_runtime_artifact
local/nginx.conf
nginx_runtime_artifact
local/nginx.service
nginx_runtime_artifact
Dockerfile
None
local/Dockerfile
None
docs/Dockerfile
None
The other two branches do not rescue them either: one keys on "nginx" being a path component, the other on an nginx- name prefix.
Which reading is right is a scope decision, not mine to assume
Either is defensible and they need different fixes:
The module's subject really is only Nginx. Its own docstring says "active Nginx runtime artifacts", and the repository moved to Pingora, so container build files are out of scope. Then the two unreachable entries are dead configuration and should be deleted, because they currently read as a guarantee the scanner does not provide.
Container build files were meant to be caught too. Then line 404's and "nginx" in lower_name is the defect, and removing it turns the set into what its contents imply.
Why this matters now
I wrote the declared-artifact-paths change (#2193/#2194) and stated in its PR body and to a consuming session that "runtime forms (Dockerfile, nginx.conf, service units) are still rejected inside a declared prefix". The nginx half of that is true and I verified it (local/nginx.conf under a declared prefix still returns the rule). The Dockerfile half is not: this scanner never rejected Dockerfiles, inside or outside a declared prefix. I am correcting that claim here rather than leaving it standing, and I have told the consuming session.
No behaviour changed with #2194 — the unreachable entries predate it. This is a correction to the described guarantee plus a request to decide which of the two readings the policy intends.
Activity