Giters

lvh / caesium

Modern cryptography (libsodium/NaCl) for Clojure

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ristretto255 API is available in libsodium 1.0.18+ only

eploko opened this issue · comments

commented

While trying to fix linter errors on CI in #69 I happened to come upon the following in the CI logs:

== Linting caesium.crypto.core.ristretto255 ==
Exception thrown during phase :analyze+eval of linting namespace caesium.crypto.core.ristretto255
...
Caused by:
UnsatisfiedLinkError unknown
	jnr.ffi.provider.jffi.AsmRuntime.newUnsatisifiedLinkError (AsmRuntime.java:40)
	caesium.binding.Sodium$jnr$ffi$0.crypto_core_ristretto255_bytes (:-1)

Source: https://travis-ci.com/github/eploko/caesium/jobs/383426457

The API was just recently added to libsodium and thus is not present in the 1.0.16 version that is being targeted by the CI builds. What can/should we do about it?

An obvious solution would be to bump the target version on CI, but I'm not sure it's along the way this project was heading before the change. There are build steps for older versions of libsodium as well, which stumble on the unsatisfied linking issue too. What are your thoughts on a proper way to approach it all?

commented

Thinking about this a little further, I guess the main question is whether we strive to provide any kind of backward compatibility to older versions of libsodium or... maybe we could just outline what version of caesium corresponds to what version of libsodium in the docs... and that would be enough?

commented

There was a relatedish ticket about supporting multiple libsodium versions. I'm fine with the idea of just supporting only whatever features we support right now, and so forcing people to upgrade their libsodiums.

My solution to that in the past has been to ship libsodium debs for folks, but I haven't really kept up with it (because mostly OSes started shipping reasonable, recent libsodiums).

Another solution is to vendor libsodium, but I don't know offhand how to properly do that with jnr-ffi without some pretty extensive hacks. JavaCPP is better at that.

commented

Skimming through the previous issues only reveals #34 that talks about running tests on both 1.0.14 and 1.0.15.

Theoretically one could use an older version of libsodium with the current version of caesium as long as: a) one doesn't use any of the new APIs and b) the types of return values and/or arguments of the APIs one uses haven't changed between the old and the currently targeted libsodium versions.

The tests wouldn't run on old versions per se, though. It'll require some elaborate fiddling with the test suite to let only the corresponding tests to run against an older version. Which I frankly don't see any benefit in.

As for vendoring a crypto library, it seems strange from the security standpoint: say, I'd rather link to something I control the origin of and not some non-officially distributed binary. Add to that the fact jnr-ffi doesn't currently support bundling of native libraries (jnr/jnr-ffi#93 via #23), and we may cross this option out as well, I guess.

So, if it's alright with you, what I'll try to do as a part of #69 will be this:

  1. Get rid of the build matrix that targets old versions of libsodium on CI.
  2. Make CI run tests against 1.0.18 (the current libsodium version) only.
  3. Add a note to README re: the minimum required libsodium version.