Configuring MacPorts to work via a proxy

[Ryan Schmidt]

On Sep 9, 2018, at 13:49, Andrew Luke Nesbit wrote:

> I am preparing to install and configure MacPorts on a new machine that
> has been supplied by my employer.  It will be used in a corporate
> network with strict access controls between the intranet and the Internet.
> 
> The only option is to configure MacPorts to use HTTPS through the
> official proxy.  The proxy mediates TLS connections using a MITM
> approach.  MacPorts and its subtools need to be able to find the root
> certificate, which is officially available for installation where required.
> 
> I checked the macports.org website today but I couldn't find
> instructions on how to do this.  Also, since I last configured MacPorts,
> it has moved from Subversion to GitHub.
> 
> Does anybody have any information that could help me?
> 
> I found a placemarker for an unwritten HOWTO at
> https://trac.macports.org/wiki/howto .  I would be happy to help write
> this document, or at least to get it started.
> 
> Any help would be appreciated.  Thank you!!
> 
> Andrew
> 
> P.S. Background context and past experience is as follows.
> 
> On my previous machine, I was able to configure MacPorts so that `port
> sync` worked well over SVN+HTTPS and most port installations worked
> properly.  I was never able to get `port selfupdate` working because
> rsync is blocked.

"port selfupdate" still can only use rsync for updating MacPorts base. If rsync is blocked on your network, you will not be able to use selfupdate, and will need to update MacPorts manually when a new version of MacPorts is released, such as by downloading and running the installer from our web site.

"port sync" has many communication methods available; hopefully one of them works for you.


> This was a couple of years ago.  Configuration was a complex and
> time-consuming job due to the constrained environment and lack of
> documentation.  I eventually got a mostly-working setup by aggregating
> information from blog posts, Subversion documentation, other
> documentation, and Stack Exchange.

I am not familiar with proxies that perform man-in-the-middle attacks on ssl connections. But if you found a way to make it work with svn+https before, hopefully the same methods would work with git+https now. GitHub even offers svn access to git repositories, so if for some reason your method only works with svn, you can probably still use that now that we're on GitHub.