can we haz dynamic linking?

[dangowrt]

Especially on space-constraint systems (think: OpenWrt routers) it is desirable to use dynamic linking to avoid unwanted (source-/binary-)code duplication. I understand that having a libuv-fork included in cjdns makes sense when building for non-GNU systems such as Android, OSX or win32. As libuv is packaged on most GNU/Linux distributions, why not use the package instead or at least allow building with external libuv?

I also understand that djb intended NaCl to be statically linked-into projects. Furthermore, afaik the NaCl-fork included in cjdns contains some (cjdns-specific?) improvements. However, libsodium could be used as "external NaCl". Again, do you believe it could be feasible to optionally build against "external NaCl" (i.e. libsodium)?

@cjdelisle: I'd by thankful to read a line or two about the (supposedly good) arguments you had in mind when deciding to use static linking and maintaining your own fork of all libraries used in cjdns.

[sdgathman]

I now build against libnacl dynamic library on Fedora. It seems to work fine. If any of the cjd enhancements affect security (as opposed to performance), I need to petition Fedora for an exemption to the prohibition against embedded libraries.

I think, however, that I will add an option to the source rpm to use the embedded libraries. That way, savy users can get the cjd enhancements (and I know at least some customize the code to the platform to enhance performance) by simply rebuilding the source rpm.

[cjdelisle]

@dangowrt couple of issues.

1. When I started cjdns, libsodium was a bit of a joke, if you wanted nacl you needed to use it.
2. Libsodium does not use the fastest implementations for each processor, instead it uses a single implementation which works on everything.
3. Cjdns/NaCl has a poly1305 implementation for mips32r2 processors which doubles the packet forwarding speed... It's written in assembly so it will never end up in Libsodium and probably not in the OpenWRT nacl.
4. Dynamic linking opens up some various types of security bullshit see: https://startpage.com/do/search?q=dynamic+linking+exploit
5. How much space savings it is really ? (is it even net-positive if there are no other applications using nacl?)
6. The more stuff which is external to cjdns that cjdns relies upon, the more possibility for bugs which only happen on certain systems. I program with the assumption that the environment is hostile. For example cjdns has it's own random generator, after what happened with Debian OpenSSL, I would immediately -1 any attempt to replace that with a dynamically linked source of random. Basically the nacl that I use on my laptop matches the one that you use and that makes the safety of cjdns easier to validate. When there is a big major security vulnerability and it is exposed, everyone is going to point at the one feature which caused it and say "ho ho ho, that was stupid!" but until that day comes, everybody is going to push and push for more features, more edge cases, more things which don't work for the original vision and every one that I let by will make the security model a little more complex, a little more nuanced and a little more difficult to validate. Until the day when one of them finally bites us.

For what this claims to bring, I don't see value worth the pain it (and other features like it) will cause in the long term.

[sdgathman]

FWIW, Fedora concerns over embedded libraries have nothing to do with space savings (they often don't actually save anything), but security and support. For instance, when an exploit or bug is found for a library, they like to be able to push a fix that fixes all apps using the library. There are a few packages that have embedded libraries, and they have to be separately patched, rebuilt, and pushed. So they want to keep the list of packages with embedded libraries as small as possible. Whatever the decision of Fedora committees, I will add a "embedded_nacl" flag to the SPEC, so that users can easily rebuild to get the enhanced library.

[dangowrt]

On Sun, Nov 08, 2015 at 02:34:04PM -0800, Caleb James DeLisle wrote:

@dangowrt couple of issues.

1. When I started cjdns, libsodium was a bit of a joke, if you wanted nacl you needed to use it.

Ok. Is there a way to dynamically link against NaCl?

1. Libsodium does not use the fastest implementations for each processor, instead it uses a single implementation which works on everything.
2. Cjdns/NaCl has a poly1305 implementation for mips32r2 processors which doubles the packet forwarding speed... It's written in assembly so it will never end up in Libsodium and probably not in the OpenWRT nacl.

Why?

1. Dynamic linking opens up some various types of security bullshit see: https://startpage.com/do/search?q=dynamic+linking+exploit
2. How much space savings it is really ? (is it even net-positive if there are no other applications using nacl?)
3. The more stuff which is external to cjdns that cjdns relies upon, the more possibility for bugs which only happen on certain systems. I program with the assumption that the environment is hostile. For example cjdns has it's own random generator, after what happened with Debian OpenSSL, I would immediately -1 any attempt to replace that with a dynamically linked source of random. Basically the nacl that I use on my laptop matches the one that you use and that makes the safety of cjdns easier to validate. When there is a big major security vulnerability and it is exposed, everyone is going to point at the one feature which caused it and say "ho ho ho, that was stupid!" but until that day comes, everybody is going to push and push for more features, more edge cases, more things which don't work for the original vision and every one that I let by will make the security model a little more complex, a little more nuanced and a little more difficult to validate. Until the day when one of them finally bites us.

Sounds like you're about to fork NaCl in a way that might be useful for users other than cjdns...? Similar to the gnurl vs. curl debate...

For what this claims to bring, I don't see value worth the pain it (and other features like it) will cause in the long term.

I see that pushing all the added-optimization upstream to either NaCl or libsodium would take a while. In the meantime, we'll have to live with the embedded library.

Last but not least: What about libuv?

[Kubuxu]

@dangowrt libuv still didn't add features required to handle TAP device on Windows. https://github.com/libuv/libuv/pull/484

[chpio]

can we use libsodium instead of nacl? is there a build command for this? it would be a nice thing to have, especially because i'm using cjdns only in a docker-ized environment and libsodium should (?) perform better in cross-compile environments (runtime vs compile time selection of the crypto primitives).

[sdgathman]

On 05/26/2016 12:27 PM, chpio wrote:

can we use libsodium instead of nacl? is there a build command for this? it would be a nice thing to have, especially because i'm using cjdns only in a docker-ized environment and libsodium /should/ (?) perform better in cross-compile environments (runtime vs compile time selection of the crypto primitives).

The official Fedora/EPEL cjdns packages use libsodium on f22,f23. The SRPM has flags to choose between dynamic nacl, dynamic libsodium, or embedded nacl. The SRPM has patch files to tweak the build for dynamic nacl or libsodium.

[chpio]

@sdgathman thank you.

so i tested libsodium and the embedded nacl impl. libsodium seems to be 5% slower than nacl (tested with cjdroute --bench, don't know if this is a "valid" test).

my sodium patch (based on http://pkgs.fedoraproject.org/cgit/rpms/cjdns.git/tree/cjdns.sodium.patch)

[chpio]

i updated from debian's libsodium to the current version (v1.0.10) and the bench speed went up by 15-20% compared to nacl.

[cjdelisle]

This is one of the reasons why closed platforms like windows and mac are so much more stable than linux. The .exe file you get is the exact same code the developers tested.