Expose the view table and the visibility rule on Authentication

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[augmentcode]

🤖 Augment PR Summary

Summary: This PR exposes the serialized authentication view table and its path-visibility rule through the public API.

Changes:

• Adds RecordedView, view_count(), and view_at() so callers can enumerate artifact-recorded views.
• Adds visible(path, view) to determine whether a build view should include a registry path.
• Implements the APIs for both enterprise and community editions.
• Reads enterprise view names and policy masks directly from the memory-mapped authentication artifact.
• Uses the existing path-policy matcher so ungoverned paths remain visible to every view.
• Adds unit coverage for table ordering, masks, and visibility combinations.

Technical Notes: Enterprise visibility is based on overlap between the path's governing-policy mask and the recorded view's policy mask; the community edition always exposes its sole public view.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

[enterprise/authentication/authentication.cc:2048] Because view_at(view) is short-circuited when no policy governs path, visible(path, view_count()) returns true instead of rejecting an index that names no view, even in assertion-enabled builds. A stale or corrupted action index can therefore receive every public artifact; the community implementation has the same release-build behavior.

Severity: medium

Other Locations

• src/authentication/authentication.cc:92

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[cubic-dev-ai]

1 issue found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="enterprise/authentication/authentication.cc">

<violation number="1" location="enterprise/authentication/authentication.cc:2040">
P2: The new public `view_at`/`visible` API never validates the incoming index on the production path. The only guard is an `assert(index < this->view_count_)` inside `Impl::view_at`, which is stripped under NDEBUG, so a release build with an out-of-range index does an out-of-bounds read of the view table and forms a garbage `std::string_view` from an invalid string offset. Since these are exported public entry points, consider guarding the index in the public methods (e.g. return std::nullopt/std::optional, or explicit bounds checks) instead of relying only on debug asserts.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[github-actions]

Benchmark Index (community)

Details

Benchmark suite	Current: 1ab561a	Previous: ea33051	Ratio
Add one schema (0 existing)	319 ms	322 ms	0.99
Add one schema (100 existing)	30 ms	30 ms	1
Add one schema (1000 existing)	92 ms	90 ms	1.02
Add one schema (10000 existing)	1048 ms	1186 ms	0.88
Update one schema (1 existing)	22 ms	22 ms	1
Update one schema (101 existing)	30 ms	30 ms	1
Update one schema (1001 existing)	91 ms	93 ms	0.98
Update one schema (10001 existing)	1055 ms	806 ms	1.31
Cached rebuild (1 existing)	7 ms	8 ms	0.88
Cached rebuild (101 existing)	10 ms	10 ms	1
Cached rebuild (1001 existing)	35 ms	36 ms	0.97
Cached rebuild (10001 existing)	358 ms	342 ms	1.05
Index 100 schemas	613 ms	620 ms	0.99
Index 1000 schemas	1491 ms	1531 ms	0.97
Index 10000 schemas	13399 ms	13341 ms	1.00
Index 10000 schemas (custom meta-schema)	16268 ms	16595 ms	0.98
Index 10000 schemas ($ref fan-out)	15895 ms	16631 ms	0.96

This comment was automatically generated by workflow using github-action-benchmark.

[github-actions]

Benchmark Index (enterprise)

Details

Benchmark suite	Current: 1ab561a	Previous: ea33051	Ratio
Add one schema (0 existing)	395 ms	459 ms	0.86
Add one schema (100 existing)	107 ms	183 ms	0.58
Add one schema (1000 existing)	168 ms	155 ms	1.08
Add one schema (10000 existing)	835 ms	1487 ms	0.56
Update one schema (1 existing)	98 ms	89 ms	1.10
Update one schema (101 existing)	105 ms	90 ms	1.17
Update one schema (1001 existing)	169 ms	162 ms	1.04
Update one schema (10001 existing)	853 ms	1541 ms	0.55
Cached rebuild (1 existing)	9 ms	8 ms	1.13
Cached rebuild (101 existing)	12 ms	10 ms	1.20
Cached rebuild (1001 existing)	39 ms	35 ms	1.11
Cached rebuild (10001 existing)	329 ms	294 ms	1.12
Index 100 schemas	530 ms	890 ms	0.60
Index 1000 schemas	1706 ms	2206 ms	0.77
Index 10000 schemas	13353 ms	17511 ms	0.76
Index 10000 schemas (custom meta-schema)	16422 ms	19001 ms	0.86
Index 10000 schemas ($ref fan-out)	16295 ms	19354 ms	0.84

This comment was automatically generated by workflow using github-action-benchmark.