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.