On 8 March 2018 at 12:22, Hernán Morales Durand <hernan.mora...@gmail.com> wrote:
> 2018-03-07 23:07 GMT-03:00 Ben Coman <b...@openinworld.com>: > > > > > > On 8 March 2018 at 02:38, Michael Forster <m...@forsterfamily.ca> wrote: > >> > >> On Fri, Mar 2, 2018 at 9:40 PM, Ben Coman <b...@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 <git...@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 > >
