Matthew Garrett Forks the Linux Kernel

jones_supa writes: Just like Sarah Sharp, Linux developer Matthew Garrett has gotten fed up with the unprofessional development culture surrounding the kernel. "I remember having to deal with interminable arguments over the naming of an interface because Linus has an undying hatred of BSD securelevel, or having my name forever associated with the deepthroating of Microsoft because Linus couldn't be bothered asking questions about the reasoning behind a design before trashing it," Garrett writes. He has chosen to go his own way, and has forked the Linux kernel and added patches that implement a BSD-style securelevel interface. Over time it is expected to pick up some of the power management code that Garrett is working on, and we shall see where it goes from there.

Comments

securelevel who?

[fisted]

Just for the people who don't know what the fuck securelevel is (NetBSD's flavor in this case)

Not going back to Linux, but this really is a worthwhile addition.

Not really

[Kjella]

Branching happens all the time, either to develop a feature or because it's doing something that upstream won't accept. One man maintaining his own patches isn't a fork. A fork would imply that that you're planning to diverge from or replace the project you branched from, nothing in his post indicates he wants to compete with Linux or the LKML. He's just saying I'll make my own patches and provide them for those who want them, but I'm not going to bother trying to upstream them. Kinda like Debian and Ubuntu, Canonical made a lot of patches for Debian but they weren't trying to fork it. They just rebased off it every six months, being a downstream variation. He's making a downstream variation with some interface from BSD. Big whoop.

for those wondering about the deepthroating

[nimbius]

https://lkml.org/lkml/2013/2/2... Matt got reamed for this because it was a stupid idea, not because the environment was somehow too immature. from Linus Torvalds himself:

Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

By the time SCALE 11 hit, Matt was no longer working at redhat. people moved on. A Fork was always an option for Matthew...just perplexed as to why he decided to do it 2 years after...

Re:for those wondering about the deepthroating

[JumboMessiah]

For those not wanting to read anything historical. The confrontation comes because the Secure Boot option of UEFI (if enabled) only ships with Microsoft keys in the firmware. Thus, Microsoft's signing service is the only practical signing service and will only sign a PE executable. The solution that Matt and company came up with was to have a module vendor wrap their keys in a PE executable, have Microsoft sign them, and then ship the signed PE executable with the signed Linux kernel module. Verification of the signed Linux module thus requires the Linux kernel to load the PE executable, verify its signature, then extract the vendor keys and continue on.

Linus rightly called out the idea as moronic and stupid. The retorts basically came in the form of "Microsoft created the standard, and is the only viable signing service for the standard". Even though alternative options could of been had, they were deemed to complicated and involved.

Life would of been much easier of Microsoft would just sign X.509 certificates like the rest of the world.

Read more about it here.

Re:Waaaahhhhh!!

[tweak13]

This is the "deepthroating Microsoft" he's referring to: https://lkml.org/lkml/2013/2/21/228

It was a pretty stupid idea, and it isn't surprising that Linus shot it down.