[MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.

Christopher Ramos chrisdavidramos at gmail.com
Wed Jun 24 11:31:34 PDT 2015


"You can systematically avoid it by letting the operating system's
security do its thing: Don't use superuser privileges to build software,
and don't use them to install unless you know what it's going to do."

Wow, you know, wow. Now you have me wondering if I've gotten too
comfortable using sudo.

Christopher David Ramos
www.paxperscientiam.com
www.lnkdin.me/chris

On Wed, Jun 24, 2015 at 12:38 AM, Lawrence Velázquez <larryv at macports.org>
wrote:

> On Jun 23, 2015, at 11:03 PM, Christopher D. Ramos
> <chrisdavidramos at gmail.com> wrote:
>
> > That said, I don't think it's merely incidental.
>
> I assure you that it is.
>
> > After all, git is, in a sense, part of the Macports ecosystem by
> > virtue of a version of it being hosted by Macports. Is there not
> > a policy about hosting ports -- whether version control or other types
> > of software distribution mechanisms -- that may distribute projects
> > that ultimately harm a Macports installation?
>
> It would be one thing if Git were more akin to dpkg/apt or rpm/yum,
> which are proper systems for distributing software. Git is closer to
> rsync in this regard — basically a fancy downloader. It does far less
> than you seem to think it does. The important code here is the build
> system (the input to Autotools, Make, CMake, Ninja, SCons, whatever).
>
> > My reason for bringing up "/opt/local" was because I was wondering if
> > there was a chance that the makefile of some git project (or any other
> > project management system!) might instruct it (implicitly or
> > explicitly) to install under /opt/local.
>
> There is a chance, yes. A makefile author can write anything, and a Make
> process can do anything that the invoking user can do. You can try
> searching for "/opt/local" in the relevant configure script or makefile
> if you're curious.
>
> > And if so, how could this be systematically avoided.
>
> You can systematically avoid it by letting the operating system's
> security do its thing: Don't use superuser privileges to build software,
> and don't use them to install unless you know what it's going to do.
>
> vq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20150624/4d938347/attachment.html>


More information about the macports-users mailing list