3 ms·
OpenSSL is part of the OS as far as users are concerned. It's right there after installation, in /usr/bin/openssl and in /lib64/libcrypto.so.3. Applications nor
by rhn_mk1 4y ago
OpenSSL is part of the OS as far as users are concerned. It's right there after installation, in /usr/bin/openssl and in /lib64/libcrypto.so.3. Applications normally just pick it up. And indeed it does not prevent applications from shipping it separately.
But, depending on the OS you're using, the organization is not necessarily well-funded. Even those who are and use OpenSSL (Red Hat) haven't caught this one.
I assume that you're not mixing up "OS" and "kernel", because adding more attack surface to a monolithic kernel is never a good idea.
- 0xbadcafebee 4y agoI mean the kernel. But there's a lot of different ways to implement this functionality. The kernel already has a variety of crypto baked in, it's just a matter of deciding on the implementation, which doesn't have to be 100% in-kernel. The point is to offload the maintenance onto a team that is better staffed and has better development practices, and possibly also add additional functionality to existing syscalls.
- rhn_mk1 4y agoI think those are two separate problems. When you want to benefit from a process (better staffed project), you don't need to impose technical conditions (make something part of syscalls). While the Linux kernel doesn't publish userspace OS components (I imagine there's overlap with projects like glibc), I believe Windows "kernel" is composed of many pieces, including some running in userspace, and that would be the organizational entry for your idea.
- yakubin 4y agoLinux kernel publishes util-linux, iproute2 and perf at the very least. I don’t see why they couldn’t publish an so.