NuGet packages with evidence you can enforce.
Rorix Registry is a fail-closed NuGet gateway. It rebuilds packages when source is verifiable, preserves authenticated upstream bytes when it is not, and exposes the difference as policy—not marketing fine print.
An open ecosystem. A controlled way in.
Public registries put a world of dependencies within reach. Rorix Registry narrows that attack surface to a catalog governed by your organization’s package policy.
Packages & dependencies
Your package policy
- Provenance
- Vulnerabilities
- License rules
versions
- 01
Start with the public ecosystem
NuGet and npm connect your team to packages, publishers, and transitive dependencies from around the world. Every new dependency expands what you need to trust.
- 02
Make your policy the entry point
Choose the package versions your organization accepts. Require provenance evidence, enforce vulnerability and license rules, and record reviewed exceptions before publication.
- 03
Give builds a governed catalog
Only approved, published versions that meet your policy reach the feed. Quarantined versions stay out, including dependencies that fail the same gates.
A package hash proves identity. It does not prove how the package was made.
NuGet metadata is uneven: some packages name an exact commit, some expose only a repository, and some expose no usable source evidence. Pretending those cases carry the same confidence creates a brittle registry. Rorix makes uncertainty visible and enforceable.
- ✓Only published versions are visible to restore clients
- ✓Missing commit metadata triggers more evidence resolution
- ✓Signed upstream fallback preserves the original bytes
- ✓Unsigned packages require a version-specific approval
- ✓High-risk security findings quarantine publication
- ✓Source-built and mirrored artifacts are labeled differently
Five levels. One organization policy.
Choose the weakest evidence your organization will accept. Anything below it stays quarantined and absent from the feed.
Reproduced source
An exact commit rebuilt to matching normalized package contents and assemblies.
Pinned source
An exact commit rebuilt in isolation, with differences from the upstream package disclosed.
Inferred source
An immutable commit resolved from an exact version or release-tag heuristic and rebuilt.
Upstream signed
The exact upstream nupkg bytes mirrored after NuGet signature verification.
Digest only
Unsigned upstream bytes pinned by SHA-256 and quarantined until a version-specific approval exists.
Request → resolve → verify → restore
The source path and fallback path converge on the same publication gate.
Trust a package line
Choose a baseline version and your organization’s minimum acceptable provenance.
Resolve source evidence
Rorix follows the package metadata and embedded evidence to an immutable commit or exact tag.
Build or mirror
Verifiable source is rebuilt and compared. Otherwise the exact upstream package enters the lower-trust mirror path.
Gate and restore
Only versions that pass provenance, security, and recursive dependency policy appear in the authenticated NuGet feed.
A registry built around provenance decisions
Evidence before labels
Rorix reads nuspec XML, Source Link, assembly version metadata, immutable tags, and reviewed mappings. A mirror is never labeled as a rebuild.
Measured reproduction
Rebuilt output is compared with upstream after removing volatile NuGet metadata. Assembly, PDB, source-mapping, and package differences remain in the record.
Authenticated fallback
When source evidence or a build fails, Rorix can preserve the exact signed upstream package. Unsigned artifacts remain quarantined by default.
Publication gates
Minimum provenance, typosquats, denied licenses, and high or critical vulnerabilities are enforced before a package becomes restorable.
Reviewable exceptions
A package-version exception records its reviewer and rationale, keeps the original finding visible, and re-runs verification before release.
Evidence artifacts
Published versions include CycloneDX and SPDX SBOMs, vulnerability and license reports, SLSA-shaped provenance, logs, digests, and Rorix verification signatures.
Answers without caveat-shaped surprises
What happens when a package has no repository commit?
That is a normal state. Rorix checks Source Link, assembly informational versions, immutable version tags, and reviewed mappings before falling back to the original upstream artifact.
Is every package rebuilt from source?
No. Rorix rebuilds where the source can be resolved and built defensibly. Otherwise it uses an explicitly labeled upstream-signed or digest-only mirror path, subject to your provenance threshold.
Does reproduced source mean every dependency was also rebuilt first?
No. It proves the selected package reproduced from its pinned source and exact resolved dependency versions. Blocking dependencies receive their own provenance and policy decisions; verified-upstream dependencies are never relabeled as source rebuilt.
How is this different from a normal NuGet proxy?
A normal proxy focuses on routing and caching. Rorix records source evidence, attempts controlled rebuilds, compares outputs, scans the package graph, assigns a trust level, and enforces that decision at restore time.
Will existing packages.lock.json files keep working?
Mirrored packages preserve upstream bytes and hashes. Source-built packages may have a different NuGet content hash, so you perform a reviewed one-time lock regeneration before returning CI to locked mode.
Does the beta use public Sigstore transparency logs?
Not today. Rorix emits signed verification artifacts and SLSA-shaped provenance, but does not claim a public Sigstore identity or cosign-compatible transparency proof until that integration is implemented and independently verified.