How(and why) a TuxCare team member contributes to open-source software

In some of our previous articles, we’ve covered the closely integrated relationship between open-source software – which is essentially free – and the commercial organizations that rely on open-source software.

One of the points we touched on is that it’s common for employees paid by commercial organizations to contribute to open-source projects, without their employer receiving a direct financial benefit from this work.

There is a range of motivations behind this generosity. Sometimes a commercially oriented organization simply needs to add features to an open-source project out of self-interest. However, often it comes down to the symbiotic relationship between the users of open-source software – and the open source community.

For this article, we talked to one of the developers on the TuxCare team – Dmitry Antipov – to find out how the TuxCare team contributes to open source. Keep reading to see how Dmitry works with open-source software through his everyday work at TuxCare, and what the motivations are behind TuxCare and Dmitri’s contributions to open-source software.

Flagging a key problem in RPM

Dmitry started working as a software engineer in 1998, mostly working on a range of Linux projects including the Linux kernel and a range of other general system development tasks. Much of this experience was gained within the enterprise environment. Currently, Dmitry works with the Extended Lifecycle Support (ELS) team at TuxCare, but he also contributes to a range of open-source projects during his everyday work at TuxCare.

Sometimes this work arises out of an observed need. Take the case of RPM packages. A community member noticed that, for RPM packages, revoked subkeys are not in fact verified when a package is checked for a valid signature. So, even if a subkey was revoked, it will still be accepted.

It prompted Dmitry to investigate the issue – which was rather a critical problem given that for many years, users of RPM-based Linux distributions may have been installing packages where the signatures were not correctly validated.

Luck – for now

While both RPM and libdnf do a check whether a key is valid and not expired, neither checks for revocation. Thankfully, none of the RPM distributions have been hit by an attack based on this flaw.

According to Dmitri, it’s been luck essentially that keys have not needed to be revoked as was the case with the hack of Norton’s certificate authority. And, by consequence, that keys used to sign RPM packages have been stored properly, and never revoked.

Dmitri says that part of the problem is that package management projects focus on packaging management rather than cryptography. This is to be expected, and there is little need for RPM to set up its own crypto libraries. Nonetheless, Dmitri flagged the problem, and in due course, the team behind RPM package management will address it, though it’s an open question as to when this will happen.

Contributing to GlusterFS

One of the powerful aspects of the open-source community is how the community continues to address the most contemporary technology needs with cutting-edge, community-driven projects.

GlusterFS is one of these projects. To meet the needs of constantly scaled distributed server environments, a team of users started building a distributed file system that can be scaled in an arbitrary way.

The file system can handle several petabytes of storage across hundreds of notes and is a popular solution for backend storage in distributed virtual environments. However, as with all other open-source projects, GlusterFS needs continuous community input. It’s over a decade old, after all.

In talking to Dmitri, it quickly emerged that he’s contributing to GlusterFS in an important way. For some time, Dmitri has worked on the lower layers of the GlusterFS system, where the high-level system logic meets the operating system. It includes working on files, sockets, threads, synchronization, etc. More recently, he addressed some issues related to uninitialized mutexes still being used, which, even though is something that a tool like valgrind can pick up easily enough, still found their way into the codebase. He also fixed some code related to thread finalization, where some exiting threads were not freeing stack space correctly – which led to memory leaks.

Fixing the growing problem with mutexes

Our regular readers would have noticed that we’ve recently covered security flaws across a range of vulnerabilities, and that concerns around the use of mutexes and futexes have come up, with several CVEs pointing to flaws in their use.

Indeed, some of Dmitry’s contributions to GlusterFS were around mutexes – trying to resolve issues with resource leaks. According to Dmitry, when mutexes are no longer needed, they should be released – otherwise, a small yet visible resource leak will occur. While it’s not as serious as a memory leak, there is still the need for sanitized programming practices – and resources should always be cleaned up after use.

Working on open source within TuxCare

RPM and GlusterFS are just two examples of Dmitri’s contributions within the open source community. The interesting element of our developer’s work is the fact that it consumes almost all of his time at TuxCare.

In other words, Dmitri works mostly on contributing to open-source projects, even though he works within the Extended Lifecycle Support (ELS) team. We asked Dmitri how that fits in within the prerogatives of a commercial organization.

According to Dmitri, TuxCare intends to be seen as a valuable member of the open-source movement, and that the drive to deliver contributions on open-source projects comes from a management level. By sharing code created to fix issues identified in Linux distributions covered by ELS with upstream projects, those fixes will be available to everyone, thus contributing to a more secure IT environment overall.

Dmitri says he’s likely to continue to contribute to open-source projects, adding to a long list of existing contributions which beyond what we already mentioned also includes a filesystem backend sync based on POSIX AIO and improved support for running different Valgrind checkers.

The story of Dmitri a TuxCare highlights how commercial vendors work closely with open source community members to contribute to open-source projects. Together, we drive the open source project forward – and ensure that all organizations, whether government, non-government, or with a profit motive, can all continue to rely on a capable, secure open source code base.