As 3.0 format packages are now allowed into the archive, I am thinking
about what I would like the workflow to look like and hoping one of
them fits me.
For new upstream releases, I am imaginging something like:
- New upstream version is released.
git fetch + merge into upstream branch.- Import tarballs, preferably in their original format (bz2/gzip),
using
pristine-tar.
- Merge upstream to debian branch. Do necessary fixups and
adjustments. At this point, the upstream..debian branch delta is
what I want to apply to the upstream release. The reason I need
to apply this delta is so I get all generated files into the
package that's built and uploaded.
The source package has two functions at this point: Be a starting
point for further hacking; and be the source that buildds use to
build the binary Debian packages.
For the former, I need the git repository itself. It is
increasingly my preferred form of modification and so I consider
it part of the source.
For the latter, it might be easiest just to ship the
orig.tar.{gz,bz2} and the upstream..debian delta. This does
require the upstream..debian delta not to change any generated
files, which I think is a fair requirement.
I'm not actually sure which source format can give me this. I think
maybe the 3.0 (git) format can, but I haven't played around with it
enough to see. I also don't know if any tools actually support this
workflow.
Back at the Debian barbeque party at the end of August, I got myself
an EntropyKey from the kind folks at Simtec. It has
been working so well that I haven't really had a big need to blog
about it. Plug it in and watch
/proc/sys/kernel/random/entropy_avail never empty.
However, Collabora, where I am a sysadmin also got one. We are using
a few virtual machines rather than physical machines as we want the
security domains, but don't have any extreme performance needs. Like
most VMs they have been starved from entropy. One problem presents
itself: how do we get the entropy from the host system where the key
is plugged in to the virtual machines?
Kindly enough the ekeyd package also includes ekeyd-egd-linux
which speaks EGD, the TCP protocol the Entropy Gathering Daemon
defined a long time ago. ekeyd itself can also output in the same
protocol, so this should be easy enough, or so you would think.
Our VMs are all bridged together on the same network that is also
exposed to the internet and the EGD protocol doesn't support any kind
of encryption, so in order to be safe rather than sorry, I decided to
encrypt the entropy. Some people think I'm mad for encrypting what is
essentially random bits, but that's me for you.
So, I ended up setting up stunnel, telling ekeyd on the host to
listen to localhost on a given port, and stunnel to forward
connections to that port. On each VM, I set up stunnel to forward
connections from a given port on localhost to the port physical
machine where stunnel is listening. ekeyd-linux-egd is then told to
connect to the port on localhost where stunnel is listening. After a
bit of certificate fiddling and such, I can do:
# pv -rb < /dev/random > /dev/null
17.5kB [4.39kB/s]
which is way, way better than what you will get without a hardware
RNG. The hardware itself seems to be delivering about 32kbit/s of
entropy.
My only gripes at this point is that the EGD implementation could use
a little bit more work. It seems to leak memory in the EGD server
implementation. Also, it would be very useful if the client would
reconnect if it was disconnected for any reason. Even with those
missing bits, I'm happy about the key so far.
