fooinha
README update
The README mentions using master OpenSSL version. There's been recent OpenSSL release (prompted by security vulnerability) - perhaps it can be used instead of master branch to simplify maintenance a bit?
Not sure if I understand.
This repository has a patch to be applied to OpenSSL, and the user must apply the patch on a source code version that is compatible.
The patch has to be updated if OpenSSL changes its source code.
I've followed OpenSSL vulnerability and it's related certificate validation and email addresses with special unicode chars, only exploitable in very specific circumstances.
That's my point exactly: if the patch for OpenSSL is against particular released version than it doesn't have to be updated any longer. If it's against master branch than the patch have to be regularly updated requiring extra maintenance efforts.
@zabbal , generally speaking I'm all in favour of the suggested approach. The drawback is that I think that the dependant project - in this case, this one - should keep pace with regularly updated releases if any security or critical issue happens in the dependency.
If we lock to a specific OpenSSL version here, we might also "lock" users to a vulnerable version, until we either update the patch or the README.
In the past, for OpenSSL, we kept all patches for previous versions of OpenSSL, whenever we updated the patch ( which is not very common )
I'm not sure I'm following - if you set requirements for version X of OpenSSL in your release Y than it's not a lock-up, it's a common practice. If for any reason (including CVE) you need to bump dependency version to X2, you just make release Y2. You've got to do it from time to time anyway.
Having explicit version numbers makes maintenance much more predictable.