[MacPorts] #47755: Broken symlink left by select code when selected port is deactivated causes poppler and other ports using aclocal to fail during configuration.
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
On Wed, Jun 24, 2015 at 5:02 PM, Ryan Schmidt <ryandesign at macports.org>
> 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,
> 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
> These are rhetorical questions, and the answer is no, we should not add
> such disclaimers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-users