It’s not purely a matter of trust - if I didn’t trust your code, I wouldn’t be using it at all. It’s a step removed from that, and comes down to two points:
- Reducing the need for blind trust through improved transparency is a good thing.
- Best practices are there for a reason. It’s difficult to defend exec(sudo …) in web-invokable php with the requirement to add the web server user to sudoers as a good practice.
Now, recognise that I am talking about legacy AdminLTE here - mainly because that’s what the install script seems to have installed in my test VM. I haven’t had a chance to look at the new web front end - that may well not suffer from any such potential issues.
One of the other things I’m working on is making sure that the packages I’m working on play nice with default SELinux policies on EL7, which I think will be of value to anyone wanting to run it on RH/CentOS/Fedora.
As for the packages - if you look under SRPMs, you will find that they contain sources, not binaries. The tarballs therein are as per the source tarballs that come from github. The only thing that is changed is the names of the directory in the tarball to make it a little more straightforward to build. All of the patches applied and additional files such as the service scripts are also included with the source. This is, IMO, more scrutinizable than curl | sudo bash, reading a large shell script (the rpm spec file is far shorter than the install bash script), or downloading binaries.
I’ll grant you that not deleting an ancient header from my index page was an oversight on my part. But I hope you also agree that there is merit to the issues I raised on this thread, most of which are mitigatable easily enough that I’ve been able to do it in a day.
Finally - apologies if I came across as disrespectful and/or abrasive. It was not intentional. Such is the difficulty of the typed medium. I am trying to help with changes that I think would benefit others. A handful of alterations in defaults and packaging can go a long way.