On my laptop I have two types of Git repositories. Some of them are open source projects, to which I may occasionally (try to) contribute. There are also my daily work repositories which belong to a company I work for. If I happen to make some changes and mean to publish them, my name along with my email address appear in commits. For open source projects, preferably I use my private email, while for the company projects it’s a requisite company’s email address.
Encrypting disks, especially on laptops, seems like a no-brainer these days. There are plenty of stories of laptops being lost or stolen with important information stored on them (medical records, financial information). To me this is about the peace of mind: I don’t want to care too much about losing equipment if I only know the data stored on it cannot be accessed (easily). Of course with enough effort, expertise and the right equipment, it’s likely possible to recover encrypted data, but I assume I’m not the target.
As much as cloud services make life easier, there are two types of them which I’ve always felt bad about: files and calendar.
No matter how hard I try to avoid it, a lot of content and services I use, are available online. Most of the time the most convenient way to access them is with a web browser. I’m on my crusade to limit my need for using a web browser, but for the time being, small steps, I am where I am, and I need a “traditional” web browser.
It’s overwhelming these days–everywhere I’m asked for a user name and a password. It’d be great if only there was a convenient and widely adopted way of proving my identity, or more precisely, my rights to access something (if I don’t really want to expose my identity as such). Meanwhile, I have to deal with passwords somehow.
It’s been nagging me for a while, that something’s possibly wrong with my online presence and the services I had been using. Particularly I had been a big Google fan when it emerged. It was really cool to have a GMail account at the time, as an alternative to one of those providers in the dot-com boom era. I still think Google do a great job and their GMail service is really great and secure (yes, secure). Also I can boast a name.surname GMail account which is actually not possible to get these days (I got it when GMail was getting popular). The problem with it is privacy.
This time I’d like to share some piece of code I find very useful when experimenting with GStreamer. This includes writing some small tests to understand some features and all sort of debugging of specific cases after distilling them from larger applications.
Here’s another, somewhat exotic subject which is canonicalisation, quite often abbreviated C14N. No, this has nothing to do with the pope and saints. This is about getting the canonical form of an XML file.
This is another article where I try to tame OpenSSL API using C++11. This time round I describe a small example showing how to verify signed data programatically. There are many message formats catering for different needs. In this example I show how to verify that the data is not tampered and is sent from a party identified by a PKI certificate. Please refer to my other article to learn how to verify a certificate.
I’d like to allude to my previous article where I superficially described how certificates and PKI work, at least the way I understand it. This time I want it to be more tangible and hope to make it helpful to anyone grappling with a problem: how to verify certificates programatically with OpenSSL API.
This time for something completely different I’ll broach a bit intimidating area—PKI certificate chains that link back both to trusted and untrusted root certificates. That is, how to recognise different trees from quite a long way away.
When programming for *nix systems, like it or not, sooner or later your application will be bothered with POSIX signals. And even if signals are considered to be a broken design, you have to live with them, hammered with some trepidation. And even if you’ve tinkered with it and managed to install some handlers, you can’t really do much in a signal handler context. You can merely set some flag and get out of there if you don’t want to get into trouble. And if you have to whack some threads in, you feel completely screwed as there’s no certainty whatsoever of which thread would receive signals. A bit intimidating, isn’t it?
Every so often an application has to deal with some sort of resources. There’s been plenty of books and articles written about it and they are all useful. They even attempt to go beyond managing memory as this is only one of many resources. The resources often mentioned are network connections, database connections, file system objects and the like. Not only the application has to release them when it’s done with them but also has to ensure that they are not held when errors occur and a different execution path is taken.
Some time ago I had a nasty issue of an application crashing due to heap corruption. Quite quickly I discovered it was related to the intensively multi-threaded nature of the test case that reproduced the crash that happened in the field. The call stacks used to end up somewhere in
free()pair. I said they used to, as there where different ways it was crashing (different call stacks in the back trace). It was another reason to think that multiple threads were making harm to each other. To make this story more exciting (or painful to me at that time), the problem couldn’t be reproduced on x86 PC. Only some specific timing conditions on the MIPSEL system could make the crash happen.
One of the reasons I mention it here is a nostalgia as my first exposure to parallel programming in the academia was with the use of processes and System V. If you’re too cool for old skool, better start with threads instead. The very first *nix system I ever used was FreeBSD. The very first *nix system I happened to use in my professional career was Solaris. And I still use hjkl to move around in vi since once I was given access to a Solaris server terminal with no arrow keys on the keyboard and vi being the only editor available on the system (visiting a large IT company in Asia as a support engineer). For these and other reason I’m probably becoming an old grumpy man.
This time I stumbled upon a challenge: integrate handling of the standard input data (a very primitive user interaction) with the
GMainLoop. I knew there must be a solution to this problem in a project like GLib. But as a busy developer I hardly ever devour entire manuals upfront with all the details. I tend to just skim through the main sections to get an idea as I prefer the RAII approach: don’t touch it if you don’t need it. Of course all small pieces of knowledge amass and at some point it’s worth to read the manual in depth to line up with what’s been learned and fill the gaps (these are quite likely huge gaps).
Usually debugging an application is straight forward: fire it up with a debugger. Even if the application requires some context (environment variables, specific directory, arguments etc.), it’s not that difficult as either it’s scriptable or the IDE will offer a plethora of options.
subscribe via RSS