2012-01-05
Nailing down RPM epoch numbers
As I mentioned here, RPM package version numbers have three components: an 'epoch' number, the package's upstream version, and an RPM package release version. The epoch number is there because upstream developers sometimes change version numbers in ways that break RPM's normal version comparison algorithm, or just plain use odd version formats.
(For example, I believe there's at least one program that increments its version by adding another digit of π to the end of the version number. This makes perfect sense in a way, but is hard for RPM version comparison to cope with.)
In that other entry I wrote that the default epoch number was '1' (and then a commentator corrected me to say that it was '0'). Both of us turn out to be wrong. The default RPM versioning is to have no epoch number at all. A RPM package that does not specify an epoch number does not have an epoch of '0'; it has no epoch at all, which is displayed by RPM as '(none)'. A package with no epoch number is a lower version overall than any epoch number, even 0.
On all of the RPM-based machines that I have sitting around, no epoch is by far the most common epoch. The next most common epoch is actually '1', not '0'; one theory I have about this is that a lot of people who build RPMs also think that the default epoch is 0, so when they specify an explicit epoch to override the upstream version number they start from 1.
Across all of the packages that I have handy on my machines, the highest
epoch number is 50 (on aspell-en, on Fedora 14, Fedora 15, and Fedora
16). Other high epochs (on Fedora 16) are 32 (for bind's packages), 14
(tcpdump plus libpcap), and 12 (dhcp and aspell).
If you want to check your own RPM-based systems, appropriate rpm
commands are:
rpm -qa --qf '%{E}\n' | sort | uniq -c | sort -nr
rpm -qa --qf '%{E}:%{N}\n'
The first will show you a count of epoch numbers; the second will show you the epochs for all of your packages (so you can find, for example, the package or packages at epoch 50).
Disk encryption, backups, and your threat model
In response to my two entries on some of the problems with full disk encryption, several people have suggested that the answer is backups. At this point I want to note that the EFF's suggestion is specifically not just disk encryption on laptops, but disk encryption on every computer you own. Given this, we now get to talk about the threat model you want to assume, which is computer security terminology for 'what are you worried about and want to prevent?'
One fundamental security constant about backups is that backups need to be as well protected as what they're a backup of, since they are effectively another copy of it. There's no point in locking one copy in a safe if you are just going to leave the other copy out on the lounge table for anyone to read or take. Does this mean that backups also need to be encrypted (with the accompanying risks of total loss of the backups if the decryption key is lost)? That depends on your threat model.
One threat model is specifically concern about data on your laptop when you are out of what you consider a secure place (such as your home). You worry about your laptop being stolen, inspected at the border, and the like, but you don't worry about your laptop being stolen (or seized) while it's home. Another threat model is to worry about computers being stolen even if they are at home (or alternately in the office). In the first threat model, unencrypted backups at home are protected because you're assuming that your home is safe and secure in general. In the second threat model, your home is not secure; unencrypted backups sitting around your home are just as much a risk as an unencrypted computer.
(In an office, you might consider backups on a disk that is physically in your office area to be at risk while backups sitting on a server in the secured machine room to not be at risk, on the grounds that things not infrequently get stolen from offices but almost never from machine rooms.)
Since the EFF is telling people to use disk encryption on all machines, their threat model seems to be much closer to my second threat model than my first one. This means that you need either encrypted backups or some sort of secure in-the-cloud backups. Both have (extra) total loss scenarios over unencrypted backups, so they are not a complete cure for the drawback of disk encryption. You have perhaps reduced your risk but you have not eliminated it; you're still prioritizing non-disclosure over availability.
Sidebar: on requiring backups
If you believe that full disk encryption requires some form of backup in order to be viable, you implicitly believe that full disk encryption is not appropriate for the large portion of the computer-using public that doesn't back their machines up on a routine basis. This holds both for backing up all of the data and for backing up vital portions of metadata. The less obvious, easy, and automated such backups are, the fewer people the system is suitable for.
(Please note that blaming people when they predictably don't back up their machines is not solving the problem. Real security systems are designed for real people, not theoretical ideal ones.)