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

[Clemens Lang]

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.

> But because certsync synchronizes with the system certificates, it means users with custom (e.g. corporate) certificates can use them, which curl-ca-bundle doesn’t have a provision for.

That is actually not correct. I recently tried to add an intermediate to my system keychain and mark it trusted as root, but certsync didn’t export it (even though I expected it to) for a number of reasons:
- Even though certsync walks through both the “System” and “System Roots” keychain to find certificates, it only exports those from “System Roots”, because of what I think is a simple oversight: Around line 322, the NSEnumerator that it being looped over to export the certificates is created from [results objectEnumerator] rather than [anchors objectEnumerator] as it should.
- certsync validates whether a certificate is trusted when the set of root certificates is only the certificate itself. That was introduced to avoid exporting expired certificates (because the check will fail on expired certs), but it also filters out any intermediate certificates I’d like to export because I added them using `security add-trusted-cert -d -r trustAsRoot -p basic’. I’m attaching a patch that fixes the two problems mentioned by checking the certificate expiry directly – I however don’t know whether this code is backwards compatible, since I only tested on 10.9.

There even is yet another problem with certsync at the moment: To mark certificates that are in the “System Roots” keychain as untrusted, Keychain Access adds the same certificate to “System” and marks it as untrusted. I have done so for a series of roots issued by the Chinese, US or Turkish government and DigiNotar. However, these certificates are still being exported. They properly fail to validate while processing the “System” keychain, but “ValidateSelfTrust” happily returns YES when processing the “System Roots” as if I hadn’t distrusted the certificates. I think instead of checking whether a certificate is trusted when the root cert set only contains itself, certsync should instead check whether a certificate is trusted by the current set of roots as configured in the “System” and “System Roots” chains before exporting it. I tried to get that implemented, but failed (due to lack of experience with the SSL API offered by Security.framework).

> So neither port is perfect right now, and I’m not aware of anything being done to fix either of them.

If certsync worked on Tiger and Leopard, it would be the best way to go at the moment. The expired roots in the system certificate store on Tiger and Leopard is a problem MacPorts shouldn’t attempt to solve for users. We should not try to tell users which certificates they trust (that’s the whole point of certsync, because so far we made MacPorts software trust all roots from curl-ca-bundle, and users might not want to do that!).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: certsync.m.patch
Type: application/octet-stream
Size: 2119 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140430/a6b641d5/attachment-0001.obj>