On Fri, Jun 8, 2018 at 3:49 PM, Victoria Henry <vhenry@pivotal.io> wrote:
- I think the build instructions need to be more generic (particularly on macOS). For example, I do not use HomeBrew (largely due to some nasty security issues they had in the past). I was able to mostly port the instructions and build script over to work using MacPorts (without PyEnv) which actually turned out to be somewhat more simple than what's there now.
Since we don't use MacPorts, we cannot provide installation instructions.
FYI, I just tried Homebrew again to see if it has improved. It has not:
==> The following existing directories will be made group writable:
/usr/local/bin
/usr/local/include
/usr/local/lib
/usr/local/share
/usr/local/share/man
==> The following existing directories will have their owner set to dpage:
/usr/local/bin
/usr/local/include
/usr/local/lib
/usr/local/share
/usr/local/share/man
==> The following existing directories will have their group set to admin:
/usr/local/bin
/usr/local/include
/usr/local/lib
/usr/local/share
/usr/local/share/man
==> The following new directories will be created:
/usr/local/Cellar
/usr/local/Homebrew
/usr/local/Frameworks
/usr/local/etc
/usr/local/opt
/usr/local/sbin
/usr/local/share/zsh
/usr/local/share/zsh/site-functions
/usr/local/var
As anyone familiar with Unix system architecture could tell you, this is a horribly bad idea for a number of reasons:
1) It will break on any system used by more than one person - only the original installer (and possible members of the admin group) will be able to properly use brew.
2) It's changing the default (and correct) permissions on /usr/local/ to something they are not supposed to be.
3) It's making a directory that is in the path writeable by user other than root. This is a very bad idea as it means that any malicious software run by the user could place executable files there without the user's knowledge.
/usr/local/ is supposed to be a secure directory for very good reasons. We cannot start recommending our devs do something that compromises the security of their system to build pgAdmin, thus we need to figure out how to do this using MacPorts or some other similar technology that doesn't suffer from this problem.
I'm leaning towards the idea that having any build instructions that suggest using brew should be removed from pgAdmin entirely, to avoid putting users at risk.
