Plugin Directory: Block uploads of .git folders va SVN

[Ipstenu]

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.

[dd32]

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.

[GregLone]

.htaccess files should still be allowed imho.

[dd32]

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

[GregLone]

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

[Clorith]

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)

[tellyworth]

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

[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

[dd32]

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.

[kbat82]

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.

[GregLone]

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?

[kbat82]

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.

[Ipstenu]

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"