Introduction
When a package version is initially blocked by JFrog Curation, administrators have the option to grant a waiver to allow its use. However, there are scenarios such as a newly discovered vulnerability or a change in compliance standards where that waiver must be revoked to ensure the package is once again blocked from your software supply chain.
This article will guide you through the process of manually revoking a Curation waiver by removing its associated metadata label and clearing the repository cache to enforce immediate blocking.
Resolution
To revoke a waiver, you must identify and remove the specific label assigned to the package version in the Package Catalog. For example, if you are revoking a waiver for newtonsoft.json:13.0.3, follow these steps:
Step-by-Step Instructions
- Navigate to the Package Catalog: Log in to your JFrog Platform UI and navigate to the Catalog -> Explore tab.
- Locate the Package Version: Use the search bar to find the specific package (e.g., newtonsoft.json) and select the version that currently has the waiver (e.g., 13.0.3).
- Remove the Waiver Label:
- Look for the Labels section associated with that version.
- Identify the label following the convention jfrog-waiver-policy-<PolicyID>.
- Delete this label. Removing this metadata effectively tells the Curation engine that the "exception" no longer exists.
NOTE: Currently, waiver labels only display the waiver policy. The Challenge is if a package version has multiple similar labels (e.g., jfrog-waiver-policy-123 and jfrog-waiver-policy-456), there is no way to distinguish which policy each label refers to.
- Clear the Remote Repository Cache: To ensure the blocking policy is enforced immediately upon the next download request, clear the cache for that specific package version in the relevant remote repository. This prevents the platform from serving the previously allowed (and cached) version.
Alternative: Revocation via GraphQL API
For automation or bulk actions, use a GraphQL mutation to unassign the label from a specific package version. Unlike deleting a label globally, this method ensures that other packages covered by the same Curation policy remain unaffected.
Endpoint: POST https://<jfrog-instance-url>/catalog/api/v1/custom/graphql
Example Request: The following example removes a specific waiver label from newtonsoft.json version 13.0.3.
curl -X POST "https://<jfrog-instance-url>/catalog/api/v1/custom/graphql" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <ACCESS-TOKEN>" \
-d '{
"query": "mutation { customCatalogLabel { removeCustomCatalogLabelsFromPublicPackageVersion(publicPackageVersionLabels: { labelNames: [\"jfrog-waiver-policy-12345\"], publicPackageVersion: { publicPackage: {name: \"newtonsoft.json\", type: \"nuget\"}, version: \"13.0.3\" } }) } }"
}'Key Parameters:
- labelNames: The specific waiver label to remove (e.g., jfrog-waiver-policy-12345).
- name: The name of the package (e.g., newtonsoft.json).
- type: The package ecosystem (e.g., npm, nuget, pypi).
- version: The specific version string (e.g., 13.0.3).
Important Note: This operation only removes the association between the label and the package version. It does not delete the label from your JFrog Platform, which is the preferred behavior when multiple packages share the same Curation policy.
Conclusion
By removing the jfrog-waiver-policy label and clearing the repository cache, you effectively re-enable the Curation gates for that package. This ensures your environment remains compliant with your organization's security policies.