Would the Core Infrastructure Initiative be willing to sponsor a cryptographer to review it?
Getting this right would make it a lot easier to have faith in encrypted backups. Right now, you have to trust that each network backup product like bacula is doing it right.
I just randomly picked bacula and then looked up what they are doing. They're using OpenSSL with AES-CBC. I don't think anyone would recommend that.
As a start, it would be nice if Datto could document the design decisions. For instance, AES-CCM is a bit of a strange default and it's not explained anywhere. I see Solaris chose AES-128-CCM and maybe that influenced why OpenZFS is using AES-256-CCM. I haven't found a cryptographer in favor of CCM over GCM. For instance, Matthew Green doesn't appear to like it over GCM.
Given that GCM IV reuse is catastrophic and one of the main use cases for this is backups to potentially untrusted sources, I'm curious if AES-GCM-SIV would be a more conservative choice.
I'm Tom Caputi, author of the ZFS encryption patch and I can answer of few of your questions.
First of all, the choice of AES-CCM. I have had a few people ask me why we didn't chose something like ChaCha20 as a block cipher instead of AES. This is largely because AES is by far the most scrutinized block cipher around. It's use is currently so widely accepted that modern Intel CPUs have built-in AES instructions to improve performance. While its true to say that ChaCha20 (or other block ciphers) might theoretically be faster or that they ARE faster on some architectures like 32-bit cell phone CPUs, this is not currently the case with the vast majority of ZFS deployments.
As far as the choice for CCM as a default goes, this one was a little bit harder. Originally this decision was made to match the Oracle implementation as much as possible (a design decision which has since been dropped). Later, when we re-evaluated the descision, we found a paper (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comment...) indicating there might be weaknesses with the authentication mechanism, although the paper only mentioned cases with truncated authentication tags. So in the interest of being as conservative as possible, we chose the option which looked the most secure. We did not look into AES-GCM-SIV since it is very new (it looks like it actually came out this year) and so I would not by any means consider it a "conservative" choice.
As far as performance goes, we have not yet (as far as I'm aware anyway) seen a case where read or write speed wasn't bottlenecked by the disk speed. The benchmarks you posted are (as far as I can tell) single threaded and ZFS processes each block asynchronously.
The biggest thing here is that AES-256-CCM is only the default. It is easy for users to pick GCM for the time being and for developers to add newer, better encryption algorithms and change the default as time goes on. I wouldn't be surprised i we had changed the default by the time that the patch ends up in a tagged release.
I'm not a cryptographer, but for your dedup version, you might want to consider using SIV mode [1,2]. It provides a well known, already vetted deterministic authenticated encryption, so you don't have to build your own from HMAC etc and then get it vetted.
Thank you for the suggestion. As I said above, there is nothing preventing something like that from being implemented in ZFS in the future. Unfortunately, however, the encryption implementation uses a port of the Illumos Kernel Crypto Framework, which has not yet implemented an SIV mode.
As far as using our own HMAC goes we are using a standard SHA512-HMAC implementation which should be just as secure.
This isn't as easy as it sounds. Pledge works in OpenBSD because OpenBSD is simple and all of the necessary code lives in one tree. Pledge is supported in the vast majority of OpenBSD base programs but very few ports. If programs aren't written in a careful manner or with an eye to privsep, you end up with pledges that don't protect much since they are so broad. There are a lot of programs you can't pledge even with all options turned on because pledge has a whitelist on the kernel side for what it allows.
It's not impossible for Linux, but there would have to be a lot more conditional cases in the Linux kernel to handle all of the various ways that programs would use it. The Linux ecosystem is massive and the number of alternatives for even basic daemons is large. Instead of pledge, you may end up with a syscall filter or something like FreeBSD's capsicum. Both of those are more complex because it puts all of the effort on the application developer and also gets in their way.
Straight syscall filters and complex systems like capsicum are designed to allow for arbitrary programs to be protected. In doing so, it moves all of the complexity to the application developer. The advantage of pledge is that it does not attempt to be completely generic. Pledge is designed for how OpenBSD programs are written and what's in the OpenBSD tree. It may evolve over time to include some functionality for ports, but the overall design is to make a subset of well written programs easy to protect. If you try to pledge arbitrary programs, you'll find it doesn't work out unless you rewrite the program logic to be more well written.
Pledge is conceptually simple, but the kernel side shows how it was tightly integrated into OpenBSD's way of doing things and has evolved to make it simpler (by relaxing some behavior or whitelisting parts) and breaking up other permissions to make it more fine grained when needed.
These are good points. However unlike SELinux / AppArmor, a Debian package maintainer does not need to do make sure things are set up right for pledge- programs that aren't pledge'd will run just fine (i.e. all syscalls are allowed by default, not the other way around). So even though adding pledge to the kernel does nothing by itself, can't usermode programs (the ones for which pledge makes since) slowly make themselves more secure?
> It's not impossible for Linux, but there would have to be a lot more conditional cases in the Linux kernel to handle all of the various ways that programs would use it.
Why would there be a lot more conditional cases in the kernel? I'm just imagining having a bitvector whitelist[] for each task_struct and then in the syscall_trace_enter functions one indexes into current->whitelist if it's __NR_pledge.
- HEADLINE: Bring back the standard (console) Live CD
- DESCRIPTION: Jessie had a standard Live CD. While the HTML still refers to this flavor, it is not found on any mirror that I checked for Stretch.
I have to use the live CD to install ZFS on Root. I would prefer to not bother downloading or booting a desktop environment when I don't need one.
I don't know why it was removed, but the name was always strange to me. Name it textonly or expert or something so people don't choose it. Standard sounds like it is the recommended image.
DESCRIPTION: There are a ton of packages in Debian. I sometimes browse through all of the packages looking for some gem that I didn't know about before. It's a time intensive process and I don't have any input into my decision other than reading the description. Sometimes I'll install it immediately. Other times I'll check out the website to see if it's still maintained (or if there's a better alternative). It's all a very manual process.
popcon doesn't fill this void. Popcon tells me what packages are popular across all users. I'm more interested in what a subset of users with similar interests or preferences would install. Or maybe I want to see what it's like to live in someone else's shoes. For instance, maybe I'm learning a new programming language and I want to setup my environment similar to an experienced user so I have all of the popular libraries already installed.
It would be nice if there was a better way to discover packages that are relevant to you. Perhaps you could add this feature as a way of getting people to install popcon? For example, you could say if you install popcon, then it will upload your set of installed packages and make recommendations for you.
If people are able to add metadata about themselves (e.g. I'm an expert Emacs user and I'm a golang developer), then you could use that plus their package list to make recommendations. I could say "show me what packages golang developers tend to install". Or you could say "for someone with a package list similar to mine, find out what packages are popular that I'm missing".
Popcon also has the disadvantage that it has an unconscious bias: if you care about security, you don't send your package lists out to be part of the survey.
Corporations setting policy for their systems are also unlikely to install popcon.
The overall effect is to bias popcon in favor of home users who don't think much about security.
DESCRIPTION: Debian unstable still has elixir 1.3.3. It looks like the "official" path forward is to add Erlang Solutions as another apt repository and install packages from there. However, this feels wrong to me as a user. I want to get packages from Debian.
I can't remember which distribution it is, but IIRC one of the other ones has developers upload builds from their personal machines and they are signed with GPG. I don't like this because it is opening yourself up to problems. Perhaps someone uploads a malicious binary build. Or perhaps their developer machine is compromised and someone else uploads it for them or infects their upload.
All of this would go away with 100% reproducible builds in Debian and when it builds on Debian infrastructure. That's not the case when Erlang Solutions is setup as the provider.
I realize this is a minor point as few people will install it, but I was surprised that other distributions include the latest Elixir but Debian does not. The latest is 1.4.4 and I couldn't find anything related to 1.4.x in the upload queue or bug reports. It seems like the package maintenance has been outsourced to Erlang Solutions.
HEADLINE: More fine grained meta packages as community recommendations.
DESCRIPTION: There are a few Debian meta packages but they are really broad. Example: it would be great if there were a few developer leaning packages grouped into one meta package.
For instance, I always install etckeeper, apt-listchanges and apt-listbugs. I think anyone following testing or unstable would want to install those and I'm not aware of any real alternatives to those. I can't imagine using unstable without apt-listbugs to warn you when there high priority bugs in the packages that were already uploaded.
OpenSSL doesn't follow semantic versioning. This is not a simple version upgrade. They knowingly broke the API between 1.0 and 1.1 and it can require substantial changes. They also refused to provide a compatibility shim to make it easier for developers to migrate.
This is not a Debian problem. This is an OpenSSL problem where they forced each upstream program author to make changes in order to upgrade. You'll have to wait for each upstream program author to update.
HEADLINE: First class ZFS install support on Live CD.
DESCRIPTION: The license conflict between the open source ZFS and open source Linux kernel mean ZFS needs to be in contrib. Unlike a lot of other packages in contrib, ZFS doesn't rely on any non-free software. It just can't be in Debian main because of the conflict of licenses.
However, it would be nice if there was a way to have a more official path to ZFS on root for Debian. The current instructions require a fairly high number of steps in the ZFS On Linux wiki.
The ZFS On Linux wiki also lists a new initramfs file that has to be included so ZFS is supported. It seems odd that Debian couldn't include that as part of initramfs. I realize Debian doesn't want to necessarily promote non-free software, but this is free software that just conflicts with the GPL. It doesn't seem like it should be a second class citizen where you have to manually include files that should already be part of the package.
By the nature of the license conflict, it will be a second class citizen in that it can't be part of the normal installation package and you'll have to compile on the fly. However, it would be nice if there was a mode in the Live CD that could handle ZFS installation rather than doing it all manually.
DISTRIBUTION: currently mixture of testing/unstable but I'd like to use day(s) old sid (see other post).
I would really like to see ZFS make it into the regular install image. Debian already releases an install image with non-free firmware and ZFS is free software. It just has an incompatible license.
The specific issue you mention about creating the initramfs file is actually not necessary in Stretch since this file already exists. There have been other, more significant changes in Stretch as well. (Note: I've contributed to the Debian Jessie ZFS on Root Howto and have followed this guide for numerous systems on both Jessie and Stretch).
1) ZFS has made it into Debian Stretch, so it is no longer necessary to add the backports repository. You just need contrib.
2) The grub-pc package in Stretch provides ZFS support. In contrast, Jessie required installing the package from Testing, and this could cause issues with prior versions of the Howto, as it would often pull Grub's dependencies from Testing as well, blocking installation of among other things, Gnome. The Howto now ensures that dependencies are satisfied from Stable.
3) Since ZFS and grub-pc can be installed from Stable, there's no need to add the /etc/apt/preferences file for pinning priority.
I promised a few people that I would do a fresh ZFS port to FUSE that could be merged into ZoL HEAD. While life has delayed that, I hope to make it a reality this year. It was intended to be a development aid, but I know that there are some internal politics in a few distributions about shipping out of tree kernel modules on install media. I am told that a FUSE port will alleviate the internal politics. I imagine Debian et al integration would improve once that is a reality. Conceptually, it should allow for users to make an easy switch to the kernel modules once the system is installed. Keep your eyes open for that later this year.
Thirded! I've been building out all my Debian boxes with ZFS root (and everywhere) for a year or more. Not only does this require installing via debootstrap, but there are some subtle things that have to be done just so or the system won't boot. Stretch improves this over Jessie, but it's still clearly not a first order citizen.
Like with non-free firmware, and other such things, I get the licensing and taint issues, but it would be good to see this evolve and be supported in the installer, someday, if only on a "forked" installer like with non-free firmware.
Decent support for ZFS in general, especially during installation already.
Ideally, ZFS root filesystem support (snapshot before upgrade, yay!).
I've been using ZFS for six(?) years now, on both Debian and Ubuntu, and while ZFS root is so important to me that I'm willing to jump through the necessary hoops to install it, it's kinda grating and perhaps riskier. And not for the faint of heart.
DESCRIPTION: I think I represent a number of users. We want to use unstable as a rolling distribution, but we don't want to run into every edge case. Testing doesn't update fast enough and doesn't have as good of security. There's no middle ground between absolute bleeding edge and the too conservative testing.
I used to use unstable but there's that annoying race condition where I could upgrade at the exact wrong time when brand new (broken) package versions were uploaded and not enough time has passed for even the first round of bugs. I'd like a day safety buffer so apt-listbugs has a chance to warn me about catastrophic bugs.
Setting up a true rolling distribution may be too much work for Debian. Actual Debian developers will be running unstable. It would be nice if there was a middle ground for non-Debian developers who want a rolling distribution but don't want to get hit by every edge case in sid.
I think a nice compromise would be to cache the sid packages for a day (or two) and set that up as another branch. A full day of possible bug reports from people on bleeding edge sid would give us a chance at missing the catastrophic edge cases while still being very current.
I think this could encourage more Debian developers. If I wanted to join Debian as a DD, I would need to have an unstable installation somewhere. It wouldn't be my daily driver because I don't want to run into those breaking edge cases. If my daily driver was day old sid, I could have another machine / VM that runs sid and would almost be identical to what my daily driver is running. It's not like testing where packages could be entirely different due to the delay in migrating.
Unlike testing, day old sid would migrate all packages even if there are release critical bugs. There would be no waiting period beyond the strict day limit. If there is a catastrophic edge case, people already on day old sid using apt-listbugs would be able to avoid it. New installations would hit it but you could warn users (see below).
If you make apt-listchanges and apt-listbugs as required packages for day old sid, then people could be informed about what broke on the previous day.
It would be nice to integrate apt-listbugs into an installer for day old sid and fetch the latest critical or high priority bugs before the installation. A new user could then decide if that's a good day to install. Or you could have a simple website that says here's the day old sid installer and these packages currently have critical or high priority bugs. If you would install those packages, maybe wait another day or two for it to settle down.
Maybe day old sid is too close. Perhaps 2 day sid or 3 day old sid? I don't feel that testing fills this role already because testing waits for 2-10 days and won't update if there are release critical bugs. I'm fine with something closer to bleeding edge sid, but I'd really like to allow a few days for the bleeding edge users to report bugs so I can decide whether to upgrade. I don't have an expectation that day(s) old sid is more stable than testing or less unstable than sid. All it provides is a buffer so I can get bug reports and make my decision about whether to upgrade.
>"Debian is available in three releases (stable, testing or unstable which can all be installed as a rolling release(by replacing the releases name(eg: stretch) with the code name(eg: testing)."
It's not really the same thing though. Packages in testing get migrated 2-10 days unless there's a serious bug report and then they get delayed indefinitely. Not all bug reports are going to affect me. I've run testing before and packages would get delayed on some bug that didn't affect me at all.
I ended up running a mixed testing/unstable just to pull in updated versions of programs from unstable that I wanted. However, that isn't a great situation either since now you can run into situations where you're using a configuration that few or no other people are running.
I think if there was simply a sid distribution that cached the packages for a day or two to allow for catastrophic bugs to get reported, I would have what I want. I'm fine with working around bugs in sid when the pop up. I just want a heads up from people following the absolute bleeding edge.
