Stevey is currently certified at Master level.

Name: Steve Kemp
Member since: N/A
Last Login: 2013-01-05 09:46:29

FOAF RDF Share This



For the curious I live in Edinburgh, Scotland.

I'm a big believer in the benefits of the open source
software. I've written, or contributed, to a large
number of Open Source projects including GNU Emacs,
GNUTella, GoGo, GNUMP3d, MP3Blaster.

Nowadays I guess the most visible thing I do in my spare
time is run a site I created for Debian GNU/Linux system administration:



Articles Posted by Stevey

Recent blog entries by Stevey

Syndication: RSS 2.0

Generating fingerprints from SSH keys

I've been allowing users to upload SSH public-keys, and displaying them online in a form. Displaying an SSH public key is a pain, because they're typically long. That means you need to wrap them, or truncate them, or you introduce a horizontal scroll-bar.

So rather than displaying them I figured I'd generate a fingerprint when the key was uploaded and show that instead - This is exactly how github shows your ssh-keys.

Annoyingly there is only one reasonable way to get a fingerprint from a key:

  • Write it to a temporary file.
  • Run "ssh-keygen -lf temporary/file/name".

You can sometimes calculate the key via more direct, but less obvious methods:

awk '{print $2}' ~/.ssh/ | base64 -d | md5sum

But that won't work for all key-types.

It is interesting to look at the various key-types which are available these days:

mkdir ~/ssh/
cd ~/ssh/
for i in dsa ecdsa ed25519 rsa rsa1 ; do
  ssh-keygen -P "" -t $i -f ${i}-key

I've never seen an ed25519 key in the wild. It looks like this:

$ cat ~/ssh/
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMcT04t6UpewqQHWI4gfyBpP/ueSjbcGEze22vdlq0mW skx@shelob

Similarly curve-based keys are short too, but not as short:

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLTJ5+  \
 rWoq5cNcjXdhzRiEK3Yq6tFSYr4DBsqkRI0ZqJdb+7RxbhJYUOq5jsBlHUzktYhOahEDlc9Lezz3ZUqXg= skx@shelob

Remember what I said about wrapping? Ha!

Anyway for the moment I've hacked up a simple perl module SSH::Key::Fingerprint which will accept a public key and return the fingerprint, as well as validating the key is well-formed and of a known-type. I might make it public in the future, but I think the name is all wrong.

The only code I could easily find to do a similar job is this node.js package, but it doesn't work on all key-types. Shame.

And that concludes this weeks super-happy fun-time TODO-list item.

Syndicated 2015-10-07 10:56:49 from Steve Kemp's Blog

All about sharing files easily

Although I've been writing a bit recently about file-storage, this post is about something much more simple: Just making a random file or two available on an ad-hoc basis.

In the past I used to have my email and website(s) hosted on the same machine, and that machine was well connected. Making a file visible just involved running ~/bin/publish, which used scp to write a file beneath an apache document-root.

These days I use "my computer", "my work computer", and "my work laptop", amongst other hosts. The SSH-keys required to access my personal boxes are not necessarily available on all of these hosts. Add in firewall constraints and suddenly there isn't an obvious way for me to say "Publish this file online, and show me the root".

I asked on twitter but nothing useful jumped out. So I ended up writing a simple server, via sinatra which would allow:

  • Login via the site, and a browser. The login-form looks sexy via bootstrap.
  • Upload via a web-form, once logged in. The upload-form looks sexy via bootstrap.
  • Or, entirely seperately, with HTTP-basic-auth and a HTTP POST (i.e. curl)

This worked, and was even secure-enough, given that I run SSL if you import my CA file.

But using basic auth felt like cheating, and I've been learning more Go recently, and I figured I should start taking it more seriously, so I created a small repository of learning-programs. The learning programs started out simply, but I did wire up a simple TOTP authenticator.

Having TOTP available made me rethink things - suddenly even if you're not using SSL having an eavesdropper doesn't compromise future uploads.

I'd also spent a few hours working out how to make extensible commands in go, the kind of thing that lets you run:

cmd sub-command1 arg1 arg2
cmd sub-command2 arg1 .. argN

The solution I came up with wasn't perfect, but did work, and allow the seperation of different sub-command logic.

So suddenly I have the ability to run "subcommands", and the ability to authenticate against a time-based secret. What is next? Well the hard part with golang is that there are so many things to choose from - I went with gorilla/mux as my HTTP-router, then I spend several hours filling in the blanks.

The upshot is now that I have a TOTP-protected file upload site:

publishr init    - Generates the secret
publishr secret  - Shows you the secret for import to your authenticator
publishr serve   - Starts the HTTP daemon

Other than a lack of comments, and test-cases, it is complete. And stand-alone. Uploads get dropped into ./public, and short-links are generated for free.

If you want to take a peak the code is here:

The only annoyance is the handling of dependencies - which need to be "go got ..". I guess I need to look at godep or similar, for my next learning project.

I guess there's a minor gain in making this service available via golang. I've gained protection against replay attacks, assuming non-SSL environment, and I've simplified deployment. The downside is I can no longer login over the web, and I must use curl, or similar, to upload. Acceptible tradeoff.

Syndicated 2015-09-13 12:39:10 from Steve Kemp's Blog

The Jessie 8.2 point-release broke for me

I have about 18 personal hosts, all running the Jessie release of Debian GNU/Linux. To keep up with security updates I use unattended-upgrades.

The intention is that every day, via cron, the system will look for updates and apply them. Although I mostly expect it to handle security updates I also have it configured such that point-releases will be applied by magic too.

Unfortunately this weekend, with the 8.2 release, things broke in a significant way - The cron deamon was left in a broken state, such that all cronjobs failed to execute.

I was amazed that nobody had reported a bug, as several people on twitter had the same experience as me, but today I read through a lot of bug-reports and discovered that #783683 is to blame:

  • Old-cron runs.
  • Scheduled unattended-upgrades runs.
  • This causes cron to restart.
  • When cron restarts the jobs it was running are killed.
  • The system is in a broken state.

The solution:

# dpkg --configure -a
# apt-get upgrade

I guess the good news is I spotted it promptly, with the benefit of hindsight the bug report does warn of this as being a concern, but I guess there wasn't a great solution.

Anyway I hope others see this, or otherwise spot the problem themselves.


In unrelated news the seaweedfs file-store I previously introduced is looking more and more attractive to me.

I reported a documentation-related bug which was promptly handled, even though it turned out I was wrong, and I contributed CIDR support to whitelisting hosts which was merged in well.

I've got a two-node "cluster" setup at the moment, and will be expanding that shortly.

I've been doing a lot of little toy-projects in Go recently. This weekend I was mostly playing with the message-bus, and tying it together with sinatra.

Syndicated 2015-09-07 09:37:05 from Steve Kemp's Blog

Making an old android phone useful again

I've got an HTC Desire, running Android 2.2. It is old enough that installing applications such as thsoe from my bank, etc, fails.

The process of upgrading the stock ROM/firmware seems to be:

  • Download an unsigned zip file, from a shady website/forum.
  • Boot the phone in recovery mode.
  • Wipe the phone / reset to default state.
  • Install the update, and hope it works.
  • Assume you're not running trojaned binaries.
  • Hope the thing still works.
  • Reboot into the new O/S.

All in all .. not ideal .. in any sense.

I wish there were a more "official" way to go. For the moment I guess I'll ignore the problem for another year. My nokia phone does look pretty good ..

Syndicated 2015-08-13 14:44:38 from Steve Kemp's Blog

A brief look at the weed file store

Now that I've got a citizen-ID, a pair of Finnish bank accounts, and have enrolled in a Finnish language-course (due to start next month) I guess I can go back to looking at object stores, and replicated filesystems.

To recap my current favourite, despite the lack of documentation, is the Camlistore project which is written in Go.

Looking around there are lots of interesting projects being written in Go, and so is my next one the seaweedfs, which despite its name is not a filesystem at all, but a store which is accessed via HTTP.

Installation is simple, if you have a working go-lang environment:

go get

Once that completes you'll find you have the executable bin/weed placed beneath your $GOPATH. This single binary is used for everything though it is worth noting that there are distinct roles:

  • A key concept in weed is "volumes". Volumes are areas to which files are written. Volumes may be replicated, and this replication is decided on a per-volume basis, rather than a per-upload one.
  • Clients talk to a master. The master notices when volumes spring into existance, or go away. For high-availability you can run multiple masters, and they elect the real master (via RAFT).

In our demo we'll have three hosts one, the master, two and three which are storage nodes. First of all we start the master:

root@one:~# mkdir /
root@one:~# weed master -mdir / -defaultReplication=001

Then on the storage nodes we start them up:

root@two:~# mkdir /data;
root@two:~# weed volume -dir=/data -max=1  -mserver=one.our.domain:9333

Then the second storage-node:

root@three:~# mkdir /data;
root@three:~# weed volume -dir=/data -max=1 -mserver=one.our.domain:9333

At this point we have a master to which we'll talk (on port :9333), and a pair of storage-nodes which will accept commands over :8080. We've configured replication such that all uploads will go to both volumes. (The -max=1 configuration ensures that each volume-store will only create one volume each. This is in the interest of simplicity.)

Uploading content works in two phases:

  • First tell the master you wish to upload something, to gain an ID in response.
  • Then using the upload-ID actually upload the object.

We'll do that like so:

laptop ~ $ curl -X POST http://one.our.domain:9333/dir/assign

client ~ $ curl -X PUT -F file=@/etc/passwd,06c3add5c3

In the first command we call /dir/assign, and receive a JSON response which contains the IPs/ports of the storage-nodes, along with a "file ID", or fid. In the second command we pick one of the hosts at random (which are the IPs of our storage nodes) and make the upload using the given ID.

If the upload succeeds it will be written to both volumes, which we can see directly by running strings on the files beneath /data on the two nodes.

The next part is retrieving a file by ID, and we can do that by asking the master server where that ID lives:

client ~ $ curl http://one.our.domain:9333/dir/lookup?volumeId=1,06c3add5c3

Or, if we prefer we could just fetch via the master - it will issue a redirect to one of the volumes that contains the file:

client ~$ curl http://one.our.domain:9333/1,06c3add5c3
<a href=",06c3add5c3">Moved Permanently</a>

If you follow redirections then it'll download, as you'd expect:

client ~ $ curl -L http://one.our.domain:9333/1,06c3add5c3

That's about all you need to know to decide if this is for you - in short uploads require two requests, one to claim an identifier, and one to use it. Downloads require that your storage-volumes be publicly accessible, and will probably require a proxy of some kind to make them visible on :80, or :443.

A single "weed volume .." process, which runs as a volume-server can support multiple volumes, which are created on-demand, but I've explicitly preferred to limit them here. I'm not 100% sure yet whether it's a good idea to allow creation of multiple volumes or not. There are space implications, and you need to read about replication before you go too far down the rabbit-hole. There is the notion of "data centres", and "racks", such that you can pretend different IPs are different locations and ensure that data is replicated across them, or only within-them, but these choices will depend on your needs.

Writing a thin middleware/shim to allow uploads to be atomic seems simple enough, and there are options to allow exporting the data from the volumes as .tar files, so I have no undue worries about data-storage.

This system seems reliable, and it seems well designed, but people keep saying "I'm not using it in production because .. nobody else is" which is an unfortunate problem to have.

Anyway, I like it. The biggest omission is really authentication. All files are public if you know their IDs, but at least they're not sequential ..

Syndicated 2015-08-10 13:29:10 from Steve Kemp's Blog

770 older entries...


Stevey certified others as follows:

  • Stevey certified skx as Master
  • Stevey certified zx80user as Journeyer
  • Stevey certified faw as Apprentice
  • Stevey certified Liedra as Journeyer
  • Stevey certified ladypine as Journeyer
  • Stevey certified Sarah as Apprentice
  • Stevey certified Ward as Master
  • Stevey certified chipx86 as Journeyer
  • Stevey certified johnnyb as Journeyer
  • Stevey certified perlpimp as Journeyer
  • Stevey certified CaptainNemo as Journeyer
  • Stevey certified mobius as Apprentice
  • Stevey certified tjansen as Journeyer
  • Stevey certified auspex as Apprentice
  • Stevey certified laymusic as Journeyer
  • Stevey certified apeiro as Journeyer
  • Stevey certified dneighbors as Master
  • Stevey certified alejandro as Journeyer
  • Stevey certified scandal as Master
  • Stevey certified moray as Journeyer
  • Stevey certified sacha as Apprentice
  • Stevey certified Malkin as Journeyer
  • Stevey certified dria as Journeyer
  • Stevey certified Jordi as Journeyer
  • Stevey certified Mysidia as Journeyer
  • Stevey certified dirtyrat as Journeyer
  • Stevey certified bdelacretaz as Apprentice
  • Stevey certified braden as Journeyer
  • Stevey certified pencechp as Apprentice
  • Stevey certified brouhaha as Journeyer
  • Stevey certified fejj as Journeyer
  • Stevey certified hanna as Apprentice
  • Stevey certified aero6dof as Apprentice
  • Stevey certified gman as Journeyer
  • Stevey certified dlecorfec as Apprentice
  • Stevey certified jpr as Journeyer
  • Stevey certified Pizza as Journeyer
  • Stevey certified kroah as Master
  • Stevey certified wingo as Journeyer
  • Stevey certified jwz as Master
  • Stevey certified ploppy as Master
  • Stevey certified nosinut as Journeyer
  • Stevey certified Radagast as Journeyer
  • Stevey certified Jody as Master
  • Stevey certified ariya as Apprentice
  • Stevey certified nausicaa as Journeyer
  • Stevey certified dan as Master
  • Stevey certified kappa as Apprentice
  • Stevey certified slamb as Apprentice
  • Stevey certified stevebaker as Journeyer
  • Stevey certified gregor as Journeyer
  • Stevey certified maelstorm as Apprentice
  • Stevey certified palm as Apprentice
  • Stevey certified Artimage as Journeyer
  • Stevey certified bluets as Apprentice
  • Stevey certified jds as Journeyer
  • Stevey certified steve as Apprentice
  • Stevey certified elanthis as Apprentice
  • Stevey certified afayolle as Journeyer
  • Stevey certified bonzini as Journeyer
  • Stevey certified jml as Apprentice
  • Stevey certified ciphergoth as Journeyer
  • Stevey certified Fefe as Master
  • Stevey certified Denny as Journeyer
  • Stevey certified sethcohn as Journeyer
  • Stevey certified bjf as Apprentice
  • Stevey certified sdodji as Journeyer
  • Stevey certified raph as Master
  • Stevey certified jarod as Apprentice
  • Stevey certified StevenRainwater as Journeyer
  • Stevey certified Surfr as Apprentice
  • Stevey certified rlevin as Journeyer
  • Stevey certified ike as Apprentice
  • Stevey certified ebf as Journeyer
  • Stevey certified chakie as Journeyer
  • Stevey certified gstein as Master
  • Stevey certified dtype as Apprentice
  • Stevey certified pompeiisneaks as Journeyer
  • Stevey certified acme as Master
  • Stevey certified lsdrocha as Apprentice
  • Stevey certified mjg59 as Journeyer
  • Stevey certified squrl as Journeyer
  • Stevey certified physos as Apprentice
  • Stevey certified rasmus as Master
  • Stevey certified jelle as Journeyer
  • Stevey certified chrisime as Journeyer
  • Stevey certified julian as Master
  • Stevey certified eliot as Journeyer
  • Stevey certified sh as Journeyer
  • Stevey certified mascot as Apprentice
  • Stevey certified SyntaxPolice as Journeyer
  • Stevey certified bytesplit as Apprentice
  • Stevey certified nymia as Journeyer
  • Stevey certified thomasvs as Master
  • Stevey certified Bram as Journeyer
  • Stevey certified pfremy as Apprentice
  • Stevey certified todd as Master
  • Stevey certified bma as Journeyer
  • Stevey certified coolvibe as Journeyer
  • Stevey certified deekayen as Journeyer
  • Stevey certified fxn as Journeyer
  • Stevey certified bgeiger as Apprentice
  • Stevey certified angelsun as Journeyer
  • Stevey certified andrelop as Apprentice
  • Stevey certified jono as Master
  • Stevey certified groom as Apprentice
  • Stevey certified axboe as Master
  • Stevey certified jennv as Journeyer
  • Stevey certified tseaver as Journeyer
  • Stevey certified duncanm as Apprentice
  • Stevey certified jc as Apprentice

Others have certified Stevey as follows:

  • fxn certified Stevey as Journeyer
  • wingo certified Stevey as Master
  • faw certified Stevey as Master
  • Liedra certified Stevey as Journeyer
  • ladypine certified Stevey as Journeyer
  • CaptainNemo certified Stevey as Journeyer
  • apeiro certified Stevey as Journeyer
  • dneighbors certified Stevey as Journeyer
  • Jordi certified Stevey as Journeyer
  • Mysidia certified Stevey as Master
  • braden certified Stevey as Journeyer
  • Chicago certified Stevey as Master
  • pencechp certified Stevey as Master
  • brouhaha certified Stevey as Master
  • wardv certified Stevey as Journeyer
  • Pizza certified Stevey as Master
  • jrf certified Stevey as Journeyer
  • ariya certified Stevey as Master
  • maelstorm certified Stevey as Journeyer
  • palm certified Stevey as Journeyer
  • alfie certified Stevey as Master
  • donscarletti certified Stevey as Master
  • afayolle certified Stevey as Journeyer
  • bonzini certified Stevey as Journeyer
  • ciphergoth certified Stevey as Journeyer
  • domi certified Stevey as Master
  • sdodji certified Stevey as Master
  • jarashi certified Stevey as Master
  • jarod certified Stevey as Master
  • ebf certified Stevey as Journeyer
  • lsdrocha certified Stevey as Master
  • alexm certified Stevey as Journeyer
  • richdawe certified Stevey as Journeyer
  • sh certified Stevey as Journeyer
  • mascot certified Stevey as Master
  • realblades certified Stevey as Apprentice
  • lerdsuwa certified Stevey as Master
  • bytesplit certified Stevey as Apprentice
  • thom certified Stevey as Master
  • coolvibe certified Stevey as Master
  • speeder certified Stevey as Master
  • broonie certified Stevey as Journeyer
  • angelsun certified Stevey as Journeyer
  • MAK certified Stevey as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page