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

[Ryan Schmidt]

On Jun 24, 2015, at 5:10 PM, Christopher Ramos wrote:

> Hm, well I understand your point and, while valid, it's not relevant to my point. For one, I'm not referring to the problem with a user downloading malicious code or code that does something the user doesn't understand.

But yes you are. That is exactly what you are saying.


> Macports, like the Mac App Store, is *curated*; it's not the same thing as going to some fly-by-night website, downloading, and installing willy nilly.

MacPorts is curated, yes. We have verified, to some arbitrary degree, that the git software does what it's supposed to, and have added it to MacPorts (just as Apple has done similar verification and added git to OS X). Specifically, git is a program that (among other functions) downloads files from the Internet. What you do with git after having installed it with MacPorts (or OS X) is up to you, and is not MacPorts' (or Apple's) responsibility.


> A better analogy would be Mozilla hosting a FF add-on that, by proxy, interferes with the functionality of other add-ons.

No, that would not be an accurate analogy.

You can make an analogy where the Mozilla organization is like the MacPorts organization, the Firefox browser is like the MacPorts software, and Firefox add-ons are like MacPorts ports.

You can also make an analogy where the Firefox browser is like the git software, and any random webpage on the Internet that the Firefox browser might access is analogous to any random git repository on the Internet that the git program might access. Just as the Mozilla organization has no responsibility for the content of random webpages, so too the neither the creators of the git software nor the MacPorts organization has any responsibility for the content of random git repositories.

To make sure it's clear: when we say "git repository", we do not mean "repository hosted by the git organization" or "repository hosted by the git service" because no such service exists. Instead, we mean "repository in a format readable by the git program and available on any arbitrary server on the Internet, provided by any arbitrary person or organization".

Note that there *is* a service called "github". It is not related to the creators of the git software; it's merely a service that offers, among other things, a way to host git repositories.


> At this point, I'm not much concerned with any affect on my installation. I'm most interested in what more, if anything, can be done to protect a user's Macports installation.
> 
> Perhaps it would be feasible to employ an agent or daemon that logs all changes to a user's installation. That way, if it's ever bungled by an "outside force," the user could do something like "sudo port revert snapshot-06222015". This would remove any files not registered by the daemon to have been present at the time of the requested snapshot; if need be, previously installed or files (or files that were in a different state) would retrieved from the Internet.

We do definitely have a problem where users sometimes install things into the MacPorts prefix (not using MacPorts) that they should not install there. For example, they might manually compile software and instruct it to install into the MacPorts prefix, or they might run a pre-compiled installer that was itself built using MacPorts in its default prefix.

A daemon to detect such actions is an interesting suggestion. This could adversely affect performance. I'm also not sure how we would instruct the daemon what changes are ok and what changes aren't. For example, installing /opt/local/lib/libsomething.dylib without using MacPorts would not be ok, but creating /opt/local/etc/something.conf would probably be fine. Installing /opt/local/bin/something would be bad, but a database server installed with MacPorts that modifies the contents of /opt/local/var/db/something/ while it runs would be ok.