You are right that there are plenty of old installations all over the web but no one here can be held accountable for the responsibility of website owners to upgrade regardless of reason.
TBH if an attacker is spending time manually checking version numbers of each site they are attacking the won't make it very far. Attacks are typically scripted and indiscriminate of version number, the attack runs and either fails or is successful. Writing a script to read Coppermine's version number before running attacks could be done but the time saved running it instead of running the attack directly would be negligible.
Anyway the version tagging in files (here mostly the backend files as well) also makes updating quite difficult. Why? Because when we compare for differences and want to update only changed files and apply own patches we get 100% changed files. So actually every update is a nightmare of dropping a whole new release files onto server, applying personal patches, checking what to remove again (like readme's etc.) and finally checking what custom files were overwritten and recovering them (like favicon, site logo, custom image set)
No offence but I think this argument is a little exaggerated.
Nothing forces a user to upgrade all the files in a new release, the version check may fail but it also fails if the user has any mods/patches present. It even says in the upgrade docs to backup any modded files (or to simply delete them from the new version download before uploading) and if no major changes have been made you can replace the newer files with your modded files or update the new files with your mod.
All websites require maintenance.
- aside of full package there could be package with only changed files (similar to phpbb3 distros)
git pull (
--rebase if you have mods)
Shouldn't be uploading new version directly into production anyway IMHO, use a testbed and push updates from there to production.
Once 1.6 is the official release the whole process should get easier.
- drop the idea of file tagging and use file hashes - everything would stay on server side, we only need to know if a file was changed, but if we really need to know the actual version we could keep a list of hashes for previous versions (the list wouldn't be that long, because hash would change only when file was changed between versions - now because of version/release tags file looks as changed every time)
keep the version number present but obscure it?
or like
git tag? I agree with this for bug fixes/build changes but still believe in major.minor.release versioning for releases.
Anyway this is all option and only really applies to the git repo but this is an open source project:
https://github.com/coppermine-gallery