I reviewed pollen version 3.6-0ubuntu1 as checked into trusty. This shouldn't be considered a full security audit, nor an audit of the design, but rather a quick gauge of code quality. - pollinate provides an entropy server and client, designed to combat low-entropy on systems after early install - The client runs at boot and periodically via cron - The server runs at boot - Build-depends upon autotools and friends - Server depends upon golang-go compiler, the pollen server is recompiled every time it is started - Server recommends haveged, pollinate, ent - Client depends upon run-one and curl - Client suggests pollen-server and ent - Uses Go's HTTPS libraries, server runs a self-contained web server - Server: - listens on configurable ports for TLS and non-TLS - runs as user root - Does not daemonize, expects to be managed with upstart or similar - Client: - Runs a script at boot and via cron to connect to servers using curl and store results into /dev/urandom - runs as user root during boot - runs as user daemon during cronjobs - Postinst scripts look broken, details below - Initscripts start server and client at boot - No dbus services - No setuid executables - 'pollen' and 'pollinate' binaries installed into /usr/bin - No sudo fragments - No udev rules - No test suite - Client supplies a cron file: - Runs randomly selected number of times per day, from 1440 to 24, to periodically reseed the client's entropy pool; slight bug. - Should not be needed - May present privacy intrusions beyond what would be welcomed by the user community - Build logs are clean -- compiles happen at run time - No subprocesses are spawned from the server; the client is a shell script, so spawns dozens, but the code looked clean - No real memory management; the server's http handler is quite small and allocates only stack memory - Files are written to -- /dev/urandom in both client and server; the server postinst creates a key and a certificate in /etc/pollen; the client postinst creates a unique machine identifier in /var/lib/pollinate/tag - Server-side logging stores the supplied User-Agent string verbatim without stripping or encoding newline and ] characters, which could complicate log analysis - No environment variables are used - No privileged operations as used - Encryption use is encapsulated in golang HTTPS support and curl - Certificate validation is left up to curl - There is no management of privileges - All temporary files explicitly managed by the programs are handled safely - No WebKit - No PolicyKit The code quality of pollen and pollinate is high; maintenance should be straightforward. There are a few small issues I'm reporting here because I know Dustin is eager for feedback and wants to address everything he can: - is dh_installinit functioning correctly? both pollinate and pollen postinst have sections like the following: [...] # Automatically added by dh_installinit if [ -x "/etc/init.d/pollen" ] || [ -e "/etc/init/pollen.conf" ]; then if [ ! -e "/etc/init/pollen.conf" ]; then update-rc.d pollen defaults >/dev/null fi invoke-rc.d pollen start || exit $? fi # End automatically added section # Automatically added by dh_installinit update-rc.d -f pollen remove >/dev/null || exit $? # End automatically added section - pollinate shell script, the order of -c and -i arguments matter -- give them in the wrong order and the arguments are lost - pollinate shell script, IPV6 variable unused - pollen.postinst generates a certificate with