[
https://issues.apache.org/jira/browse/MNG-7238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517686#comment-17517686
]
Chris Kilding commented on MNG-7238:
------------------------------------
In light of the recent Log4Shell and Spring4Shell vulnerabilities, I believe
it's worth taking another look at this feature proposal from the security
angle, rather than just the maintenance angle which has been considered before.
At the moment, the lack of a centralised deprecation mechanism means that
artifact consumers need to use 3rd party sources to find out about
vulnerabilities. They either do this the automated way (by getting an alert
from tools like Snyk or Dependabot, which requires setting up these tools
before a vulnerability hits), or the manual way (learning about the
vulnerability when they stumble across the CVE headlines in the news).
This approach is opt-in by definition. It means that only the vigilant
developers who set up scanning tools, or those who read the headlines at the
right time, have been notified about Log4Shell/Spring4Shell. It has left a
'long tail' of projects still using vulnerable versions of Log4J/Spring
*months* after the vulnerabilities have been made public.
Is this really the best we can do?
Consider an alternative version of events where there is a dependency
deprecation mechanism built in to Maven, and that mechanism supports
per-version deprecation indicators...
The maintainers of the affected library would mark the vulnerable version as
deprecated in Maven Central (or wherever it's hosted). Anyone who runs Maven on
a vulnerable downstream project would get a warning about the deprecated
dependency version (just as in the NPM, Nuget, Composer, or Cocoapods
ecosystems). They would get that warning as soon as their Maven client
refreshes its deprecation information (not weeks or months after the
vulnerability announcement). There would be no need to opt into 3rd party tools
to get these warnings (although such tools could leverage the deprecation
indicators to do clever value-adds like automated fixes).
Yes, this wouldn't fix everything by itself, because updating the vulnerable
projects would still be up to developers. Yes, there would still be some
residual of projects that will never be fixed. But I do believe it would be a
significant improvement over where we are today.
> Dependency deprecation indicators
> ---------------------------------
>
> Key: MNG-7238
> URL: https://issues.apache.org/jira/browse/MNG-7238
> Project: Maven
> Issue Type: New Feature
> Reporter: Chris Kilding
> Priority: Major
>
> I would like to propose a new Maven feature: dependency deprecation
> indicators.
> In a nutshell, the idea is to let maintainers set a 'deprecated' metadata
> indicator on a Maven artifact in a repository. This will indicate to users
> that the artifact should no longer be used.
> The Maven CLI tools could then react to deprecation indicators in the
> appropriate ways:
> * {{mvn}} itself: Print a warning when deprecated dependencies are seen.
> * Maven Enforcer Plugin: Add a {{<banDeprecatedDependencies>}} rule which
> throws an error when deprecated dependencies are seen. (Also have a 'skip'
> property which allows the rule to be temporarily bypassed if needed.)
> * Maven Dependency Tree: Print a {{[deprecated]}} notice next to any
> deprecated dependency in the tree.
> We can also envisage automated agents like Dependabot or Snyk using these
> indicators to alert developers about deprecated dependencies in their stacks,
> and even assisting developers to remove them.
> Some of the major build tools outside the JVM already have deprecation
> indicators:
> * NPM: [https://docs.npmjs.com/cli/v7/commands/npm-deprecate]
> * Nuget:
> [https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages]
> * Composer:
> [https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/]
> * Cocoapods: [https://guides.cocoapods.org/syntax/podspec.html#deprecated]
> So the feature has precedent, and I believe it would be useful to have in
> Maven.
> This Jira ticket follows up from the conversation "Feature proposal:
> Dependency deprecation indicators" on the maven-dev mailing list.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
