but it isn't "rolling your own" but changing the lib you use.

> The C++ programmer who needs to do an HTTPS POST but mostly is doing 3D graphics could spend a month learning about the Web PKI, AES, the X.500 directory system and the Distinguished Encoding, or they could just call OpenSSL and not care.

they gonna call libcurl, not openssl directly. Tho they might use it still for parsing certs but that's easier to replace

▲

Macha an hour ago | parent [-]

Pre all the recent OpenSSL forks the only other options were:

- use the platform sdks which have completely distinct APIs (and so probably aren't supported by everything between you and the TLS connection)

- Use GnuTLS which is GPL and so wasn't suitable for a lot of commercial uses (less important in the age of SaaS to be fair)

	▲	tialaramex 36 minutes ago \| parent [-]
		Also, the platform SDKs invariably assume platform preferred semantics which might not be what you wanted if you write cross platform software. In particular this means you get another source of platform difference, no only does your Windows App work with different peripherals from the Mac App (because of OS drivers), but now some certificates which work with the Mac App don't work in Windows or vice versa. OpenSSL lets you bundle your CA policies with the app and thus avoid that issue (though now it's your choice what is or isn't accepted and you're probably not ready for that labour)