Introduce deploy keys for SVN

[Clorith]

It's been stated many times that the plugins and themes directories are not for version control, they are deployment systems, and should only be used as such.

This means developers should be (and are) using other services, like for example GitHub, to host their publicly available code (also to comply with for example plugin directory guidelines that un-minified sources code needs to be freely available).

The problem here is the tedium of doing those deploy, with a proper workflow, you would be developing on GitHub, making a release, tagging it, then having to replicate all the code over to SVN. I know this is a contentious topic, and not everyone is a fan of automated workflows from locations such as GitHub.

Many folks use GitHub actions to automate this, but that has a drawback: You need to supply your WordPress.org username and password as secrets on a 3rd party. This also makes for extra steps if someone else takes over maintaining your code.

I don't know if it's possible to add multiple keys to a user, so that application password like keys could be added for a user on SVN, and that wouldn't solve the problem of maintainer ownership transfers with 3rd party systems.

My thought is therefore, all SVN assets get their own user, with an auto-generated key (the key can be revoked to get a new one from within the plugin admin screen by anyone with commit access, and a notification being sent to all committers if this is done).

This would allow existing users to keep doing it the way they've always done things with their own user if they want, but they, and new plugins, could then also use this new user, which would be unique to each plugin.

A user like wp-plugin-${plugin-slug} would likely not exist already in the system, and it would then be possible to block registrations of any such prefixed usernames as well.

If we wanted to take it one step further, and make sure that uses of GitHub actions (which would be my preferred approach) do not cause issues, we could very easily create our own wp-plugin-deploy action, that would help authors not make mistakes during releases.

[dd32]

I don't know if it's possible to add multiple keys to a user, so that application password like keys could be added for a user on SVN, and that wouldn't solve the problem of maintainer ownership transfers with 3rd party systems.

Application Passwords are possible, part of the problem is that we're using BASIC auth though, and the mod_auth_mysql Apache auth module seems to only support a singular user/pass combination. (Note: We we another module to provide WP password hash support)

all SVN assets get their own user, with an auto-generated key (the key can be revoked to get a new one from within the plugin admin screen by anyone with commit access, and a notification being sent to all committers if this is done).

Unfortunately, we can't easily enable key-based authentication due to using SVN over HTTPs with path restrictions per-user (plugin). (Key based required ssh+svn which doesn't support per-path auth, and HTTPS doesn't offer key-based auth AFAIK)

But assuming that you're suggesting an auto-generated user w/ password for commit/deployment purposes, that's possible currently with the current SVN setup, and is how I personally do it. I've got a ​dd32-githubsync user whose only purpose is to commit on my behalf to SVN from GitHub..

While we could add a single-button create-svn-user type thing, I'm not 100% sure that'll actually be beneficial in the long run?

If we wanted to take it one step further, and make sure that uses of GitHub actions (which would be my preferred approach) do not cause issues, we could very easily create our own wp-plugin-deploy action, that would help authors not make mistakes during releases.

Having something similar to the 10up deployer that's 'official' would make lives easier, last time I went down that path though, I found a better option was to ditch SVN and have the plugin directory pull directly from GitHub releases (​GitHub feature branch) but I never finalised that.. after running into limitations of the GitHub api at the time, but since then, things such as GitHub actions have launched.. so it might be easier to just do an official deployer action.
The other option is installation of a WordPress Plugin Directory app which can do the auth with the plugin directory and/or trigger action builds via workflow_dispatch

[Clorith]

Yeah, an automatically generated user was my thought process here as I suspected there would be limitations in the SVN setup, so that would basically make it function as today, only that a second committer is automatically added for a new user that's generated on plugin approval.

I'd say that making it a part of the automated process that happens when a plugin is approved could be great, here, I'm honestly not sure what the best approach would be for existing entries though, might need a bit more thought in that regard. I guess my use of "key" was confusing here, it would be more "its own user which has a normal password, but since it's a separate user, it's not tied in to your regular account".

I do remember the mention of the GitHub pull, I see benefits of a WPPD app to auth, we should find out which approach (between app and action) has the best route to a MVP, but also which one offers the best flexibility moving forward.

With an action, it is much easier to open source it, and some may feel more comfortable with that than an application which they don't know the inner workings of 🤔