[119549] trunk/dports/irc/weechat/Portfile

[Landon J Fuller]

Howdy --

Thanks for the patch; I'll have time to look at it this weekend, but if you feel comfortable with committing it prior to review, I'm happy to have another set of capable hands maintaining the code.

More below.

On Apr 30, 2014, at 5:59 AM, Clemens Lang <cl at clang.name> wrote:

> Hi,
> 
> On 30.04.2014, at 10:26, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
>> The plan was to default to certsync after the problems had been ironed out, and for a brief time, they were, but then an update to certsync made it incompatible with Leopard and Tiger, and since it synchronizes with the system certificates, which on Leopard and Tiger are quite outdated, there’s concern that users of older systems would not be able to access web sites secured by newer certificate authorities, or those who have had to replace their certificates (e.g. due to heart bleed).
> 
> I think we agreed that we weren’t going to get in the business of distributing our own certificate bundle for OS versions that have run out of support? The problem you’re outlining (users on Leopard and Tiger not being able to access some websites via SSL) is going to stay a problem for them even with curl-ca-bundle, because most software uses the system certificate storage. Users on these systems will either have to manually update their certificate storage or upgrade to a newer version.

Agreed. Additionally, I'm not sure we can reasonably support pre-10.6 systems without developers that are willing to chip in. The API differences are substantial enough that modern code simply will not build and run, and the APIs that are supported are deprecated on newer systems.

I went to lengths to support 10.4 initially, including binary patching the Tiger kernel so I could run Tiger in VMware (http://landonf.bikemonkey.org/code/macosx/Virtualizing_Tiger_On_Modern_CPUs.20131217.html), but given the eternal problem of having too much to do and not enough time to do it, I can't justify the amount of effort supporting pre-10.6 takes.

I think we can proceed one of two ways:

If anyone relying on <= 10.5 is willing to help maintain certsync, then we can continue to ship certsync as the default. I've been working on a pkcs11 replacement for certsync that allows for live fetching (via pkcs11) of CA certificates, rather than writing out to a PEM file; it might be that older systems continue to use the simpler certsync daemon and it changes little, while newer systems switch to pkcs11-based cetificate handling.

As Clemens noted regarding stale certificates, this is a system-wide problem; I'd suggest that this either by solved:
	- Externally to MacPorts, eg, by providing an installer package that includes up-to-date CA certs for the System keychain, or
	- With a new port (or a subport of certsync) that uses the certsync code to inject updated certificates into the System keychain on legacy systems for which Apple provides no support.

Alternatively, if nobody has the time or inclination to support certsync for <= 10.5, then we could modify the certsync port to provide curl-ca-bundle's certificates for older systems, and use actual synchronization on newer systems.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140501/7a322eb2/attachment.sig>