3 ms·
"Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems: * the fork will lag behind when new feat
by _pmf_ 13y ago
"Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems:
* the fork will lag behind when new features are introduced into OpenSSL
* the fork will lag behind when new fixes for OpenSSL are implemented
This creates a permanent maintenance burden for the LibreSSL maintainers; sure they have attention now, but in 3 months nobody will give a shit any more.
- rlpb 13y agoUnless the rest of the world switches to using LibreSSL by default, (eg. for security reasons). Then the situation could reverse. Given the state of the OpenSSL codebase, I think this has a greater chance of happening than most other forks.
- _cipher_ 13y ago> "Fixing" it in a way that guarantees that the changes will not be pulled back into OpenSSL has the following problems: > * the fork will lag behind when new features are introduced into OpenSSL > * the fork will lag behind when new fixes for OpenSSL are implemented > This creates a permanent maintenance burden for the LibreSSL maintainers; sure they have attention now, but in 3 months nobody will give a shit any more. So, it's gonna be apache all over again. Where they maintained their own fork, with no security patches applied. Or perhaps like OpenSSH, where a linux user is forced to `./configure && make && make install'. I'm trusting your opinion, after careful reviewing of all your commits. :) /irony off