Slashdot Mirror

Earlier this month Bruce Perens notified us that "the Software Freedom Law Center, a Linux-Foundation supported organization, has asked USPTO to cancel the trademark of the name of the Software Freedom Conservancy, an organization that assists and represents Free Software/Open Source developers." Now Slashdot reader curcuru -- director of the Apache Software Foundation -- writes: No matter how you look at it, this kind of lawsuit is a loss for software freedom and open source in general, since this kind of USPTO trademark petition (like a lawsuit) will tie up both organizations, leaving less time and funds to help FOSS projects. There's clearly more to the issue than the trademark issue; the many community members' blog posts make that clear.

GNOME executive director Neil McGovern
Apache Software Foundation director Shane Curcuru
Google security developer Matthew Garrett
Linux industry journalist Bryan Lunduke

The key point in this USPTO lawsuit is that the legal aspects aren't actually important. What's most important is the community reaction: since SFLC and Conservancy are both non-profits who help serve free software communities, it's the community perception of what organizations to look to for help that matters. SFLC's attempt to take away the Conservancy's very name doesn't look good for them.

Bryan Lunduke's video covers the whole case, including his investigation into the two organizations and their funding.

prisoninmate quotes a report from Softpedia: According to Matthew Garrett, a renowned CoreOS security developer, and Linux kernel contributor, Canonical's new snap package format is not secure at all when it is used under X.Org Server (X Window System), which, for now, it is still the default display server of the Ubuntu 16.04 LTS (Xenial Xerus) operating system. The fact of the matter is that X11's old design is well-known for being insecure, and Matthew Garrett took the time to demonstrate this by writing a simple snap package that can steal data from any other X11 software, in this case anything you type on the Mozilla Firefox web browser. As more developers will provide snaps for their apps, Canonical needs to do something about the security of snaps in Ubuntu when using X11 or switch to the Mir display server. In the meantime, the security of snaps remains unaffected for the Ubuntu Server operating system, which is usually used without a display server. Canonical has officially released Ubuntu 16.04 LTS, which is now available to download for those interested.

jones_supa writes: The hotel in which Matthew Garrett was staying at, had decided that light switches are unfashionable and replaced them with a series of Android tablets. In his tour to the system, one was quickly met with a glitch message "UK_bathroom isn't responding." Anyway, two of the tablets had convenient-looking ethernet cables plugged into the wall, so MacGyver began hacking. He managed to borrow a couple of USB ethernet adapters, set up a transparent bridge and then stick his laptop between the tablet and the wall. Tcpdump showed traffic, and Wireshark revealed that it was Modbus over TCP. Modbus is a pretty trivial protocol, and does not implement authentication. The Pymodbus tool could be used to control lights, turn the TV on/off, and even close and open the curtains. Then he noticed something. His room number was 714. The IP address he was communicating with was 172.16.207.14. They wouldn't, would they? Indeed, he could access the control systems on every floor and query other rooms to figure out whether the lights were on or not, which strongly implies that he could control them as well.

The Linux Foundation, though it's straightforwardly not a grassroots organization along the lines of the FSF or EFF, has long had a degree of non-corporate involvement by way of community-elected members on its board. Now, writes new submitter Ensign Nemo, that's no longer true. An excerpt from Matthew Garrett's blog on the change: The by-laws were amended to drop the clause that permitted individual members to elect any directors. Section 3.3(a) now says that no affiliate members may be involved in the election of directors, and section 5.3(d) still permits at-large directors but does not require them[2]. The old version of the bylaws are here - the only non-whitespace differences are in sections 3.3(a) and 5.3(d).

These changes all happened shortly after Karen Sandler announced that she planned to stand for the Linux Foundation board during a presentation last September. A short time later, the "Individual membership" program was quietly renamed to the "Individual supporter" program and the promised benefit of being allowed to stand for and participate in board elections was dropped (compare the old page to the new one).

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.

jones_supa writes Some of us remember the story of why Linux kernel responds "False" when ACPI BIOS asks if the operating system is Linux. We have found yet another case where mimicking the Windows behavior instead of writing to the spec is the right choice if you just want your machine to work properly. The ACPI spec defines the _REV object as evaluating to the revision of the ACPI specification that the OS implements. Linux returns 5 for this, because Linux actually tries to implement ACPI 5.0, but Windows returns 2 (ACPI 2.0), possibly due to legacy reasons. Linux kernel expert Matthew Garrett discovered that still a fair amount of brokenness appears when 5 is returned as the revision, including a Dell machine which left the sound hardware in a misconfigured state. He is proposing a kernel patch which simply reports _REV as 2 on all x86 hardware.

GNU Mailman, likely the most popular mailing list manager in use today, has finally announced the release of a beta for version 3. GNU Mailman 3.0 is a major rewrite, features include a central server with a REST API replacing the dozen or two programs that manipulated Mailman data directly, a shiny new web fron end (Postorius), and a new archiver (HyperKitty). Fedora is already using the new archiver and interface, which is quite a bit more modern looking than Mailman 2.x's interface (wayback machine link for posterity). Individual message thread views are greatly improved, and you can even reply from the web by logging in with your list credentials. If you'd like to try it out, see the announcement message.

sfcrazy writes "The controversy over Canonical's Contributor License Agreement (CLA) has once again surfaced. While Matthew Garrett raises valid points about the flaws in Canonical's CLAs, Linus Torvalds says 'To be fair, people just like hating on Canonical. The FSF and Apache Foundation CLA's are pretty much equally broken. And they may not be broken because of any relicencing, but because the copyright assignment paperwork ends up basically killing the community. Basically, with a CLA, you don't get the kind of "long tail" that the kernel has of random drive-by patches. And since that's how lots of people try the waters, any CLA at all – changing the license or not – is fundamentally broken.'"

First time accepted submitter slack_justyb writes "Matthew Garrett, former employee of Red Hat, comments on the current state of XMir and Canonical's recent decision to not ship XMir as the default display server in Ubuntu 13.10. Noting the current issues outstanding in XMir, the features yet to be implemented, the security loopholes, and Intel's recent rejection to support Mir in general. All of this leading Garrett to the conclusion that 'It's clear that XMir has turned into a larger project than Canonical had originally anticipated, but that's hardly surprising.'"

Seemingly to inflict more suffering upon himself, Matthew Garrett (lord of getting things to boot using EFI) decided that booting directly into Zork would be cool. Quoting his weblog entry: "So, Frotz seemed like the natural choice when this happened. But despite having a set of functionality that makes it look much more like an OS than a boot environment, UEFI doesn't actually expose a standard C library. The EFI Application Development Kit solves this particular design decision. Porting Frotz ended up involving far more fixing up of Frotz bugs that tripped up -Werror than anything else. One note, though - make sure you include DevShell in the list of required packages at build time, otherwise file i/o will mysteriously fail." Grab the code, assuming you have a copy of Zork (or any other Z-machine game, as long as you name it ZORK1.DAT, I think).

First time accepted submitter YurB writes "Matthew Garrett, a Linux kernel developer who was investigating the recent Linux-on-Samsung-in-UEFI-mode problem, has bricked a Samsung laptop using a test userspace program in Windows. The most fascinating part of the story is on what is actually causing the firmware boot failure: 'Unfortunately, it turns out that some Samsung laptops will fail to boot if too much of the [UEFI] variable storage space is used. We don't know what "too much" is yet, but writing a bunch of variables from Windows is enough to trigger it. I put some sample code here — it writes out 36 variables each containing a kilobyte of random data. I ran this as an administrator under Windows and then rebooted the system. It never came back.'"

hypnosec writes "With Linux enthusiasts and distro publishers eagerly waiting for a solution to Microsoft's UEFI SecureBoot, there are those who have already looked at the viability of Linux on Microsoft Surface tablet. Matthew Garrett, a.k.a. UEFI-guru, has revealed that those who are keeping their fingers crossed and hoping to find run Linux on Microsoft's tablet are on an uphill walk and it doesn't seem to be an easy one. So why is this? The answer is in the manner in which Microsoft has restricted the Surface from loading non-signed software / binaries by implementing UEFI SecureBoot. Microsoft has loaded on the ARM based tablet its private key instead of the 'Microsoft Windows UEFI Driver Publisher' key, which is needed to sign non-Microsoft software like Linux distributions or loaders. So, no publisher key = no signed non-Microsoft binary = no Linux."

TrueSatan writes "Matthew Garrett, formerly of Red Hat, is providing a shim bootloader that will allow installation/booting of secure boot enabled computers. The shim is designed to chain boot GRUB (Grand Universal Bootloader) without the need for a distribution to obtain a key from Microsoft. Garrett asks that further contacts regarding the shim be made to him and not to Red Hat as he no longer works there and they may not have knowledge of the product."

New submitter Nagilum23 writes "It looks like Lenovo only knows of Windows and RHEL where their Thinkcentre M92p desktop is concerned. While investigating UEFI boot issues, Matthew Garrett found the PC's firmware actually checks the descriptive string for the operating system, and will prevent unlisted operating systems from booting. Garrett writes, 'Every UEFI boot entry has a descriptive string. This is used by the firmware when it's presenting a menu to users - instead of "Hard drive 0" and "USB drive 3", the firmware can list "Windows Boot Manager" and "Fedora Linux". There's no reason at all for the firmware to be parsing these strings. ... there is a function that compares the descriptive string against "Windows Boot Manager" and appears to return an error if it doesn't match. What's stranger is that it also checks for "Red Hat Enterprise Linux" and lets that one work as well. ... This is, obviously, bizarre. A vendor appears to have actually written additional code to check whether an OS claims to be Windows before it'll let it boot. Someone then presumably tested booting RHEL on it and discovered that it didn't work. Rather than take out that check, they then addded another check to let RHEL boot as well." Note that this isn't a SecureBoot issue. Lenovo is aware of the problem and looking into it.

sfcrazy writes "Red Hat's Tim Burke has clarified Fedora/Red Hat's solution to Microsoft's secure boot implementation. He said, 'Some conspiracy theorists bristle at the thought of Red Hat and other Linux distributions using a Microsoft initiated key registration scheme. Suffice it to say that Red Hat would not have endorsed this model if we were not comfortable that it is a good-faith initiative.'" Color me unimpressed, and certainly concerned: "A healthy dynamic of the Linux open source development model is the ability to roll-your-own. For example, users take Fedora and rebuild custom variants to meet personal interest or experiment in new innovations. Such creative individuals can also participate by simply enrolling in the $99 one time fee to license UEFI. For users performing local customization, they will have the ability to self-register their own trusted keys on their own systems at no cost." From what I can tell, the worst fears of the trusted computing initiative are coming true despite any justifications from Red Hat here. Note that the ability to install your owns keys is certainly not a guaranteed right.

ToriaUru writes "Fedora is going to pay Microsoft to let them distribute a PC operating system. Microsoft is about to move from effectively owning the PC hardware platform to literally owning it. Once Windows 8 is released, hardware manufacturers will be forced to ship machines that refuse to run any software that is not explicitly approved by Microsoft — and that includes competing operating systems like Linux. Technically Fedora didn't have to go down this path. But, as this article explains, they are between a rock and a hard place: if they didn't pay Microsoft to let them onto the PC platform, they would have to explain to their potential users how to mess with firmware settings just to install the OS. How long before circumventing the secure boot mechanism is considered a DMCA violation and a felony?" Note that the author says this is likely, but that the entire plan is not yet "set in stone."

itwbennett writes "The debate over enforcement of the GPL flared up again this week when Red Hat kernel developer Matthew Garrett wrote in a blog post that Sony is looking to rewrite BusyBox to sidestep the GPL. Which is a perfectly legal undertaking. But it raises the question: 'Is there social pressure within the Linux kernel community to not undertake GPL compliance action?' writes blogger Brian Proffitt. 'This may not be nefarious: maybe people just would rather not bother with enforcing compliance. Better, they may argue, to just let the violation go and get on with developing better code.'"

MojoMax writes "The advent of Windows 8 is drawing ever nearer and recently we have learned that ARM devices installed with Windows 8 will not be able to disable the UEFI secure boot feature that many of us are deeply concerned about. However, UEFI is still a very real danger to Linux and the freedom to use whichever OS you chose. Regardless of information for OEMs to enable customers to install their own keys, such as that published by the Linux Foundation, there are still very serious and as yet unresolved issues with using secure boot and Linux. These issues are best summarized quoting Matthew Garrett: 'Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.'"

In his first accepted submission, lukemartinez sends in an excerpt from a ZDNet article on continuing developments about Microsoft's UEFI secure boot requirements: "The Linux Australia community began petitioning the ACCC this week after Microsoft aired plans to mandate the enabling of Unified Extensible Firmware Interface's secure boot feature for devices bearing the 'Designed for Windows 8' logo. This means that any software or hardware that is to run on the firmware will need to be signed by Microsoft or the original equipment manufacturer (OEM) to be able to execute. This would make it impossible to install alternative operating systems like Linux..." Delimeter has further information on the petititions, and Matthew Garret recently posted a follow-up to Microsoft's response to the concerns about secure boot, calling them out on their misinformation.

Julie188 writes "Windows 8 PCs will use the next-generation booting specification known as Unified Extensible Firmware Interface (UEFI). In fact, Windows 8 logo devices will be required to use the secure boot portion of the new spec. Secure UEFI is intended to thwart rootkit infections by using PKI authentication before allowing executables or drivers to be loaded onto the device. Problem is, unless the device manufacturer gives a key to the device owner, it can also be used to keep the PC's owner from wiping out the current OS and installing another option, such as Linux."