Plugin Directory: Auto remove zips for plugins closed more than 60 days with no activity

[Ipstenu]

When a plugin is closed, developers are allowed to still push code to it, in the hopes that all corrections will be made.

However, a large percentage of plugins are never updated, resulting in a situation where people can (in fact) download zips of a plugin if they know how, even though no one should be using the plugin.

It would be nice if zips were auto-removed and no longer built if the following criteria is met:

1. The plugin is closed for at least 60 days

2. There have been no code-changes for at least 60 days

OR

3. There is no one with commit access to the plugin

On top of that, we should probably have a way to nuke all the files in the case of a GPL issue (i.e. if the plugin used non GPL code, we need to ensure it cannot be downloaded and really should nuke the files, but that's a bigger headache). I think, by preventing downloads of the zip, we protect ourselves a bit more.

It will also prevent angry people who were banned from kvetching that we 'kept their code' (even though it's open source...).

[dd32]

Instead of removing the files, we probably just want to limit access to them instead.

We could introduce a new post_meta along the lines of unavailable which if true/unset/etc would deny access to the ZIP.

That would mean that if the plugin is re-enabled, the previous ZIPs would become available again without needing to be rebuilt (which is important, if we care about file signatures or something).

[Ipstenu]

@dd32 That would work.

I was thinking, since they'd have to push a new version ANYWAY to come back no matter what, it's not really a harm and we can recoup disk space.

[dd32]

Replying to Ipstenu:

I was thinking, since they'd have to push a new version ANYWAY to come back no matter what, it's not really a harm and we can recoup disk space.

The ZIPs are stored in a SVN now, so deleting them doesn't actually recoup any disk space.

[dd32]

It's been noted that the plugin reviewers (and probably the WordPress.org security team too) would benefit from retaining access to the ZIPs.

That greatly complicates it, but the simplest way would probably be to allow any authenticated user to access the ZIP, but decline non-auth'd clients (Such as a WordPress install).

The plugin security team also needs to be able to use automated tooling to test the plugins, which currently would be making an unauth'd request to the ZIP, so this would likely require further changes to plugin review/security tools first.

[dd32]

#7756 has raised another scenario where this would be useful.

Sometimes (sadly) we have scenario's where a copy of a plugin is submitted (such as a paid version) or where there's malicious content, and we obviously don't want to serve ZIPs of those.

Being able to effectively turn off ZIP serving for those cases would be helpful.