Howdy all -- I think certsync is now ready to be relied on by default. Here's a brief status update:
- On-demand Launching:
I've updated certsync to launch via launchd on-demand when relevant files
change, rather than staying memory-resident. This eliminates any sort of
potential runtime cost; certsync was never large, but it doesn't hurt to not
have to run a daemon at all.
- Tiger Support
Tiger is now supported, although actually *running* Tiger turned out to be
harder than I expected. I don't have any hardware capable of running Tiger, so
I thought i could just bring it up in a VM. As it turns out, Tiger panics on
boot under a VM on more modern machines (eg, my nearly 3 year old iMac).
I wound up having to track down the 10.4 kernel bug in question and produced a
binary patch I could apply to xnu. If someone else needs to run a Tiger VM for
some instance, I've posted the background and the patch here:
http://landonf.bikemonkey.org/code/macosx/Virtualizing_Tiger_On_Modern_CPUs.20131217.html
In light of this, and the enormous number of API differences between Tiger and
Leopard, I'm not really sure maintaining Tiger support makes sense for
MacPorts, but I was able to make certsync work regardless.
- Next Steps
If things look good to everyone, I'd like to move all ports over to using
certsync as a certificate store, replacing curl-ca-bundle.
In addition, I've started extending certsync to vend a keychain-backed PKCS#11
plugin that can be consumed by p11-kit, Java's PKCS#11 implementation, NSS,
etc. This will provide even better integration for modern PKCS#11-aware
software. In theory, we should be able to migrate to a fully consistent
certificate store across all applications.
-landonf
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
