Anarchy In The UK

Posted: October 2nd, 2005 | Filed under: Uncategorized | No Comments »

Actually I really mean Liberty in the UK. Following my previous blog I went off and signed up as a member, making an additional sizable donation on top of the basic membership charge. I’m not going to sit by and watch this country turn into a police state, even given the horrors of terrorism showing themselves again in Bali this weekend. Charles Clark’s plans to outlaw the ‘glorification of terrorism’ will have sod all impact on terrorism, rather directly impacting on freedom of speech. All they could achieve would be to drive the ‘glorification’ further underground where it’ll be even harder to detect until it strikes again. Again, the only long term viable way to fight terrorism is to address the causes, rather than the symptoms. Sadly this isn’t a task which quick or easy results, thus isn’t all that ‘sexy’ for a politician looking for a quick win to illustrate how ‘tough’ on terrorism the government is.

A few (not so) recent tunes

Posted: October 2nd, 2005 | Filed under: Uncategorized | No Comments »

So over the summer i’ve been on a bit of a retro kick, picking up CD’s for INXS’ albums X and Kick, Texas’ Southside, a several by Nina Simone, and several more artists. And then (a year late to this particular party) I came across Franz Ferdinand’s self titled debut. The high energy songs really get you feeling good, and were just what I’ve been looking for recently. Best of all, their new album is out tomorrow, but for the rest of this evening its time for Elvis! Don’t ever say my musical tastes/moods are predictable :-)

Utterly unacceptable violation of personal liberties

Posted: September 27th, 2005 | Filed under: Uncategorized | No Comments »

This Guardian article highlights the utterly unacceptable violation of personal liberties taking place under the banner of ‘fighting terrorism’. If one puts aside the pathetic grounds on which police suspected David Mery of being a terrorist, what really makes me mad as hell is the fact the fact that even without any evidence of terrorist involvement, the Police will keep details of the arrest on their computers for ever more & happily share this information which countries around the world.

the police are not only entitled to keep my fingerprints and DNA samples, but according to my solicitor, they are also entitled to hold on to what they gather during their investigation: notepads of arresting officers, photographs, interviewing tapes and any other documents they entered in the police national computer (PNC). So even though the police consider me innocent there will remain some mention (what exactly?) in the PNC and, if they fully share their information with Interpol, in other police databases around the world as well. Isn’t a state that keeps files on innocent persons a police state?

What guarentees of use & data protection would apply if the records were to make their way to, say, the US. With the way US immigration policy is going, it is not at all far fetched that the police records could lead of all manner of complications visiting the US. All this the consquences of so called “terrorist” behaviour

  • They found my behaviour suspicious from direct observation and then from watching me on the CCTV system
  • I went into the station without looking at the police officers at the entrance or by the gates
  • Two other men entered the station at about the same time as me
  • I am wearing a jacket “too warm for the season”
  • I am carrying a bulky rucksack, and kept my rucksack with me at all times
  • I looked at people coming on the platform
  • I played with my phone and then took a paper from inside my jacket

Pretty much every commuter in London would match these criteria several times a week. It is an absolutely unacceptable violation of personal liberties for such criteria to lead to a permanent record of an innocent person being a potential “terrorist” suspect. I’ve been considering it for a while, but this just highlights that its way past time for one to join Liberty. Right now.

Recovering encryption keys via acoustic analysis

Posted: September 13th, 2005 | Filed under: Uncategorized | No Comments »

Have just been reading this article about how, given a 15 minute recording of a user typing, it is possible to ‘recover’ details of every word & even letter typed. Each key has a subtly different sound, so given a mapping of sound <-> key it is possible analyse a recording to recover the letters / words typed. By assuming that the text being typed was, say English, it is possible to apply statistical to the 15 minute recording to generate the sound <-> key mappings. Combine the two techniques with a suitably planted microphone and you have a pretty damn good channel for covertly monitoring what someone types. Another good reason to stop using regular passwords & move wholesale to one time keys / secure id generators – as if existing spyware weren’t enough of a reason already.

Even more intriguing though, is the last paragraph where they link to another study suggesting that, since CPUs make different sounds (high frequency, inaudible to humans) depending on what they are computing, that it might be possible to analyse a recording of a decryption operation to recover the encryption keys. Damn, encryption & security breaks down in the most obscure & unimaginable/unexpected ways.

Thoughts on creating better RPMs

Posted: August 23rd, 2005 | Filed under: Coding Tips | No Comments »

Despite the impression given from endless flame wars about the merits of Debian packages vs RPMs, the biggest problems with RPM are not technical, but rather quality control. With its very long release cycles, extensive / comprehensive testing, and higher than average ability of its maintainers, the debian packages one encounters are very well produced indeed. Somewhat a victim of its own success & popularity, RPMs are being produced by a large number of third parties, many of whom only have passing familiarity with Linux, let along RPM packaging guideliens. As an unfortunate result, there are a large number of poorly packaged RPMs floating around the net. The even more unfortunate thing is that if just a few simple guidelines were followed, the situation would improve dramatically. So, without further ado, here are some pointers.

Group names
Only use group names which are defined in /usr/share/doc/rpm-[VERSION]/GROUPS – don’t make up new groups
Installation prefix
Most software should install into the regular /usr hierarchy, and definitely not into /usr/local, or /usr/local/[APP] which are for *unpackaged* software. Since RPM manages all installed files, there is no need to worry about files from different apps being installed side-by-side. RPM knows what belongs to which app and will ensure clean uninstallation of all files, and prevent installation of two apps with conflicting files. If a private installation location is required, then use /opt/APP-NAME/VERSION, which both separates out the app into its own heirarchy & also allows multiple versions to live in harmony.
Files list
The %files section MUST list all files belonging to the application. RPM uses this files list for many purposes

  • to ensure that two applications don’t try to install the same file
  • to ensure complete removal of all files upon uninstallation
  • to verify installed files for changes, from modification time, and ownership right down to md5 sums.

Having a %post section which, for example, extracts a ZIP / tar.gz archive of files for the application completely bypasses these important features of RPM, dramatically lowering the value of having the application packaged in an RPM at all.

Init scripts
If the application includes init scripts, make sure they are registered with chkconfig, but don’t turn on the service by default – policy decisions such as whether a daemon should start on boot are the realm of the system administrator, not the software distributor. This is especially important if the application listens on any network ports.
Patch releases
After an initial release of software it may be neccessary to distribute a patch update. The approach for this is to take the original source RPM, add one or more patches in the spec file, increment the release number & then rebuild the bina4ry RPM.