Closed otagi closed 9 years ago
Hi @otagi
What exactly are the "security reasons" involved?
It's unsafe to run larasset
commands in a production environment (I mean on a server) because it run system commands.
So a malicious user could use it to run dangerous(arbitrary) commands (e.g. erase all your data...).
Wouldn't the malicious user need to have access to either the server shell or the app's source code with authorization to deploy it on the server?
If so, the point is moot, because (s)he would then have other available entry points to execute dangerous commands.
Or maybe I'm missing something. I'm not an expert on Laravel's code base.
(s)he would then have other available entry points to execute dangerous commands.
I agree with you, but most hacked websites are done with the conjunction of multiple vulnerabilities.
My point of view if that larraset
precompilation should be only executed on a development computer or a staging server but never on a production server. And to run precompilation you also need to install Node.js on the server so it can be useless if you haven't any Node.js production applications on it.
In LarassetServiceProvider, commands are disabled in production:
This makes it impossible to precompile assets on the server, with e.g. a Rocketeer post-deploy hook.
Precompiling locally before a git commit is not an ideal solution either, because it stores unnecessary big files in the repository. (not very clean)
Can we remove this unnecessary limitation? What exactly are the "security reasons" involved?