Before continuing: I am not a cryptographer; merely someone who, on a good day, can use cryptographic libraries with what might pass for intelligence. I write this post with 20/20 hindsight. One of the security maxims I hold dear is to not freely mix data from different security contexts. Programmers often see this with “don't mix code and data”, and guidance to prepare parameterised SQL queries and then execute them with untrusted data in parameters, rather than try to sanitise the data into an SQL query.
One of the really nice things about the Go programming language is that you have the complete source to the compiler and the standard library, as very readable code which can be used to investigate problems. When merging a feature branch in a git repo I, of course, rebuilt my test frontend server to be sure everything still worked, as a check before committing. So I found that a client call was never returning, while my program was now chewing a whole CPU.
Various folks fight the good fight and tackle spammers and we read news reports about "took down the botnet responsible for X% of the world's spam". Perhaps the volume of spam drops for a day or two. In exceptional cases, for a week. But the spam returns, and with changed characteristics which do not filter so readily. At heart, it's an economics problem. There is demand, therefore there will be surprise.
This post references "I" quite a bit, as I'm exploring my reactions and thoughts on a particular topic; all ethics are subjective at some level, and I hope that by exploring my reactions a little I can contribute towards a healthy debate, while noting that my reactions are not absolutes that should guide others. Particularly, I am not a psychologist and many of the issues here could do with input from such for someone trying to come to an informed conclusion of action to take.
In February, I wrote the post How private is your mailing-list subscriber list?. It gets worse. Combine authentication-failure reports, VERP, mailing-lists and what appears to be a buggy verifier. VERP is Variable Envelope Return Path, a name for a technique where a mailing-list encodes information about the recipient's email address into the SMTP Envelope Sender. This is used so that if there is a delivery problem, the "bounce" which comes back will, for any not-massively-broken mail-system generating the bounce, identify the subscriber to the list who had problems.
I am a stupid grumpy troll. I was invited to Google I/O Extended, but got the date wrong and set aside tomorrow to attend, a day late. Not only have I missed it, but I've denied someone else a slot. That's really embarrassing. More embarrassing than it is annoying to have not attended. How did this happen? I'm human, I made a mistake when entering the event in Google Calendar.
As someone who uses a laptop for work, and may also check personal email with it, this Grumpy Troll has noticed how … inadequate the current multi-signin support with Google's suite of tools is. Too many products forcibly sign you out of everything when you choose to use the second identity in the list of "current identities" for that product. And yet, Chrome remains the trollish browser of choice, with using multiple browsers as a work-around too often just leading to frustration.
One of the biggest productivity enhancements you can make to a browser, when working with web-based services, is to add the ability to edit any text area in a real text editor. Today, I realised that I had not set this up on my work laptop, and my personal laptop is not with me so could not crib the setup. Since I've had to debug this twice, it's time to blog it for next time.
For those who remember my post, A tablet that wows, and thought "I'd like something like that", then perhaps you should take a look at the Sensordrone kickstarter project. It's not a tablet, but a bluetooth peripheral with some number of the things I suggested would be good to see. Open source drivers. -The Grumpy Troll, unaffiliated with the Sensordrone folks
In February, my friend Brady Catherman became my business partner, as we founded Trivial, Inc. We worked on developing infrastructure tools which are designed to make software development and maintenance on systems far easier, with an eye to serving the cloud-based scripted serving market. During the initial weeks of this company, a mutual friend, Mike Abbott, introduced us to Derek Collison, an entrepreneur who was founding Apcera and gathering engineers with a passion for infrastructure problems.
This is long, detailed and rambling. If you don't want the editorial, then just peruse the git tree, including: README.UPDATINGNewStuffChangeLog A while back, The Exim Maintainers held a mini-conf where we sorted out policy for issues such as "when do we release". We decided that if not forced sooner by something urgent or the wrap up of major new features, we'd release about every six months with whatever we have. Our previous release was 4.
One of this troll's two "homes" on the network is a Xen VM from prgmr, to provide a West Coast USA presence to augment my (FreeBSD) colo box in Amsterdam NL. It was running Ubuntu Oneiric (11.10) and is now running Ubuntu Pangolin (12.04). This mostly went smoothly. The two exceptions: certificates/subversion and bind. Certificates I had set up my system to just check out of svn the same layout used on my FreeBSD machine, which has a set of certificates under my control, some adjusted c_* scripts (mostly c_rehash which generates hash symlinks for both OpenSSL pre-1 and 1, with the two different hash schemes used, so applications using either system can still find the certs) and a Makefile, so that updates are just a “make”.
Kudos to www.favicon.cc: this Grumpy Troll lacks talent in the visual arts, but their site provided a tool at the complexity level I wanted: a grid of pixels, basic colour management, draw something in pixels, download favicon. I didn't know how to portray ‘grumpy’. Ah well, at least the troll's teeth display fine British dentistry. This one is 16x16 only. Probably a good thing …
Time for this Grumpy Troll to state publicly an opinion previously only passed on in speaking. Nothing presented here is given as anything other than the opinion of one person. Social networking sites are items of fashion. They come, they go. They may get fabulously large and generate a lot of money while they're in, but if so then they're aimed at the general population and sooner or later they'll always fade from prominence.
One of the pieces of software this troll runs is the Synchronising Key-Server, SKS, which serves keys for PGP via the HKP protocol (based on HTTP). Recently, Daniel Kahn Gillmor brought an issue to the attention of the keyserver operator community, relating to undesirable behaviour of the server-code when faced with certain types of request, which makes it wise to run the key-server behind an HTTP proxy. Until now, my SKS website had been running under Apache, with a simple redirect for traffic that matches /pks/ to bump over to the HKP port (11371), plus a WSGI app I wrote, for spidering the key-server mesh and reporting stats.
In an earlier blog post, “Why deploy ECC in SSH?”, I noted: “It's not that I have any reason to fear that RSA or DSA might be weak, but that I have no reason to believe that either is too weak, so running both in parallel does not hurt security and does improve my ability to respond to a changing environment, which at some point in time will critically improve my security.
Discovered that this is mostly a UI problem. Mrs Grumpy Troll was bemused by my setting up Calibre on our home computers, with imports of all the eBooks we legally own. With the DRM stripped so that this would be possible. “But you can always re-download them!” she said. She is no longer bemused. The other day, as we sat down to eat in a diner, she asked me if I knew what had happened to a book we'd both read on our Barnes & Noble Nook account.
In discussion with nomad, over the topic of https://lopsa.org/content/calendars-we-dont-need-no-steeken-calendars, I noted that the core problem is the absence of a standard for exchange of data about calendar availability. Various Calendar implementations, such as Google's, let you choose who to share calendar content with, including just free/busy, but that only works if the other attendees all use that same implementation. Google Calendar also lets you find a time suitable for all attendees, if they're using Google Calendar.
Memo to self: while ending a ~/.ssh/config file with a block supplying defaults for * is good (as each attribute uses the first match found for that attribute), and adding security checks is good, DNS based checks do not necessarily play well with Zeroconf. In particular, VerifyHostKeyDNS ask is problematic. To avoid major delays on connecting, it may be helpful to precede that block with: Host *.local VerifyHostKeyDNS no
If you have a supposedly private mailing-list, you may be surprised how much information about your subscriber-list may be disclosed to anyone who can post, by the operators of the mail-systems of those who subscribe. Not email addresses, but counts of subscribers at gmail, indications of forwarding services used, and more. Similarly, if you're hiding behind a mail-forwarding service but use one of the big freemail providers, someone who wants to may be able to identify which provider you're using.
This grumpy troll is sometimes old-fashioned; I'm inclined to self-levitate my own patch of fog and call it a cloud. I run my own mail-server, where I receive the bulk of my mail. For anti-spam reasons, the addresses that go to companies and to the less clueful will be for a Gmail account, but for reading mail in bulk, I prefer to use mutt(1) pointed at my own IMAP setup.
At first, I loved my Nook Color from Barnes & Noble. It was so neat, and ran Android, and I could boot into Cyanogen, even if I chose to stick with the supplied OS for now. The Nook app on my Android phone worked well too. Google Books is very nice, but it inherently ties books to your Google Account identity, which means that you can't share an account without sharing email, contacts, docs, everything.
This troll's colocation box was physically moved to a new location today. In preparation for this, extensive backups were taken, but this troll did not find time to sort out niceties such as "backup MX". There is now a VPS second instance which will become usable as a backup, but more work is required. The machine, "redoubt", is in Amsterdam, NL, where I used to live and where I still have friends; it has moved less often than I have, since I moved to the USA, while providing continuity of service.