Sunday, January 29, 2006

MJ Ray: Tour de France 2007 in London

Mj ray says: MJ Ray: Tour de France 2007 in London: "TdF Blog mentioned the announcement that the 2007 Grand Depart will be in London, England (official announcement at Red Ken's site, official London site) . Of course this isn't this first time that the Tour de France has come through England, it doesn't seem that long go it came through Crowborough , my home town. Of course watching it go by with a pint in hand wasn't to bad for the 3 seconds, the leaders pack was actually in view.

Tuesday, January 24, 2006

It's the little things which make a difference.

Like forgetting to check to permissions on "/".

Yeah, well I was putting together a new computer and since I had built the required configuration before I collected all the approriate files on my workstation. I then tar-ed up a fake /etc and /usr/local directories in to a single tar file and took it over to the new machine, Cd-d to root and unpacked it on.

Of course tar helpfull chmod'd the new system's "/" to the fake "/" I was using when I put the tar file together. But I didn't notice this at first.

The thing is nothing stopped working straight away. It was only when I rebooted and exim failed to start with the meaningful message "user mail was not found" that the problems started - I tried ripping exim4 out of the system entirely and putting all back in , fighting the debian packaging system as the would normally leave loads of broken packages.

I ask one of my colleages to look at it and he point out that he couldn't su to mail. I had spotted this but was sure hoe to debug it - you often cant strace su for security reasons.

While su's error message as lots more help, "Can't cd to /var/mail' I had checked the /var and the /var/amil perms.

Suddenly as I was explaining all this to my colleague , the penny dropped and I check "/"s perms and all was clear.

A Day for Bug

As an occasional, and the past more frequent contributor to wxWidgets . I decided to help out when I saw the Bug Day on Saturday annouced. Even though it was me & my girlfriends anniversary I managed to spend a few hours helping out.

More interestingly it has awakened my enthuasim again - so maybe I'll spend a few more weekends just picking of bugs in the bug tracker and doing something about them.

So the even the bug day didn't no much on it own , it may have got me and hopefully some others moving again , or faster which will help overall

Sunday, January 08, 2006

GPGkeys on usb

I found this blog post (which is unfortunately down atm) Matt Brown: New GPG Subkey / Offline for a few days

One of my Christmas presents was a brand spanking new USB key. For quite a while I’d been planning to put my SSH / GPG keys off onto something like this for some extra security.

I’ll write up the exact steps of how I achieved my setup in the sometime next week, but it was all fairly easy.


All in all I’m quite liking the new setup, plug usb key in, password dialog pops up for SSH key, enter password, password dialog pops up for GPG signing key, enter password. I then h"

I'm quite interested in seeing what Matt has actually done later, but I've been considering using one of these to actually put the agent code into them.

The private key never leaves the usb device at all - although it is obviously must be saved in some portion of the device. But I would make the key write-only. I would probably also put a physical button on the device which has to pushed for the agent to run. This is to mitigate the weakness in agent-forwarding schemes where root on any machine in a forwading chain can communicate to the real agent or agent device. (This means a root user can masquearde as you. It works because root can always get r/w access to the agents commications channel). By forcing the button to pushed for each authenication attempt it makes more likely that attacks are at least visible to the user.

Unfortunately I understand there is a 'bug' the ssh-agent protocol and it can leak the private key. Which limits this.

Thursday, January 05, 2006

On Other things

One of the small pleasures my job gives me is that while travelling to customers sites (by car), I often find myself listening to radio programmes I might otherwise I have missed - or indeed not thought to listen to.

Today I happened across one of those rare gems in the the radio 4 schedule. Entitled 'The World's First Rock Band' it was a wonderful look at - well not really rock music, more what pterry might call "music with rocks in ". Specifically music played on instruments made at least partially from rock - the geological kind in case of any remaining confusions.

Follow the link while it works as the programme seems to be available for listen again.

Don't underestimate the resourcefulness of people being annoying

Mostly my day jobs involves sorting out unusual computer problems, most often they invovle the Windows OS. I can across this - Don't underestimate the resourcefulness of people trying to be annoying.

Anyway the author talks about removing configuration API, and documentation of where those settings are stored in the registry. This is so that they cant be abused by installers. The idea is there is that an installer shouldn't change a users settings. This is all for the good and all installers should follow such guidelines. Mind you I'm not aware of such a guidelines document from microsoft , which specify what things to leave alone in your installers.

But by not documenting some of these things - how is a local system administrator going to fix them when the something goes horribly wrong. A simple example would be carefully constructed registry entry which causes the document UI program to GPF when it reads/processes the settings, but the main library,which is the user of the settings still interprets the settings in the way the mal-installer wished.

A local sysadmin is going to have merry hell trying to sort such a situation out, because he can't even look up on msdn or technet where the compromised settings are likely to be.

Tuesday, January 03, 2006

The bug system

Well, a grand new year was had, I went over to a party some friends were holding to discover they all seemed to know each other purely by reading each other LJ. Anyway I said I'd post about the bug system I was sorking on some here or some docs culled from the development directories. It pretty much works as described although I have yet to actually use it anger - and it still need some debugging itself. I haven't even tried the search yet, although I have coded an algorithm which should work as per described . (Famous last , I know). PS: - I can believe how long it took me to compose this , especially since I started with well formed html, produced by pod2html. Sigh. And the html seems to have got worse not better..

Semantics for the Bugbase data

Record Format

The 'current' status of a bug is tracked using a record object, which is stored in a file. This file is checked into the SCM/VCS system alongside the code.

The dates the bug was first committed and subsequently revised reflect the date the information in the update were made available in the bug database. So it important not to use commit dates for bug records in to much of a similar way to you might for code files.

If you consider the usual lifetime of a bug this make sense - a bug is coded at some arbitrary point in the development cycle but only some time later is it discovered and added to the bug database. When a bug is fixed we leave the bug record in the VCS and change it status 'Fixed'. And similarly for other terminal states.

By using symbolic tags to indicate which versions of the code suffer from the bug, this means we can only retrospectively track bugs against tagged versions of the software. But this is not unreasonable as most , if not all development shop use tags to mark 'versions' of the software , which are used outside of the development team itself.

This gives us or first SCM requirement - our SCM system must provide us with a mechanism for adding a existing tag to new files, some distributed SCM systems may have a problem with this concept. Indeed in some people's view this is a violation of proper SCM semantics - as you should be always able to track all changes to the data /and/ metadata a SCM system stores. In pure software terms adding a file to an already released version is clearly a stupid thing to do as it changes to exact build used by that version.

However these semantics allow the development team to track bugs by date in the current version and by tag in earlier versions. For SCM system which don't support this , we should be able to simulate it with extra tracked data, which contains the bug revision to symbolic tag mapping. (TODO).

A desired side-effect of this semantic is that new versions (tags) of the software will automatically be assigned with the current status of all the reported bugs, so if the bug has been fixed the new version of the code will still show the code was fixed, and similarly if it is still open the database show the current version as having that bug.


Unfortunately the above would suggest there is a problem if someone reports a bug in 1.x which has already been (maybe unwittingly) fixed in (say) 2.0 . At first site this seems to be a problem, as it would show 2.0 has having the bug - assuming you want to keep the bug open for fixing in 1.0.

But as you can see in this case 2.0 would have to be on a separate VCS branch to 1.0 otherwise you wouldn't be able to continue to track changes to 1.x .So in this case you only need to create the bug record in the 1.x branch.

However, the Corollary to this that if the bug exists in both versions you need to create separate bug records in both branches. Of course this happened automatically for bug which exist when you branch, as your VCS system takes care of this.

OPTION:1: The system currently provides no tools to keep these records synchronised.

OPTION:2: To keep both bugs synchronised you need to decide on of the bugs is the master and create a reference record on the other branch. : Problem , this is not what standard branching does, so if bugs which are creating before a branch point end up as back to option 1.

Bugbase API

Bugbase::Bug - Operate on Bugbase bugs


    use Bugbase::Bug ;
  my $bug = new Bugbase::bug(Summary => "bug title",
                             Severity => "Baad",
                             Status => "Open");


  my $otherbug = Bugbase::bug::find($pathlist , @findspec);
  print $other->version();


Provides methods to manipulate the bug records with bug management centric names.

This module is basically a wrapper around either VCS::xxx , and DB::rfc822 which does the approriate thing.

This removes the need to thing about the bugs as anyhing else and just thing about the operations in terms of the bugs, rather than how this might be expressed at the back end.


Creates and returns and new bug object, for a new bug.

find($pathlist , @searchspec )
return a bug object matching the arguments .
Path list is an arrayref of paths to search, and search spec is an a array of hashrefs. Each hashref contains a key/value pair where the key is the field to be matched - the value is a an array of regexps, to match.

The specification is considered matched if all the regexp's in any hash set match.

An accessor for the status method of the bug.

This accessor clears the version array, so that $bug->status('Fixed'); doesn't mark the bug as fixed historically.

Resolution Priority
Accessors for the simple bug fields, these are store in the bug file. The only exception is commentary which is stored in the bug record's body. You can use any fieldname here which is compatible with DB::rfc822.

This is an accessor for version array which constains a list of 'tags' the currently selected bug revision. For instance if the currently selected revision has status 'Open' , this will return an arrary contain the versions of the software which are believed to contain the bug.

1.This method cannot currently be used to clear the tags on a version. 2.This method currently operates on the HEAD.

This returns the revision number of the selected bug record.

commit ( message )
Save and commit to the repository the currnet chnages in the bug record.

this returns the full path name of the bug file.

this returns the leaf name of the bug file.

this returns a globlay unique a staticname for the bug, it is normally based in the VCS naming conventions.