[Availability]
The package is currently available in universe, currently imported directly from Debian with no Ubuntu specific patches.
[Rationale]
libsodium is a dependency of ZeroMQ, which in turn is a dependency of unity-scopes-api. Therefore, we will need to include it in main to support Unity 8.
[Security]
I couldn't find any CVEs or other advisories for the libsodium library, or djb's "nacl" library (http://nacl.cr.yp.to/) that it is derived from.
[Quality Assurance]
Package is a library, so not something end users will interact with directly. There are other apps and libraries in universe that currently link with libsodium, and install without issue.
The library asks no debconf questions on install.
Bugs are tracked in Debian and Ubuntu here:
https://bugs.launchpad.net/ubuntu/+source/libsodium
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libsodium
The one Ubuntu bug looks like it might be user confusion about -dev packages. The one Debian report is complaining about Debian packaging an old version of libsodium: something that seems to have since been fixed but not noted in the bug report.
New releases appear to be packaged in Debian promptly (https://packages.qa.debian.org/libs/libsodium.html), and the latest Debian release was recently migrated into Yakkety.
The package is a software crypto library, so doesn't rely on exotic hardware.
Library has a test suite that is run as part of the package build.
The package has a debian/watch file checking for new releases on github.
[UI Standards]
The package contains a non-graphical crypto library.
[Dependencies]
The libsodium18 binary package only depends on libc6. For source build-depends, there is debhelper, pkg-config, and dh-autoreconf. All are already in main.
[Maintenance]
The package currently lists ubuntu-devel-discuss as its maintainer. It doesn't look like we've ever made any changes to the versions of the package migrated from Debian though.
[Background information]
The package has reasonable description strings and hasn't been renamed recently. The source package name matches the upstream project name.
[ABI Stability]
The library is plain C, so should be fairly robust. The upstream developers committed to API and ABI stability with the 1.0.0 release (October 2014):
https://github.com/jedisct1/libsodium/releases/tag/1.0.0
A bit worryingly though, they changed soname in the 1.0.6 release (November 2015):
https://github.com/jedisct1/libsodium/releases/tag/1.0.6
The changelog seems to indicate that the release should have been compatible but they changed soname just to be sure. It is unclear whether this is likely to happen again.
I reviewed libsodium version 1.0.10-1 as checked into yakkety. This
shouldn't be considered a full security audit but rather a quick check of
maintainability. Furthermore this is not an audit of the fitness for
purpose of the cryptography in libsodium.
- No CVE history in our database
- libsodium provides a programmer- and packager-friendly library around
the NaCl family of cryptography APIs.
- Depends: debhelper, pkg-config, dh-autoreconf
- Does not itself do networking
- Extensive cryptopgrahy
- Does not daemonize
- No pre/post inst/rm
- No init scripts
- No dbus services
- No setuid files
- No binaries in the PATH
- No sudo fragments
- No udev rules
- A test suite is run during the build
- No cron jobs
- Clean build logs
- No subprocesses spawned
- Memory management is careful, perhaps to the point of picky; it has its
own routines that set up guard pages and provide byte-tainting of
objects.
- Does not itself do file IO beyond /dev/random or /dev/urandom
- No logging
- No environment variable use
- No privileged functions
- No networking
- No privileged portions of code
- No temp files
- No WebKit
- No PolKit
- Extensive cppcheck warnings; manual inspection of randomly selected
issues suggests failings in cppcheck.
libsodium's code is necessarily complicated; writing timing-resistant AES
is very difficult, writing timing-resistant GCM mode is very difficult,
and I wouldn't be surprised if there are going to be more flaws discovered
in both these code paths. The ECC, ChaCha20, and Poly1305 code certainly
requires expert advice to modify.
However, that said, the NaCl APIs are easier for application authors to
use properly than other cryptography libraries, and libsodium has the
combined support of the opensource cryptographic communities.
Security team ACK for promoting libsodium to main.
Thanks