"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.
> "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. :)
* 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.