Using a release that has been removed from the upstream repository can present risk for your organization. These releases are no longer accessible from the repository and the removal could be an indicator of vulnerability. With the Tidelift Subscription, these releases can be kept out of your catalog by using the removed releases standard.
Image 1: Package tagged as "Removed".
Image 2: Dialogue box explaining that the selected package has been removed upstream.
Why are releases removed upstream?
Releases may be removed by the package maintainers for different reasons. Ultimately, this is an indication that a specific release is problematic and the maintainer wants to prevent additional downloads of the release.
How does Tidelift identify removed releases?
Many package managers have a way of indicating that a release has been removed. Tidelift checks the status of releases regularly in order to identify the removal.
What happens if a release in my catalog is removed upstream?
When a release in your catalog is detected as removed, it will be denied. If you have tasks enabled on this standard, a task will also be created for an administrator to review the violation. For each release that was removed, the administrator can choose to create an override or deny the use of the release.
Creating overrides for removed releases
When a release is removed upstream or a developer requests a release that has been removed, you may still want to create an override for this package release to be approved in your catalog.
Overrides can be created when completing a task or by following the steps below. You can view and export all removed release overrides:
- Navigate to the Standards page
- Find the Removed Releases standard
- Select Manage overrides
- Click on "Create new overrides" and fill in the appropriate information
- On this page you can view, edit, and add exceptions