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 <ryandes...@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. > >
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
