Zack's Kernel News
File Name Encryption in eCryptFS
The eCryptFS filesystem continues to make plenty of interesting progress. Recently, Michael Halcrow, Tyler Hicks, and David Kleikamp implemented code to encrypt file names on the system. Their code relies on a passphrase to derive an encryption key that is then specified as input at mount time. An interesting detail is that the encryption process yields an encoded file name that might be slightly longer than the original; so, if the original file name is already close to the maximum length allowed by the system, eCryptFS will be unable to encrypt that name.
File name encryption is also optional. Each encrypted file name is stored with a prefix that identifies it as an encrypted file name, and not just the user's choice for the name of that file. To avoid confusion over which file names really need to be decrypted and which merely have the special prefix because the user included it as part of the legitimate name of the file, eCryptFS also stores the rest of the file name in a particular format. If eCryptFS sees the prefix that usually indicates an encrypted name but does not see the appropriate format for the rest of the encrypted file name, it assumes the file name was not actually encrypted, and that the user intended it to have the name it has.
Status of MMC Code Reviews
Pierre Ossman has been running interference on flash MMC memory card code submissions, but recently he had a wave of self-doubt. He asked for feedback on how well he'd been handling his own feedback on other folks' code contributions, and he exhorted folks to take up some of the slack and give their own comments on MMC submissions. A big pile of people responded that they thought he'd been doing a great job giving his feedback – even in cases in which the person praising him was somewhat frustrated at not being able to get code past his rigorous inspections.
Protocol Adjustments for linux-next
Stephen Rothwell recently clarified the requirements for being included in the linux-next tree. For starters, a tree would only be included in linux-next if its patches had been posted to the relevant mailing lists and been properly reviewed. The tree must also have been unit tested, and it must be the maintainer's intention to merge the tree into the official kernel during the next available merge window.
Stephen also explains what events might conspire to cause a tree to be dropped temporarily (i.e., until the problems are addressed) from linux-next. This includes any conflict with Linus Torvalds' tree that is not trivial to resolve. Any tree that won't successfully build also will be dropped. This goes along with the idea that the trees in linux-next should really be tip-top from the get-go, since they are angling to go right into Linus' tree. Another way to get a tree bumped is if it conflicts with other trees in linux-next in ways that are not trivial to resolve. The unstated assumption is that if your tree conflicts, you must have caused the conflict and should therefore be the one to resolve it. In practice, both conflicting tree maintainers can work together to resolve the conflict.
All of this represents a slight change in Stephen's policy. Until now, he had been willing to make patches on his own to allow the code to build successfully. But from now on he will not. Any tree that doesn't build, he said, will be dropped until it is fixed. On the other hand, Stephen said he is still willing to fix slight conflicts between trees and doesn't intend to be a stickler about insisting that even the most trivial conflicts result in a tree being dropped. During the merge window, he would hope to see virtually everything drop out of linux-next and be folded into the main-line kernel. Outside of the merge window, Stephen said he intended to keep the tree in a state that Andrew Morton would find convenient for creating his own -mm trees.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs