[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 15:10:08 PDT 2015


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.
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.

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

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.




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

On Wed, Jun 24, 2015 at 5:02 PM, Ryan Schmidt <ryandesign at macports.org>
wrote:

>
> On Jun 23, 2015, at 10:03 PM, Christopher D. Ramos wrote:
>
> >> Yes, that is what I was saying, where, again, by "git project", you
> mean "some software project that just so happens to do its development in a
> git repository". The use of git is incidental to the problem.
> >
> > Heh, I think I finally see where we are talking pass one another. I
> wholeheartedly agree with this: "some software project that just so happens
> to do its development in a git repository."
> >
> > That said, I don't think it's merely incidental. 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?
>
> MacPorts has ports for web browsers (QupZilla, lynx, links). You can use a
> web browser to download code from web sites, and if you compile and run the
> code it might be harmful to your computer. Indeed you could download
> already-compiled programs, which might be harmful. Should MacPorts add a
> disclaimer to all ports that install a web browser?
>
> We have ports for curl and wget, which can be used to programmatically
> download files from web and ftp sites, which again could harm your
> computer. Should we add disclaimers to those ports?
>
> In addition to the git port you've already encountered for accessing git
> repositories, we have the subversion, bzr, cvs and mercurial ports, which
> access different kinds of repositories, which are all just more ways of
> downloading code which, when run, could be harmful. Should we add
> disclaimers to those ports?
>
> MacPorts includes ports for a variety of programming languages: php, ruby,
> perl, python, javascript, c, c++, fortran, etc. It is possible to write
> malicious software in any of those languages. Should MacPorts add
> disclaimers to those ports?
>
> When you launch the Terminal application, it starts a program called a
> shell. The shell is what processes the commands you type. You could type a
> command that could harm your computer. MacPorts includes ports for several
> shells, including bash, tcsh and zsh. Should we add disclaimers to those
> ports?
>
> These are rhetorical questions, and the answer is no, we should not add
> such disclaimers.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20150624/c72cbf40/attachment.html>


More information about the macports-users mailing list