Making WordPress.org

Opened 14 months ago

Last modified 6 weeks ago

#7217 new defect (bug)

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

Reported by: ipstenu's profile Ipstenu Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

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
  1. There have been no code-changes for at least 60 days

OR

  1. 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...).

Attachments (1)

7217.diff (5.5 KB) - added by dd32 9 months ago.

Download all attachments as: .zip

Change History (6)

#1 @dd32
14 months ago

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).

#2 follow-up: @Ipstenu
14 months ago

@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.

#3 in reply to: ↑ 2 @dd32
14 months ago

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
9 months ago

#4 @dd32
4 months ago

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.

#5 @dd32
6 weeks ago

#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.

Note: See TracTickets for help on using tickets.