Avoiding the issue with https and 'fetch.type svn'

[Rainer Müller]

Bryan Blackburn wrote:
> Ports which use 'fetch.type svn' and have an https URL (eg, tickets #17419,
> #18429, and possibly #18583) will quite likely fail for people in the fetch
> stage.  svn from the current subversion port (version 1.6.1) has the
> --trust-server-cert option to avoid this, but /usr/bin/svn on 10.5 is too
> old to have it.  Unless we are going to add subversion as a dependency for
> all ports setting svn as the fetch type, this is a problem.

This would be a simple solution. I think we can neglect entity
authentication as we are also not doing anything like that when using
rsync and HTTP/FTP.

> The maintainer of the flashdot port (Tobias Elze) mentioned one way this can
> be worked around in the Portfile, using "echo p | svn ls ${svn.url}" to get
> the cert accepted first.  So I added this in pre-fetch as a test and it
> works quite nicely.

Looks like quite a hack to me.

We are currently using svn --non-interactive which avoids being asked
any questions. So if we would like to use this approach, we would have
to drop non-interactive, too. I am not sure if there is a situation
where this could cause problems.

> This can obviously be added to any port needing it, or perhaps even to base,
> but is a bit kludgy overall; does anyone have any better ideas to fix this
> or shall we start updating some Portfiles?

Let me share some crazy idea :-)

We could ship a special Subversion config directory which already
contains accepted certificates for the hosts in question. It would be
used instead of ~/.subversion/ like this:

  svn --config-dir=${portresourcepath}/port1.0/fetch/svn/

Accepted certificates are stored in the auth/svn.ssl.server/ directory.
The filenames are hashes of the hostname/URL (?).

Pro:
 * Works with svn 1.4 as shipped with Leopard
 * No user config involved any more
 * Keeps some way of entity authentication

Contra:
 * Harder to maintain at a global place instead of per port
   (I don't believe many ports where we have seen this are using the
   same svn server, e.g. sf.net uses sub-domains)


Note that manually accepting a cert would still be possible with write
permissions on the port resource path (and adding the --config-dir
option), but it would be reverted at the next sync.

Adding a dependency on svn 1.6 from MacPorts would be an immediate fix.
Shipping a custom config with sync would require some changes to base
and would have to wait until the next release.

Rainer