Opened 2 years ago
Last modified 2 years ago
#6512 new enhancement
Plugin Directory: Block uploads of .git folders va SVN
Reported by: | 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)
#3
in reply to:
↑ 2
@
2 years 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
@
2 years ago
Security or, more generally, denying direct access to files, like [this one in Akismet](https://plugins.svn.wordpress.org/akismet/trunk/.htaccess).
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
2 years ago
#6
@
2 years 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
)
#7
@
2 years ago
Is it possible to block folders starting with .
and still allow (some) files starting with .
?
#8
follow-ups:
↓ 9
↓ 11
@
2 years 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:
↓ 10
@
2 years 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
@
2 years 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:
↓ 12
@
2 years 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
@
2 years 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
@
2 years 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"
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.