Making WordPress.org

Opened 21 months ago

Last modified 21 months ago

#6512 new enhancement

Plugin Directory: Block uploads of .git folders va SVN

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

Description

Right now, people can accidentally upload .GIT folders, resulting in private/non-public information being dumped into trac, as well as a massive ballooning in size.

I can't think of any reason we would need to allow git folders.

Change History (13)

#1 @dd32
21 months ago

Is there any reason to allow any files beginning with .?

Blocking them entirely would also prevent .svn and any other VCS files, or things like .DS_Store being added.

#2 follow-up: @GregLone
21 months ago

.htaccess files should still be allowed imho.

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

Replying to GregLone:

.htaccess files should still be allowed imho.

What's the use-case for those? I'd actually strongly suggest one shouldn't be included in a plugin, even if only containing example rules..

#4 @GregLone
21 months ago

Security or, more generally, denying direct access to files, like this one in Akismet: https://plugins.svn.wordpress.org/akismet/trunk/.htaccess.

Last edited 21 months ago by GregLone (previous) (diff)

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


21 months ago

#6 @Clorith
21 months ago

I would actually be for not allowing .htaccess, it's a false sense of security, not all systems run Apache after all :)

It makes sense to not allow . prefixed files, the plugin directory is for distribution, not development, and these type of files are generally dev-environment related (with the exception of .htaccess)

Last edited 21 months ago by Clorith (previous) (diff)

#7 @tellyworth
21 months ago

Is it possible to block folders starting with . and still allow (some) files starting with .?

#8 follow-ups: @kbat82
21 months ago

Blocking all files starting with . would remove some build scripts. Would this be in conflict with the plugin guidelines:

We require developers to provide public, maintained access to their source code and any build tools

#9 in reply to: ↑ 8 ; follow-up: @dd32
21 months ago

Replying to kbat82:

Blocking all files starting with . would remove some build scripts. Would this be in conflict with the plugin guidelines:

We require developers to provide public, maintained access to their source code and any build tools

There's been a push from some around repositioning plugins.svn from a "development" to "deployment" repo, and while I dislike that some tools use . prefixed files for configuration.. I guess that's a big enough reason to instead blacklist certain filenames/folder names.

The .htaccess example from Akismet is a poor one IMHO, that shouldn't be there really, although it was added by @tellyworth :)

Taking a step back and simply blocking problematic names, specifically, version-control folders and perhaps things like .log and error_log might be reasonable enough afterall.

#10 in reply to: ↑ 9 @kbat82
21 months ago

Replying to dd32:

...while I dislike that some tools use . prefixed files for configuration.. I guess that's a big enough reason to instead blacklist certain filenames/folder names.

Also, it's common on GitHub to include build scripts within a .github/workflows directory.

#11 in reply to: ↑ 8 ; follow-up: @GregLone
21 months ago

Replying to kbat82:

Blocking all files starting with . would remove some build scripts. Would this be in conflict with the plugin guidelines:

We require developers to provide public, maintained access to their source code and any build tools

If those files are not on the SVN repository, but publicly available somewhere else, like GitHub, is it good enough to comply with the guidelines? Maybe by providing a link somewhere in the description or the plugin?

#12 in reply to: ↑ 11 @kbat82
21 months ago

Replying to GregLone:

If those files are not on the SVN repository, but publicly available somewhere else, like GitHub, is it good enough to comply with the guidelines? Maybe by providing a link somewhere in the description or the plugin?

I'm not a part of the plugins team but it's my understanding that you are correct. However, in practice I personally see build files stripped from the repo and no link to a repository provided. I don't know how common that is though.

If the svn repo becomes a deployment repo I'd like to see some effort in enforcing that a bit more to keep everything more in the spirit of open source. To me such a change would be a loss for open source.

One example, if your GitHub repo is private (where dev discussion, etc happens), you'd have to set up an intermediary repo with the build and source files to comply. I'm speculating but I imagine a significant % would not make the effort, and I imagine the plugin team doesn't have the time/resources to manually check.

Anyway, I'll chime in when that discussion takes place.

#13 @Ipstenu
21 months ago

Re "We require developers to provide public, maintained access to their source code and any build tools"

Y'all need to re-read https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#4-code-must-be-mostly-human-readable

As I explained here: https://make.wordpress.org/plugins/2018/08/23/guideline-update-clarifications-to-trialware-and-human-readability/

Source code does not have to be included in the plugin hosted here if it's part of a compiled process. If you have it all on Github, that's fine :) You have to link (preferably in the readme) to it. We did that since Gutenberg source files get chunky.

One example, if your GitHub repo is private (where dev discussion, etc happens), you'd have to set up an intermediary repo with the build and source files to comply. I'm speculating but I imagine a significant % would not make the effort, and I imagine the plugin team doesn't have the time/resources to manually check.

We actually already do on submission, and most repos are public anyway since it's not like the code is about to be private once you push it here.

Taking a step back and simply blocking problematic names, specifically, version-control folders and perhaps things like .log and error_log might be reasonable enough afterall.

Honestly I agree. The number of times I have to point out "Remember to remove your error log!" is about the same as "Delete the .git folder"

Note: See TracTickets for help on using tickets.