<div dir="ltr"><div>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.</div><div><br></div><div>A better analogy would be Mozilla hosting a FF add-on that, by proxy, interferes with the functionality of other add-ons.</div><div><br></div><div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Christopher David Ramos</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><a href="http://www.paxperscientiam.com/" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">www.paxperscientiam.com</a><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><a href="http://www.lnkdin.me/chris" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">www.lnkdin.me/chris</a><br></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 24, 2015 at 5:02 PM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Jun 23, 2015, at 10:03 PM, Christopher D. Ramos wrote:<br>
<br>
>> 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.<br>
><br>
> 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."<br>
><br>
> 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?<br>
<br>
</span>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?<br>
<br>
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?<br>
<br>
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?<br>
<br>
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?<br>
<br>
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?<br>
<br>
These are rhetorical questions, and the answer is no, we should not add such disclaimers.<br>
<br>
</blockquote></div><br></div>