Totally normal for PHP software, and that's a primary reason of why PHP apps have such a bad security reputation. Note:

- The application code itself and system configs are modifiable by the web handler itself. This is needed to allow web-based "setup.php" to work, but also means that any sort of RCE is immediately "fatal" - no need for kernel/sandbox exploit, if you can get PHP to execute remote code you can backdoor existing files as much as you want.

- The "logs", "tmp", "config" etc.. directories are co-located with code directory. This allows easy install via unzip, but means that the code directory must be kept accessible while operation. It's not easy to lock it down if you want to prevent possible backdoors from previous options.

Those install methods have been embraced by PHP community and make exploits so much easier. That's why you always hear about "php backdoors" and not about "go backdoors" or "django backdoors" - with other languages, you version-upgrade (possibly automatically) and things work and exploits disappear. With PHP, you version upgrade .. by extracting the new zip over the same location. If you were hacked, this basically keeps all the hacks in place.

Kinda weird to see this from some self-claimed "security professionals" though, I thought they'd know better :)

▲

PokemonNoGo a day ago | parent | next [-]

I kinda understood I was missing "something" when I commented but I haven't used any PHP for over a decade and honestly it looked very well you said the rest... Thanks for the clarification. Very unfamiliar with modern PHP.

▲

lucb1e a day ago | parent [-]

What did you think you had missed? I'm not understanding

> but I haven't used any PHP for over a decade

This isn't modern PHP, this is the traditional installation method that I used also a decade ago. The only thing that could be older about it is to have a web-cron instead of a proper system cron line. Modern PHP dependency installation is to basically curl|bash something on the host system (composer iirc) rather than load in the code under the web server's user and running the install from there, as this repository suggests. Not that the parent comment is wrong about the risks that still exist in being able to dynamically pull third-party code this way and hosting secrets under the webroot

	▲	reconnecting a day ago \| parent [-]
		Correct, this isn't modern PHP. We aimed to keep overall code dependencies around ~10, and with modern frameworks this number would be multiplied heavily.

▲

reconnecting a day ago | parent | prev [-]

Fair critique on traditional PHP deployment.

However tirreno shouldn't be public-facing anyway. Production apps forward events via API on local network, security teams access dashboard over VPN.

Perhaps we will add this recommendation to the documentation to avoid any confusion. Thanks for the clarification.