Jiri Kosina: Services needed from kernel.org infrastructure

July 22, 2015

Related Material:

  1. August 25, 2014 LWN article: Kernel.org news: two-factor authentication and more

Additional Participants: Andy Lutomirski, Dmitry Torokhov, Fengguang Wu, Geert Uytterhoeven, Greg KH, Guenter Roeck, James Bottomley, Jason Cooper, Josh Triplett, Konstantin Ryabitsev, Mark Brown, Steven Rostedt, and Theodore Ts'o.

People tagged: Andrew Morton, Greg KH, Konstantin Ryabitsev, and Linus Torvalds.

Jiri Kosina proposes a session where maintainers provide feature and improvement requests for the kernel.org infrastructure. Jiri's request is a facility that automatically sends out email when a new commit is pushed to a git.kernel.org repo branch, similar to what tip-bot and Andrew Morten's scripts do. Mark Brown agreed that notification is useful, and has his own scripts, but feels that it is better to keep doing it on his system because this permits better fine-tuning. Jiri Kosina replied that centralization has benefits, including reducing duplication of work. Jiri also suggested that a patch with the following ownership might be a “little Bobby Tables” event for a great many scripts:

Jiri Kosina <jkosina`rm -rf .`@suse.com>

Jiri also expressed the hope that a properly maintained server-side script might be more robust and maintainable.

Mark Brown replied that he needed custom scripts to tie into his workflow and suggested that a server-side script might instead provide a way to quickly attack a larger number of developers. Theodore Ts'o agreed with Mark, adding that a server-side script would require substantial configuration ability, for example, spamming developers each time a branch was pushed for the sole purpose of getting the 0day test robot to run on it might not be appreciated by the spammed developers. Ted also noted that running shell scripts on master.kernel.org can be a significant security issue in its own right. Jason Cooper agreed with Ted on the spamming thought, but suggested a naming convention to indicate which branches should trigger spamming. However, Jason disagreed with Ted on the security issue, suggesting that developers might have high-value private keys not present on the server, and also calling out the fact that kernel.org has full-time professional sysadmins. Jiri Kosina liked the thought of a naming convention, and suggested that the notification be run on a “scratch” single-purpose system that had no valuable information and that could be quickly and easily rebuilt in case of attack. However, Greg KH opposed shell access on any of the kernel.org systems, including git hooks, preferring the current system of maintainers sending any needed emails from their own systems. That said, Greg agreed that a number of the scripts he was was aware of are vulnerable to the “little Bobby Tables” attack, and thanked Jiri for motivating him to fix this problem. Greg reiterated the need for maintainer-run scripts adapted to each maintainer's workflow. Jiri countered that there was likely to be a least-common-denominator approach that was sufficient for many (but not all) maintainers, to which Josh Triplett agreed. Steven Rostedt prefers a developer-pull model, so that developers are not involuntarily spammed.

Dmitry Torokhov requested scripts, and got the following responses:

  1. Greg KH
  2. Geert Uytterhoeven
  3. James Bottomley
  4. Konstantin Ryabitsev

Fengguang Wu suggested that the 0day test robot might host notification scripts, possibly located at:


This prompted Steven Rostedt to ask if there was a web page that he could refer to to locate checkpatch issues on his repos. Fengguang Wu replied that the 0day test robot reports only new checkpatch warnings introduced by the patch rather than any that might be pre-existing in the file.

Jason Cooper called out the recruitment benefits of notification, of whatever type. Jason was hooked on Linux-kernel development upon receiving the automated patch-acceptance emails from Greg and Andrew. Jason also asked some scope questions:

  1. What will the script do?
  2. What will it not do?
  3. Should we try it for a year and report back?
  4. How do we quantify success/failure?
  5. Who is going to write it? Maintain it?

Andy Lutomirski would like something like patchworks for LKML in order to make it easier to pull patchbombs into his repository. Guenter Roeck asked what was wrong with https://patchwork.kernel.org/project/LKML/list/, to which Andy replied “It's not spelled "linux-kernel". /me runs away.”