I had been thinking that we would use the git commit hash as a marker for uniqueness of a given plugin version, but there will be some situations where this doesn’t work.
What happens when a developer does multiple releases on GitHub based on the same commit hash from the source code?
What happens when a developer releases version 1.0.1, notices an issue and re-releases different code to fix the issue but still calls it 1.0.1?
The right thing to do in these cases is to create a new commit corresponding to the new release, and bump the version number for the fixed version, respectively, but not everyone will do this.
Should we be a bit more flexible about what a specific version number means, or should we block these situations from occuring?
I’m leaning towards the latter, which would mean that we link each version number to a commit hash and a zip file checksum (if the zip is released separately). This will guarantee that you know what you’re getting for a given plugin based on its version number, which is very useful once we get into dependencies.
I think we should be strict. I don’t advocate for possible confusing versioning.
As harsh as it can be, being strict is going to pay off in the future.
As I understand, this is a good basic security measure, in order to avoid hack or man in the middle. And any security is a high priority. Except the security theatre.
My vote goes to the hash or checksum checking and rejection to install, if it don’t match.
Speaking as a plugin developer, plugins that update a file without bumping their version number are infuriating for a number of reasons, including false positives from security plugins like WordFence. I’m all for strict linkage between commit hash and version.
I agree. Updating code without bumping the version number is bad practice so i don’t think it’s wrong to take whatever measures are necessary to prevent this. Likewise, if we can get people to use the hash in a more constructive way, then so much the better.
We have to use the zip hashes - that’s the only way to be sure people are getting what we think they’re getting and the only thing we can check once the installing CP instance has got the zip.
If the zip hash changes but the version doesn’t we flag the plugin - that’s a classic way to hijack a release.
We’ll need a way for people to report mismatched hashes.
Before that, people will have to check the hashes. Is there an easy way to tell them to do that? And what’s the method for checking that you would recommend?
All the checks will happen behind the scenes - the user won’t need to be involved. They’ll only need to get involved if the hash doesn’t match as we’ll have no way of knowing whether it’s because their hosting sucks or the zip has changed from what we’re expecting.
Regardless, it won’t install from the CP directory if the hashes don’t match.