WIP: New deprecation feature

[jayfk]

This PR is a continuation of #910. #798 is also related.

The basic idea is that package maintainers can deprecate a release as insecure or EOL and provide a URL to a CVE or a blog post for further information.

After the discussion in #910, I've settled for the more generic deprecation instead of just marking a release as insecure.

Views/Routes

This PR adds a new view deprecate under packaging/views.py. To use it, the user has to be authenticated and to be a Project maintainer.

There's also a new route packaging.deprecate, accessible under /project/{name}/deprecate/

Database

Adds 3 new columns in the releases table, including a migration.

• deprecated_at, Datetime, nullable.
• deprecated_reason, enum("eol", "insecure"), nullable.
• deprecated_url, Text, nullable.

Template Changes

There's a new template packaging/deprecate.html for the deprecate view.

Additionally, there are changes in packaging/detail.html:

• Adds a visible banner if the selected release is EOL (yellow), or insecure (red)
• Adds badges in the Version History tab.

I couldn't find any form styling options, so the form looks pretty abysmal. Right now the form is just wrapped in divs to get proper form blocks. I thought that there's probably a bigger plan for forms in general, so I've decided to not include any stylings here.

Design

There are some minor changes:

• Adds a --bad option to badges (to display insecure releases)
• Adds a --highlight and --bad option to horizontal sections (to display a banner for the selected release).

Screenshots

Deprecate view

Release history with insecure and EOL release

Deprecated release selected

Insecure release selected

Discussion/Todo

There are still some things to left to do/discuss here.

Currently, the only deprecation options are insecure and EOL. Maybe add a third, unmaintained?

The deprecation form is full of placeholder texts once we have consensus on the options, this needs to be added.

Where to place the link? The package detail view would be an ideal fit, but from what I know is heavily cached. Is there some kind of session detection mechanism in place that makes it possible to use uncached views of the page?

API? Should this be added to the legacy JSON API views, or is there a new API planned?

Accessibility: Add a warning icon?

[jayfk]

I've been working on a open database that contains all known security vulnerabilities in Python packages: https://github.com/pyupio/safety-db

The db (which is just a big json file) contains SpecifierSets as in packaging.specifiers, so it'd be relatively easy to write a data migration that flags insecure releases.

Please let me know if there is any interest in this.

[gtback]

shouldn't :-)

[brainwane]

@jayfk hi, and sorry for the slow response! Will you be at the PyCon North America sprints, which would be a good place to hash out the answers to your questions for a feature like this?

[nlhkabu]

marking as 'WIP'. @jayfk do you have some time to schedule a chat about this feature? thx

[brainwane]

@woodruffw thought you might want to take a look at this.

[brainwane]

Might be useful to revisit this after finishing #5863.

[nlhkabu]

Please note:
If/when this PR is re-reviewed, we will need to ensure that the templates are appropriately translated.

[di]

Given the age of this PR, and that we just merged support for "yanking" releases which mostly covers this use case, I'm going to close it, but thanks for the attempt here!

The one thing we might want to surface from this (and which PEP 592 also provides for) is specifying the reason for yanking. If anyone is inclined to work on that, we'd be happy to accept a PR.

[nlhkabu]

The one thing we might want to surface from this (and which PEP 592 also provides for) is specifying the reason for yanking. If anyone is inclined to work on that, we'd be happy to accept a PR.

@di do we have a ticket for that? Could not find one.

[di]

@nlhkabu Done: #7856