@brianteeman and @mbabker Please look over the error message if that is proper english and a proper explanation of why the installation would fail.

I have tested this item ✅ successfully on 6e89f72

I have tested this item ✅ successfully on 6e89f72

setting RTC as the last change was only text

@HLeithner What happens with this PR?

This PR does only a cosmetic protection... to resolve the problem mentioned by michael is to remove directly write access to the web directory for components. Everything else can be bypassed by executing file_put_contents in the after/before install script function.

Obviously. But having write protection to the web directory is not something we can do on our end.
Imho it's a simple and cost-efficient way which doesn't hurt anyone.

Of course, it will always be possible to hack core files. If an extension dev wants to do that, he can do it with his script file or an extension of the type file. But at least it will not that easy as naming a library package the same as core.

It will prevent however accidental overwriting.

There are additional measures that can be taken. Remove method="update" from all the core extension manifests closes someone being duped into installing a com_content package since no part of the core package can be sanely uninstalled or updated standalone.

Long and short, it is too easy right now to dupe people into installing something that cleanly overwrites core extension and library directories. Core should care enough to close those easily accessible vectors. You’re never going to make it impossible for someone to overwrite a directory’s contents as long as pure PHP scripts are executable during the extension install/update/uninstall routines, but that doesn’t mean the answer should be “meh, we aren’t going to do anything”.

There are additional measures that can be taken. Remove method="update" from all the core extension manifests closes someone being duped into installing a com_content package since no part of the core package can be sanely uninstalled or updated standalone.

Long and short, it is too easy right now to dupe people into installing something that cleanly overwrites core extension and library directories. Core should care enough to close those easily accessible vectors. You’re never going to make it impossible for someone to overwrite a directory’s contents as long as pure PHP scripts are executable during the extension install/update/uninstall routines, but that doesn’t mean the answer should be “meh, we aren’t going to do anything”.

Fair enough, maybe a small step, don't know if it helps anything but at least it doesn't hurt. I'm pretty sure we will never reach the full lockdown because it's to hard for devs but the vision for this should be only to write executable files with ftp and user authentication and have the whole web dir read only except cache and similar dirs. Writeable directories are not allowed to execute php files. This would bring joomla a big step further in protection against attacks.

Thanks for the pr and tests

It's off topic but I massively disagree with your vision

You are not the only one, so I don't try to push this direction.
But basically it's the same as any operating system is doing, anyway stop this discussion here.

a topic for a beer