Comment 1 for bug 1621386

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