3 ms·

surprised that even after the 'goto fail' story people still write code in this questionable style LibreSSL didn't spring into existence out of whole cloth. It

surprised that even after the 'goto fail' story people still write code in this questionable style LibreSSL didn't spring into existence out of whole cloth. It started as a fork of OpenSSL, which goes back to 1998. The "questionable style" is from legacy code. It would be a massive effort to revise the entire codebase. And if LibreSSL did that, it would make it harder to import changes from OpenSSL and from other forks such as BoringSSL.

technion 9y ago
The code style in question is the current recommendation in the systemd style guide - a much more current project, and a rule that was put in place in 2014. https://github.com/systemd/systemd/commit/61f33134fc9231e07e1b9519b140d68139e9fad0#diff-cae545c4578eed1a167d69fb6d3b806bR82 https://github.com/systemd/systemd/commit/61f33134fc9231e07e... I'm all for blaming legacy but this is unfortunately still a trend.
kbenson 9y ago
> it would make it harder to import changes from OpenSSL When it's a choice between making it easier to import changes or harder to import bugs, I know which one I think is more important when dealing with a security library.
- askmike 9y ago
  I don't think you see the amount of work that would go into refactoring a project of this scale whilst keeping up with the latest patches from upstream.
  - kbenson 9y ago
    I do understand the the amount of work, but that wasn't the only argument presented. It was also presented as making it harder to accept patches. Since one of the goals of LibreSSL is to start applying security best practices, and one of the reasons for its existence is the poor quality and recurrent problems with OpenSSL, keeping compatibility with OpenSSL to make it easier to accept patches should be very low on the list of priorities. Put another way, if you forked because upstream was crap, not changing because it makes it easier to accept upstream patches is a poor reason not to change something that might benefit from it.
    - treebeard901 9y ago
      I tend to agree, maybe with one exception. Would the end result of a LibreSSL refactor introduce more bugs than leaving the current process in place (with improvements)? It seems like we can't know the answer to that question until it happens so speaking definitively about either option becomes questionable.
      - kbenson 9y ago
        Definitively, no, but the lack of of a definitive (or even likely) answer still makes the it a poor choice, if not in the sense of "wrong" than in the sense of "this is something that needs to be figured out based on your goals, and until you do choices based on this will not be grounded on fact" so it's poor in that it's not well grounded. That said, the relatively poor history of OpenSSL and the relatively high quality of software that comes out of the OpenBSD project leads me to think I know what the likely outcome of refactoring code is in this particular scenario.
        treebeard901 9y ago
        That is certainly true and perhaps another advantage exists from a refactor of LibreSSL: Finding unknown bugs in OpenSSL that may only be revealed during refactoring.
euyyn 9y ago
> it would make it harder to import changes from [...] BoringSSL. BoringSSL doesn't use that style: https://boringssl.googlesource.com/boringssl/+/master/ssl/s3_both.c#268 https://boringssl.googlesource.com/boringssl/+/master/ssl/s3... There's no need to revise the entire codebase either, just fix the lines you touch, and don't introduce new cases like in that commit.

technion 9y ago

The code style in question is the current recommendation in the systemd style guide - a much more current project, and a rule that was put in place in 2014. https://github.com/systemd/systemd/commit/61f33134fc9231e07e1b9519b140d68139e9fad0#diff-cae545c4578eed1a167d69fb6d3b806bR82 https://github.com/systemd/systemd/commit/61f33134fc9231e07e... I'm all for blaming legacy but this is unfortunately still a trend.

kbenson 9y ago

> it would make it harder to import changes from OpenSSL When it's a choice between making it easier to import changes or harder to import bugs, I know which one I think is more important when dealing with a security library.

askmike 9y ago
I don't think you see the amount of work that would go into refactoring a project of this scale whilst keeping up with the latest patches from upstream.
- kbenson 9y ago
  I do understand the the amount of work, but that wasn't the only argument presented. It was also presented as making it harder to accept patches. Since one of the goals of LibreSSL is to start applying security best practices, and one of the reasons for its existence is the poor quality and recurrent problems with OpenSSL, keeping compatibility with OpenSSL to make it easier to accept patches should be very low on the list of priorities. Put another way, if you forked because upstream was crap, not changing because it makes it easier to accept upstream patches is a poor reason not to change something that might benefit from it.
  - treebeard901 9y ago
    I tend to agree, maybe with one exception. Would the end result of a LibreSSL refactor introduce more bugs than leaving the current process in place (with improvements)? It seems like we can't know the answer to that question until it happens so speaking definitively about either option becomes questionable.
    - kbenson 9y ago
      Definitively, no, but the lack of of a definitive (or even likely) answer still makes the it a poor choice, if not in the sense of "wrong" than in the sense of "this is something that needs to be figured out based on your goals, and until you do choices based on this will not be grounded on fact" so it's poor in that it's not well grounded. That said, the relatively poor history of OpenSSL and the relatively high quality of software that comes out of the OpenBSD project leads me to think I know what the likely outcome of refactoring code is in this particular scenario.
      - treebeard901 9y ago
        That is certainly true and perhaps another advantage exists from a refactor of LibreSSL: Finding unknown bugs in OpenSSL that may only be revealed during refactoring.

euyyn 9y ago

> it would make it harder to import changes from [...] BoringSSL. BoringSSL doesn't use that style: https://boringssl.googlesource.com/boringssl/+/master/ssl/s3_both.c#268 https://boringssl.googlesource.com/boringssl/+/master/ssl/s3... There's no need to revise the entire codebase either, just fix the lines you touch, and don't introduce new cases like in that commit.