Ipmitool archival, detection, and project ownership

On March 13, Phoronix published an article noting how an open source maintainer’s GitHub account was suspended, and all of his projects were archived. A Phoronix reader seems to have reached out to the Phoronix author after finding that the ipmitool project had been archived on GitHub. A later post on Phoronix noted that the cause was related to the author’s affiliation. As noted on a hackernews post, the organization, YADRO-KNS, seems to be sanctioned by the US government, and all of the members’ repositories seem to be archived. Our orphaned projects study noted that project archival was an indicator of project abandonment. In this writeup we will focus on the archival of ipmitool, what the project is, how we can detect project archival on GitHub, notable forks, and the ownership epochs of ipmitool.

Ipmitool is a system management utility used to interface with low level hardware on servers. These functions typically include system power resets, baseboard management controller functions, embedded shell commands, or even i2c read/write commands to hardware. As an example, IBM documentation shows how to flash a BIOS remotely using ipmitool raw commands. These functions are not visible at the operating system level. Unless some error occurs at this lower level that manifests symptoms at a higher layer, functionality changes in this system management code might not be noticed. Therefore, if a security issue like a backdoor, Trojan, or injected vulnerability is present or introduced into this utility, it could be difficult to detect. Any adversary use would likely depend on local or remote access to IP management interfaces. Raw network requests could be used in some cases. Backdoored or underhanded code in this and similar tools is a security risk, but risk discovery through the occasional formal or informal audit of such open source projects. However, audits are not perfect and are not frequent; indeed auditing every line of code in our systems is not feasible. As we mention above, our study of orphaned projects found that the archival status of GitHub repositories is a property strongly associated with orphaned projects. Ipmitool’s archival resurfaces one question that was not addressed in our previous research study: how do we detect archive projects on GitHub? As we had run into GitHub rate limits in the past, we attempted to use archived events from the Github Archive Project, which accumulates an archive of all public GitHub events. While there were 35,876 events with the keyword ‘ipmitool’ in the archive, we found that there was not an event for ipmitool’s archival.

Some GitHub events will note that a repository was archived at the time of the event, but that is not what we are looking for in this case. After looking further into the GitHub event documentation, we found that the repository API allows us to see the archival status of a project. Therefore, one of our health checks for a project should probably include periodic repository API callouts to see if a project is archived.

A central step to orphaned project investigations is to check for notable forks or the project. We first used the GitHub network page to see if any forks had development activity after the public archival. One notable fork is Cray/HP Enterprise’s fork, which builds on Ipmitool’s mainline code with some of their own fixes added. Other users such as WJQ1252-, Mjyang5566, htheiry, and coklm have one or two fix commits in their forks.

Our previous findings noted that new development might point toward a new repository and ownership shift, but as noted in a sourceforge post, the maintainer is looking for a way to unblock their GitHub account or “migrate to a less hostile service”, so there may be no change in project ownership. It will be interesting to see whether this negatively impacts the maintainer’s activity in the project, and if ownership shifts to a new person or organization. The selection of a new upstream repository might be reflected in package maintainer sites for various Linux distributions (debian, ubuntu, etc). While looking at the main GitHub page for ipmitool, we saw that the README begins with the following text:

                             ipmitool
                            Duncan Laurie
                [email protected]

This is not the banned user (AlexanderAmelkin). Who is Duncan Laurie, and were they a project owner? How did ownership change from Duncan to Alexander (if it did)? We ingested the git repo into OSSRanger for further investigation. In this inquiry, we look at authors, committers, and time zones of commits to piece together ownership shifts in ipmitool.

Figure 1. Commits per month in ipmitool, split by author name. 2003 - Present

When we plotted authors per month over time we found there to be three main periods of time with authors who contributed most of the code:

• November 2003 - September 2006: Duncan Laurie
• December 2011 - March 2017: Zdenek Styblik
• March 2018 - December 2022: Alexander Amelkin (with 3 initial commits in Feb 2017, and a lull in developer activity until their ownership in 2018)

Figure 2. Commits per month in ipmitool, split by committer name

The histogram graph of activity in Figure 2 shows less variation when we plot committers (vs authors as in Figure 1). It is interesting to see that the first two owners allowed other authors to make commits; under Alexander, however, almost all commits were committed by this person.

Figure 3. Commits per month, colored by timezone

When we plotted the timezone for commits, they seemed to correlate with ownership shifts. Under Duncan Laurie all commits had “tz: 0”, which suggests a presence in the UK. Under Zdenek Styblik commits were initially in “tz: 0”, but later shifted to be +1 or +2, possibly associated with Central European Summer Time timezone shifts. Finally, in Alexander’s epoch most commits had timezone +3, associated with Moscow time. In this case it seems that timezone analysis reflects geographic shifts of ascendent personas in ipmitool. Ongoing timezone–based analysis of critical projects might be an indicator of similar ascendency shifts (this is similar to timezone shifts we saw very early on in our analysis of the Linux kernel, where some commits correlated with Linus’s known public location at those times, such as attending a conference). It is important to note that where a developer lives does not indicate they are bad actors.

In this brief report we examined a project archival event that has received some public attention. We looked at associated forks with development activity. Although the project is archived, it may not be abandoned (it may migrate to a new source control hosting service). By building on our past orphaned projects study we found an approach that allows us to scan GitHub repos to check if projects are archived. This procedure could be built into a feature that can allow OSS Ranger to automatically detect when a GitHub project is archived. We looked at the largest contributors to the ipmitool project and discovered three main owners over time. Our timezone analysis of commits correlates with the discovered ownership changes. It will be interesting to follow the activity of this repository and its forks and derivatives as an unfolding example in our set of orphaned projects.

Disclaimer: This material is based upon work supported by the Defense Advanced Research Projects Agency (DARPA) under Agreement No. HR00112190094. Approved for public release; distribution is unlimited.

The views, opinions, and/or findings expressed are those of the author(s) and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.