I spend a surprising amount of my time as part of keyring-maint telling people their requests are badly formed and asking them to fix them up so I can actually process them. The one that’s hardest to fault anyone on is that we require requests to be inline PGP signed (i.e. the same sort of output as you get with “gpg –clearsign”). That’s because RT does various pieces of unpacking of MIME messages that mean that a PGP/MIME signatures that have passed through it are no longer verifiable. Daniel has pointed out that inline PGP is a bad idea and got as far as filing a request that RT handle PGP/MIME correctly (you need a login for that but there’s a generic read-only one that’s easy to figure out), but until that happens the requirement stands when dealing with Debian’s RT instance. So today I finally added the following lines to my
.muttrc rather than having to remember to switch Mutt to inline signing for this one special case:
send-hook . "unset pgp_autoinline; unset pgp_autosign" send-hook rt.debian.org "set pgp_autosign; set pgp_autoinline"
i.e. by default turn off auto inlined PGP signatures, but when emailing anything at rt.debian.org turn them on.
(Most of the other things I tell people to fix are covered by the replacing keys page; I advise anyone requesting a key replacement to read that page. There’s even a helpful example request template at the bottom.)
 RT sticks a header on the plain text portion of the mail, rather than adding a new plain text part for the header if there are multiple parts (this is something Mailman handles better). It will also re-encode received mail into UTF-8 which I can understand, but Mutt will by default try to find an 8 bit encoding that can handle the mail, because that’s more efficient, which tends to mean it picks latin1.
Update: Apparently Mutt in Jessie and beyond doesn’t have the
pgp_autosign option; you want
crypt_autosign instead (and maybe
crypt_autopgp but that defaults to yes so unless you’ve configured your setup to do S/MIME by default you should be fine). Thanks to Luca Capello for pointing this out.
I previously forgot to mention that I was planning to attend DebConf14, having missed DebConf13. This year the conference was held in Portland, OR. This is a city I’ve been to many times before, and enjoy, but I hadn’t spent any time wandering around its city centre as a pedestrian. I have to say I really prefer DebConfs that are held in middle of city. It always seems a bit of a shame to travel some distance to somewhere new and spend all the time there in a conference venue. Plus these days I have the added lure of going out and playing Ingress in a new location. DebConf14 didn’t disappoint in these respects; the location was super easy to get to from the airport via public transportation, all of the evening social events were within reasonable walking distance (I’ll tend to default to walking when possible) and the talk venue/accommodation were close to each other and various eating + drinking options. Throw in the fact at Portland managed to produce some excellent weather (modulo my Ingress session on the last Saturday morning, when rained on me) and it’s impossible to fault the physicalities of DebConf this year.
This year the conference format was a bit different; previous years have had a week long DebConf before the week of the conference itself. This year went for a 9 day talk schedule (Saturday -> Sunday) with various gaps of hacking time interspersed. I’ve found it hard to justify a full two weeks away in the past, so this setup worked a lot better from my viewpoint. Also I rarely go to DebConf with a predetermined list of things to do; the stuff I work on naturally falls out of talks I attend and informal discussions I have. Having hack time throughout the conference helped me avoid feeling I was having to trade off hacking vs talks.
Naturally enough a lot of my involvement at DebConf was around OpenPGP. Gunnar and I spent a fair bit of time getting Daniel up to speed with the keyring-maint team (Gunnar more than I, I’ll confess). We finally set a hard timeframe for freeing Debian of older 1024 bit keys. I was introduced to the Gnuk, which is a particularly interesting piece of open specification hardware with a completely Free software stack on top if it that implements the OpenPGP smartcard spec. Currently it’s limited to 2K keys but it’s hoped that 4K support can be added (and I ended up spending a couple of hours after the closing talk hacking on the source and seeing how much needs to change for 4K support, aided by the very patient Niibe). These are the sort of things that really benefit from the face time that DebConf offers to the Debian project. I’ve said it before, but I think it’s worth saying again: Debian is a bit like a huge telecommuting organization and it’s my opinion that any such organization should try and ensure its members actually spend some time together on a regular basis. It improves the ability to work remotely a hell of a lot if you can actually put a face to the entity you’re emailing / IRCing and have some sort of idea where they’re coming from because you’ve spent some time with them, whether that’s in talks or over dinner or just casual hallway chats.
For once I also found myself considering alternative employment while at DebConf and it was incredibly useful to be able to have various conversations with both old friends and people who were there with an eye on recruitment. Thanks to all those whose ears I bent about the subject (and more on the outcome in a future post). Thank you also to the many people involved with the organization of DebConf; I’ve been on the periphery a few times over the years and it’s given me a glimpse into the amount of hard work all of the volunteers (be they global team, local organizing team, video team or just random volunteers) put into making DebConf one of my must-attend yearly conferences. If you’re at all involved in Debian and haven’t attended I strongly urge you to do so - I’ll see you all next year at DebConf15 in Heidelberg!
Back in January I changed jobs. This took me longer to decide to do than it should have. My US visa (an L-1B) was tied to the old job, and not transferable, so leaving the old job also meant leaving the US. That was hard to do; I’d had a mostly fun 3 and a half years in the SF Bay Area.
The new job had an office in Belfast, and HQ in the Bay Area. I went to work in Belfast, and got sent out to the US to meet coworkers and generally get up to speed. During that visit the company applied for an H-1B visa for me. This would have let me return to the US in October 2014 and start working in the US office; up until that point I’d have continued to work from Belfast. Unfortunately there were 172,500 applications for 85,000 available visas and mine was not selected for processing.
I’m disappointed by this. I’ve enjoyed my time in the US. I had a green card application in process, but after nearly 2 years it still hadn’t completed the initial hurdle of the labor certification stage (a combination of a number of factors, human, organizational and governmental). However the effort of returning to live here seems too great for the benefits gained. I can work for a US company with a non-US office and return on an L-1B after a year. And once again have to leave should I grow out of the job, or the job change in some way that doesn’t suit me, or the company hit problems and have to lay me off. Or I can try again for an H-1B next year, aiming for an October 2015 return, and hope that this time my application gets selected for processing.
Neither really appeals. Both involve putting things on hold in the hope longer terms pans out as I hope. And to be honest I’m bored of that. I’ve loved living in America, but I ended up spending at least 6 months longer in the job I left in January than I’d have done if I’d been freely able to change employer without having to change continent. So it seems the time has come to accept that America and I must part ways, sad as that is. Which is why I’m currently sitting in SFO waiting for a flight back to Belfast and for the first time in 5 years not having any idea when I might be back in the US.
Every now and then I decide I’ll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn’t think I was aiming that high. I thought I’d start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the “I have my laptop and I want to remain connected” case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.
Let’s start with getting a SIP server up and running. I went with repro which seemed to be a reasonably well recommended SIP server to register against. And mostly getting it up and running and registering against it is fine. Until you try and make a TLS SIP call through it (to a sip5060.net test address). Problem the first; the StartCom free SSL certs are not suitable because they don’t advertise TLS Client. So I switch to CACert. And then I get bitten by the whole question about whether the common name on the cert should be the server name, or the domain name on the SIP address (it’s the domain name on the SIP address apparently, though that might make your SIP client complain).
That gets the SIP side working. Of course RTP is harder. repro looks like it’s doing the right thing. The audio never happens. I capitulate at this point, and install Lumicall on my phone. That registers correctly and I can call the sip:firstname.lastname@example.org test number and hear the time. So the server is functioning, it’s the client that’s a problem. I try the following (Debian/testing):
- jitsi - Registers fine, seems to lack any sort of TURN/STUN support.
- ekiga - No sign of TLS registration support.
- twinkle - Not in testing. A recompile leads to no sign of an actual client starting up when executed.
- sflphone - Fails to start (Debian bug #745695).
- Empathy - Fails to connect. Doesn’t show any useful debug.
- linphone - No TLS connect (Debian bug #743494).
I’m bored at this point. Can I “dial” my debian.org SIP address from Lumicall? Of course not; I get a “Codecs incompatible” (SIP 488 Not Acceptable Here) response. I have no idea what that means. I seem to have all of the options on Lumicall enabled. Is it a NAT thing? A codec thing? Did I sacrifice the wrong colour of goat?
At some point during this process I get a Skype call from some friends, which I answer. Up comes a video call with them, their newborn, perfect audio, and no hassle. I have a conversation with them that doesn’t involve me cursing technology at all. And then I go back to fighting with SIP.
Gunnar makes the comment about Skype creating a VoIP solution 10 years ago when none was to be found. I believe they’re still the market leader. It just works. I’m running the Linux client, and they’re maintaining it (a little behind the curve, but close enough), and it works for text chat, voice chat and video calls. I’ve spent half a day trying to get a Free equivalent working and failing. I need something that works behind NAT, because it’s highly likely when I’m on the move that’s going to be the case. I want something that lets my laptop be the client, because I don’t want to rely on my mobile phone. I want my email address to also be my VoIP address. I want some security (hell, I’m not even insisting on SRTP, though I’d like to). And the state of the Open VoIP stack just continues to make me embarrassed.
I haven’t given up yet, but I’d appreciate some pointers. And Skype, if you’re hiring, drop me a line. ;)
I put out the call for nominations for the 2014 Software in the Public Interest (SPI) Board election last week. At this point I haven’t yet received any nominations, so I’m mentioning it here in the hope of a slightly wider audience. Possibly not the most helpful as I would hope readers who are interested in SPI are already reading spi-announce. There are 3 positions open this election and it would be good to see a bit more diversity in candidates this year. Nominations are open until the end of Tuesday July 13th.
The primary hard and fast time commitment a board member needs to make is to attend the monthly IRC board meetings, which are conducted publicly via IRC (#spi on the OFTC network). These take place at 20:00 UTC on the second Thursday of every month. More details, including all past agendas and minutes, can be found at http://spi-inc.org/meetings/. Most of the rest of the board communication is carried out via various mailing lists.
The ideal candidate will have an existing involvement in the Free and Open Source community, though this need not be with a project affiliated with SPI.
Software in the Public Interest (SPI, http://www.spi-inc.org/) is a non-profit organization which was founded to help organizations develop and distribute open hardware and software. We see it as our role to handle things like holding domain names and/or trademarks, and processing donations for free and open source projects, allowing them to concentrate on actual development.
subscribe via RSS