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