On 8 March 2018 at 12:22, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2018-03-07 23:07 GMT-03:00 Ben Coman <btc@openinworld.com>:
On 8 March 2018 at 02:38, Michael Forster <mike@forsterfamily.ca> wrote:
On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <btc@openinworld.com> wrote: [...]
If that is the one available from the Pharo Catalog, when I tried it,
it
used a different api than the libsodium library supplied by Ubuntu 16.04.
It makes this call out... crypto_hash_sha512_ref() but Ubuntu libsodium library did not export that, but instead... crypto_hash_sha512()
I failed to track down the implications of the "_ref", and at that time Crypto-Nacl did not supply a 64-bit library, so a single FFI matching the system supplied libsodium library was easier. Also as a minor policy, I prefer to use the system library than one compiled by a third-party.
cheers -ben [...]
Hi,
Yes, I recommend using the OS/package-manager supplied libsodium (based on https://github.com/jedisct1/libsodium). The downloads provided on Tony's site were based on early commits that exported the "_ref" functions instead:
commit e144f9d40d5695b69306bde729d6d8adcd62b1c4 Author: Frank Denis <github@pureftpd.org> Date: Mon Apr 22 16:30:31 2013 -0700
crypto_hash_sha(256|512) are the exported functions that have to be exported. _ref are implementations, that shouldn't be exported.
Thanks for clarifying that.
To be useful, http://smalltalkhub.com/#!/~tonyg/Crypto-Nacl/ should be updated to use a system-supplied libsodium.
Or at least to the later api. In general there is some advantage in packaging the C-lib with the Smalltalk package for people experimenting with it the first time, to ensure the function prototypes match. But flipping into production may prefer the system library. Currently it seems awkward to switch later to a system library since the library used is hard coded.
Hi Ben,
"system library" means it's pre-installed in some Linux distros?
I installed a Debian 4.9.65-3+deb9u1 (2017-12-23) last week and
libsodium is not present.
For Linux, system libraries are not only pre-installed, but rather whatever is available in the default system repository, simply installed with a single command like... $ sudo apt-get install libsodium All such installed packages receive security updates by doing... $ sudo apt-get update $ sudo apt-get upgrade I use Windows and also isn't available by default. Unfortunately Windows lacks a standard repository with a broad range of open source packages installable with a single command. Here it makes more sense to auto-install some package. Perhaps a particular version from the project https://download.libsodium.org/libsodium/releases/ In any case, how do you ensure libsodium system lib matches your interface
code?
What do you do now if target has a different version?
Good question. I guess its unit tests and manual effort. The next question is whether its worth the effort. For a given production environment, you might take a hit every couple of years when you move distro-versions. For a more turnkey system suiting a broader range of new users, maybe downloading a particular version of libsodium from the project site is a better option. Checking just now i see the Ubuntu 16.04 LTS libsodium library is version 1.0.8... https://launchpad.net/ubuntu/xenial/+package/libsodium18 which actually is unsupported... https://download.libsodium.org/libsodium/releases/old/unsupported/ so perhaps downloading from the project site is a better option. cheers -ben P.S. Did you indicate Crypto-Nacl was being (or could be) updated to latest libsodium? If it could, and the auto-installed library was downloaded and sig-checked from the project site, I'd be interested in dropping my own hack and using Crypto-Nacl.
How do others work around that?
Perhaps it would be good to have the external library initialized into an instance variable of FFILIbrary, so a user-application can change the external C-library used without changing code in someone else's ffi-interface package.
cheers -ben
P.S. On the dream list would be a GUI for managing referenced external C-libraries, including browsing their exported functions.
That would be really cool
Hernán