Skip to content

io.js-v2.0.0 fails with libressl #1622

Description

@Gottox

It seems, that libressl removed a few functions used in iojs-v2.0.0. Version 1.6.2 works fine. I haven't test other versions.

See this output for more info:

https://gist.github.com/4199d35343200e58a5d7

System: VoidLinux
Linux: 4.0.1
LibreSSL: 2.1.6_3
io.js: 2.0.0

Activity

  1. bnoordhuis commented on May 5, 2015

    @bnoordhuis
    Member

    I'm going to close this because we don't pretend to support libressl, or anything besides the bundled openssl. Thanks for filing a bug report though.

  2. Fishrock123 commented on May 5, 2015

    @Fishrock123
    Contributor

    @Gottox that being said, the reason is probably because we switched to openssl 1.0.2a. If libressl has a compatible version for that, it may work. No guarantees.

  3. Gottox commented on May 5, 2015

    @Gottox
    Author

    Thanks for this clarification!

  4. hasufell commented on May 14, 2015

    @hasufell

    or anything besides the bundled openssl.

    Bundling security relevant libraries is inherently insecure and usually causes distro developers to diverge from upstream by unbundling them.
    Figuring out the vulnerabilities of 300 local copies of e.g. zlib is simply impossible system-wide. It also means that updates to the bundles libraries are a lot slower, because they are tied to your releases. As such, there is nothing that can make the user force to update to a non-vulnerable openssl version if he's running iojs vanilla outside of the packagemanager.

  5. jbergstroem commented on May 14, 2015

    @jbergstroem
    Member

    @hasufell That's one of the reasons iojs allows packagers/users to distribute their own openssl by passing --shared-openssl.

  6. hasufell commented on May 14, 2015

    @hasufell

    That's one of the reasons iojs allows packagers/users to distribute their own openssl by passing --shared-openssl.

    Then I cannot understand why you say "we don't support it". It's important to support it.

  7. bnoordhuis commented on May 14, 2015

    @bnoordhuis
    Member

    The burden of support falls on the packagers, them being the only ones linking to shared libraries. The shared library support was originally contributed by packagers.

  8. rvagg commented on May 14, 2015

    @rvagg
    Member

    it is something we've discussed testing in our CI cluster, but until that happens we can't claim to support it officially because we simply don't know from release-to-release if it still works

  9. envygeeks commented on Aug 1, 2015

    @envygeeks

    Well I hope you never plan to get packaged by Debian since your software is broken there too.

  10. added a commit that references this issue on Oct 5, 2018
  11. added a commit that references this issue on Oct 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions