No More Security
Florian WeimerOn October 1, 2015, I joined the Red Hat tools team, to work full-time on the GNU C library (glibc). I will spend a significant part of my time contributing to upstream development.
Professionally, this is a rather significant change for me. Since 1999, I have been employed in various forms (first as a student, later as a full-time employee) to work on security-related matters. The exception is a year where I finished my studies, to get my math diploma (but during that time, I worked on Passive DNS Replication).
Mentally, the change is more like a gradual shift. I still work for Red Hat, and maybe the reality of the change still needs to sink in. But I have been a fan of the GNU toolchain for a long time—my first computer on the Internet was called cygnus.stuttgart.netsurf.de. A few years before that, in the earlier 1990s, I had tried to learn C from a raw Texinfo printout of the GCC manual (with Texinfo commands such as @item and @code included in the printout), but I failed because the GCC manual does not actually document the C language. But the fascination was already there.
Even while working at Red Hat Product Security, I was already contributing toolchain improvements, such as the operator new[] hardening for C++
, or the fix for CVE-2014-5119 in glibc.
My main focus, glibc (the GNU C Library, which sits between the Linux kernel and almost all applications, except those written in Go), has its fair share of security bugs, as the Debian Security Tracker page for glibc shows. And the Debian view is even incomplete because it is mostly based on assigned CVE identifiers. There are many security+ bugs in glibc without CVE assignment, and some of them are still waiting for fixes.
But in general, I'm looking forward to fixing non-security bugs most, especially those that matter to actual users. With security bugs, it is sometimes difficult to tell if fixing them really makes a difference. (From a slightly extreme point of view, the only really important security bug to fix is the last one remaining in the software; before that, fixes are just window-dressing.) But if you can fix a problem a developer runs into writing their application (or, somewhat worse, fixing a defect a user encounters), you are helping a real person, which is much more satisfying, and the benefit is far easier to see.
There is no risk that we will run out of bugs to fix, security or otherwise. I am really excited that I am now contributing to the GNU project in a very direct way.
Revisions
2015-10-18: published