Apple has deprecated their OpenSSL distribution for some time now urging users to either bundle their own copy or switch to the Secure Transport framework. I wouldn't be surprised if they just drop it.
New versions of OpenSSL are in general source compatible with older versions. They are however not necessarily binary compatible. That means that you have to rebuild your program when going from OpenSSL 0.9.8 to 1.0.2 but in general without any source changes.
OpenSSL has an unusual version numbering where 0.9.7, 0.9.8, 1.0.0, 1.0.1 and 1.0.2 are different major versions. 0.9.7, 0.9.8 and 1.0.0 are binary incompatible but starting with 1.0.0 all 1.0.x releases have been binary compatible.
There is no Ubuntu LTS using one of the unsupported branches. Ubuntu 10.04 was the last one using the 0.9.8 branch and Ubuntu dropped support for it in April. Ubuntu 12.04 and 14.04 uses the 1.0.1 branch which is still supported by upstream.
OpenWRT uses OpenSSL 1.0.2e which is the latest version of the latest branch, so as long as you have updated you're fine.
https://dev.openwrt.org/browse...
I would guess most of those web sites are running on GNU/Linux with OpenJDK which is supported. Both OpenJDK 6 and 7 are still supported. It's only the binaries that you get from Oracle that aren't supported anymore, at least not without a support contract.
No, because it really is Let's Encrypt that signs the certificates, not IdenTrust. IdenTrust has only signed the intermediate certificates that allows Let's Encrypt to be trusted until their own root has made it into most trust stores.
They want to make them even shorter in the future. 90 days are fine now, so that sysadmins that aren't used to automate things like this can use it as well.
There are so many certs now that revocation isn't working as nice as it used to be. It used to be that the user-agent would actually download a complete list of revoked certificates to compare against. That's not really viable so OCSP is used instead. Short-lived certs simply it since we only need to care about revoked certs for a more limited time, and it also encourages automation.
The browser may not need more than 4 GB of memory but it sure wants the extra registers in 64 bit x86, and on ARMv8 you definitely don't want to power up the 32 bit module if you can avoid it.
You can't compile Chrome. The source code is locked up. You can compile Chromium, which is a free program that Chrome is based on. But Chromium is not affected, only the non-free program distributed by Google is.
Debian had some early issues when they switched to systemd in the testing distribution, the one that you are not supposed to run in production or anything that you think of as important. But of course that's what people did. I have used Debian 8 now for a while and never run into something like that.
That doesn't work. systemd throws away stderr as is its policy.
Is not reading the manual also a policy among sysadmins these days? Hint, it doesn't throw it away. Just tell it where it should go and it will go there.
Slashdot Mirror
Considering all university classes use MATLAB. Nice try to get kids indoctrinated to your shitty product though, bro.
We used GNU Octave in mine. But you could use MATLAB too if you wanted.
Problems? You can yum install it. https://rhn.redhat.com/errata/... But that's an old version. They are up to GCC 5 now.
GCC runs native on Windows. It's maintained by the mingw64 project and works really well.
Apple has deprecated their OpenSSL distribution for some time now urging users to either bundle their own copy or switch to the Secure Transport framework. I wouldn't be surprised if they just drop it.
New versions of OpenSSL are in general source compatible with older versions. They are however not necessarily binary compatible. That means that you have to rebuild your program when going from OpenSSL 0.9.8 to 1.0.2 but in general without any source changes. OpenSSL has an unusual version numbering where 0.9.7, 0.9.8, 1.0.0, 1.0.1 and 1.0.2 are different major versions. 0.9.7, 0.9.8 and 1.0.0 are binary incompatible but starting with 1.0.0 all 1.0.x releases have been binary compatible.
True, I somehow remembered it being released in 1999 but it was clearly around before then.
OpenSSL wasn't even around in 1998. OpenSSL 1.0.1 was released in 2012.
If you're talking about OpenSSL then you're off by a decade. 1.0.0 was released in 2010.
There is no Ubuntu LTS using one of the unsupported branches. Ubuntu 10.04 was the last one using the 0.9.8 branch and Ubuntu dropped support for it in April. Ubuntu 12.04 and 14.04 uses the 1.0.1 branch which is still supported by upstream.
OpenWRT uses OpenSSL 1.0.2e which is the latest version of the latest branch, so as long as you have updated you're fine. https://dev.openwrt.org/browse...
I would guess most of those web sites are running on GNU/Linux with OpenJDK which is supported. Both OpenJDK 6 and 7 are still supported. It's only the binaries that you get from Oracle that aren't supported anymore, at least not without a support contract.
No, because it really is Let's Encrypt that signs the certificates, not IdenTrust. IdenTrust has only signed the intermediate certificates that allows Let's Encrypt to be trusted until their own root has made it into most trust stores.
You don't need to use their software. It's an open protocol. They want more implementations of it.
I remember having to print out (yes, on paper) the CSR, sign it and send it by regular mail.
And one must install anew at least every 90 days. Wtf, this should be trivial but is instead a sysadmin project with high maintenace.
The idea is that you would automate it, so that the client automatically renews it within the 90 day window.
They want to make them even shorter in the future. 90 days are fine now, so that sysadmins that aren't used to automate things like this can use it as well.
There are so many certs now that revocation isn't working as nice as it used to be. It used to be that the user-agent would actually download a complete list of revoked certificates to compare against. That's not really viable so OCSP is used instead. Short-lived certs simply it since we only need to care about revoked certs for a more limited time, and it also encourages automation.
So inspect the code before you run it. It's open source, written in Python.
So, hands up. Who has ever forgot to renew a three year cert before it expired?
The browser may not need more than 4 GB of memory but it sure wants the extra registers in 64 bit x86, and on ARMv8 you definitely don't want to power up the 32 bit module if you can avoid it.
You can't compile Chrome. The source code is locked up. You can compile Chromium, which is a free program that Chrome is based on. But Chromium is not affected, only the non-free program distributed by Google is.
If it is almost the same then Google should cease this Chrome/Chromium dance and just make one browser and let it be free software.
There is no source tarball available. Chrome is a non-free program.
Debian had some early issues when they switched to systemd in the testing distribution, the one that you are not supposed to run in production or anything that you think of as important. But of course that's what people did. I have used Debian 8 now for a while and never run into something like that.
That doesn't work. systemd throws away stderr as is its policy.
Is not reading the manual also a policy among sysadmins these days? Hint, it doesn't throw it away. Just tell it where it should go and it will go there.