feat: add package registry and maintainability check (#1400)

[RuchitAgrawal]

Summary

Adds a new check mcn_registry_maintainability_1 that validates whether a package exists on its public registry and is actively maintained.

Description of changes

The check uses three signals when available:

• Registry presence and release recency: Uses the existing find_publish_timestamp() to confirm the package exists and check how many days have passed since the last release. Exceeding the threshold fails the check.
• Deprecated/yanked status: Reads the yanked flag for PyPI packages and the deprecated field for npm packages from existing registry JSON responses. A yanked or deprecated package always fails, regardless of release age.
• GitHub repository signals: If the source repo is on GitHub, calls the existing get_repo_data() to check if the repo is archived and how recently code was pushed. An archived repo always fails.

Results include remediation guidance and links to the registry page and source repository. The inactivity threshold is configurable via defaults.ini under registry_maintainability (default: 365 days).

Related issues

Closes #1400

Checklist

• I have reviewed the contribution guide.
• My PR title and commits follow the Conventional Commits convention.
• My commits include the "Signed-off-by" line.
• I have signed my commits following the instructions provided by GitHub. Note that we run GitHub's commit verification tool to check the commit signatures. A green verified label should appear next to all of your commits on GitHub.
• I have updated the relevant documentation, if applicable.
• I have tested my changes and verified they work as expected.

[behnazh-w]

@RuchitAgrawal Thanks for the PR! Could you suggest a few packages that would fail this check? That would help us identify good candidates to include in integration tests.

[behnazh-w]

@RuchitAgrawal Looks like the integration tests are failing. You can search for "case failed" in the log to see which test is failing.

[RuchitAgrawal]

Thanks for the PR! Could you suggest a few packages that would fail this check? That would help us identify good candidates to include in integration tests.

@behnazh-w ,Here are a few packages that would fail across the check evaluation:

• pkg:pypi/aiohttp@3.9.3 — yanked due to a security vulnerability
  Stale release (last release older than the default 365-day threshold):

• pkg:pypi/arrow@0.15.0 — released May 2019, ~7 years old

• pkg:pypi/boto@2.49.0 — released April 2018, the original boto library superseded by boto3

• pkg:npm/request@2.88.2 — officially deprecated in 2020

[RuchitAgrawal]

@RuchitAgrawal Looks like the integration tests are failing. You can search for "case failed" in the log to see which test is failing.

Found the issue and pushed a fix.

[behnazh-w]

Thanks for the PR! Could you suggest a few packages that would fail this check? That would help us identify good candidates to include in integration tests.

@behnazh-w ,Here are a few packages that would fail across the check evaluation:

* pkg:pypi/aiohttp@3.9.3 — yanked due to a security vulnerability
  Stale release (last release older than the default 365-day threshold):

* pkg:pypi/arrow@0.15.0 — released May 2019, ~7 years old

* pkg:pypi/boto@2.49.0 — released April 2018, the original boto library superseded by boto3

* pkg:npm/request@2.88.2 — officially deprecated in 2020

Thanks a lot. For pkg:pypi/arrow@0.15.0 we already have an integration test and can make sure that the check explicitly fails.

For the rest, we can add new integration tests since each test can cover a different scenario or failure reason.

[RuchitAgrawal]

@behnazh-w Thanks for the feedback! I've added the integration tests as suggested. Here is what was done:

• Extended the existing pypi_arrow to also check mcn_registry_maintainability_1: fails for arrow@0.15.0 and passes for arrow@1.3.0.
• Added pypi_aiohttp: covers the yanked package path (aiohttp@3.9.3).
• Added pypi_boto: covers the stale release path (boto@2.49.0).
• Added npm_request: covers the npm deprecated path (request@2.88.2).

All three new tests follow the same pattern i.e. the policy requires the check to pass, but since it correctly fails for these packages, we set expect_fail: true.

Regarding the CI failures visible on the PR, those build tests were already failing on main before this PR . These changes don't touch any of those test cases.

[RuchitAgrawal]

Hi @behnazh-w, Out of the 18 failing tests, 1 was pypi_arrow which was failing because of my last commit.

The problem was I applied the registry-maintainability policy to all arrow versions using a wildcard, assuming arrow@1.3.0 would pass. Fixed it in the latest commit, by scoping the policy to only arrow@0.15.0.
Kindly review the PR again.

[RuchitAgrawal]

@behnazh-w Thanks for reviewing the PR. I have addressed all the comments in the latest commit. Kindly take another look when you get a chance.

[RuchitAgrawal]

@behnazh-w I have fixed the failing tests and feel it is ready for your review. Also, really appreciate all your reviews and guidance! I am still relatively new to open source but working on these PRs under your guidance has been a very good learning experience for me.

[RuchitAgrawal]

@behnazh-w I have tested the failing integration test locally and found the issue. Corrected it and verified the test now passes locally. Thank you for your patience and guidance as I worked through errors with the CI tests over these last few commits. Kindly review this commit.

[behnazh-w]

@RuchitAgrawal thanks for the fixes. Looks like CI checks are stuck. To trigger the workflows, can you please amend the last commit and force push to your fork?

[RuchitAgrawal]

@behnazh-w Done, amended and force-pushed, CI should trigger now.

[RuchitAgrawal]

@behnazh-w The CI build test is still failing again. I spent some time debugging and checking the logs, but I'm honestly a bit stuck on why this specific error is happening.

Could you please point me or guide me on what I might be missing?

[behnazh-w]

@RuchitAgrawal Running the analyze command on pkg:maven/com.intellectualsites.arkitektonika/Arkitektonika-Client@2.1.3, the check fails, and if I don't specify the version, the check returns UNKNOWN with remediation: Cannot determine registry status: the PURL does not include a specific version.. Since this artifact is actively maintained, shouldn't the check pass in both cases?

[RuchitAgrawal]

@behnazh-w You are right, thanks for spotting this case! Both cases should definitely pass. I just pushed a fix with the following updates:

Versioned case: The check was incorrectly using the pinned version's date. I have added a method to query Maven Central for the newest release date.

No-version case: It was returning UNKNOWN if a version was missing. I added a Maven-specific helper to fetch the latest release date even without a specified version.

I have also included new unit and integration tests to cover both scenarios.

[Copilot]

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

src/macaron/slsa_analyzer/package_registry/maven_central_registry.py:332

• timezone is not imported in this module, so tz=timezone.utc will raise NameError at runtime in find_latest_release_timestamp. Since the module already imports UTC from datetime, use that directly (or import timezone).

                return datetime.fromtimestamp(round(timestamp / 1000), tz=timezone.utc)

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• 175728472+copilot@users.noreply.github.com

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[Copilot]

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/macaron/slsa_analyzer/package_registry/maven_central_registry.py:332

• find_latest_release_timestamp returns tz=timezone.utc, but timezone is not imported in this module, so this will raise NameError at runtime. find_publish_timestamp already uses the imported UTC constant; use that here for consistency (or import timezone).

                return datetime.fromtimestamp(round(timestamp / 1000), tz=timezone.utc)

src/macaron/slsa_analyzer/checks/registry_maintainability_check.py:633

• pushed_at values from the GitHub API are RFC3339 strings with a trailing Z (e.g. 2026-01-01T00:00:00Z). datetime.fromisoformat() does not reliably accept the Z suffix on Python <3.11, so this will raise ValueError and silently disable the commit-recency signal. Normalize Z to +00:00 (as is already done in the Maven no-version path).

                if pushed_at:
                    # GitHub timestamps use the ``Z`` suffix; normalise for datetime.fromisoformat() on Python < 3.11.
                    try:
                        commit_dt = datetime.fromisoformat(pushed_at)
                        days_since_commit = (now - commit_dt).days

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[oracle-contributor-agreement]

Thank you for signing the OCA.

[RuchitAgrawal]

Hey @behnazh-w , quick question before I push a fix. The make audit failure is from 3 advisories on mcp 1.23.3, which semgrep hard-pins exactly. There's no way to upgrade it independently, and even the latest semgrep (1.170.1) still ships the same pin. The vulns are in MCP server features that macaron never touches.

Would it make sense to add --ignore-vuln flags for these in the Makefile, same as the existing lxml/Click ones? Wanted to check before changing anything.

[behnazh-w]

Hey @behnazh-w , quick question before I push a fix. The make audit failure is from 3 advisories on mcp 1.23.3, which semgrep hard-pins exactly. There's no way to upgrade it independently, and even the latest semgrep (1.170.1) still ships the same pin. The vulns are in MCP server features that macaron never touches.

Would it make sense to add --ignore-vuln flags for these in the Makefile, same as the existing lxml/Click ones? Wanted to check before changing anything.

Thanks, this is addressed now on main. Please rebase.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RuchitAgrawal]

@behnazh-w Hello, addressed the CI failures from the upstream sync. Should be good and working now, Kindly review it.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.