4 ms·
I believe that what you describe is the remaining argument in favor of dynamic linking. That said, I'd like to point out that it is convenient for the develope
by deweerdt 12y ago
I believe that what you describe is the remaining argument in favor of dynamic linking.
That said, I'd like to point out that it is convenient for the developer - since customers are ultimately interested to know if your software is vulnerable, and you'll have to explain how the vulnerability affects it -.
It's also a double edged sword: openssl has a good ascending compatibility record, but that can't be said about all user space libraries. IOW, it's tricky to guarantee that your software will work flawlessly across all the incarnations of CentOS 6.x, if you have a lot of external dependencies, for example.
- danieldk 11y agoIOW, it's tricky to guarantee that your software will work flawlessly across all the incarnations of CentOS 6.x, It's not so tricky, since Red Hat specifies nowadays what guarantees can be expected for what packages: https://access.redhat.com/articles/rhel-abi-compatibility#Appendix https://access.redhat.com/articles/rhel-abi-compatibility#Ap...
- pjc50 11y agoDynamic linking is required for anything resembling a plugin architecture (such as PAM).
- wtbob 11y agoNot really—one could use processes and some form of IPC (shared memory, pipes, whatever). The efficiency could be pretty bad, but the safety and reliability could be better.
- JoachimSchipper 11y agoIn fact, OpenBSD delegates logins to a login_<foo> binary, e.g. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/login_yubikey.8?query=login&apropos=1 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/.... That works. OpenBSD's system is not as flexible as PAM, with the attendant upsides and downsides.
- bandrami 11y agoYeah. There's a reason I stick with OpenBSD. I have absolutely no need for my authentication system to be "flexible".