Thanks to everyone who participated at this month's meeting. We discussed:
- ZoL 0.8.3 contents and schedule - checksum algorithm feature flags refcount bug - zfs change-key security implications - changing default encryption algorithm to GCM The recording is now available: https://www.youtube.com/watch?v=x9-wua_mzt0 Thanks Serapheim for taking notes: - When will 0.8.3 ship and will it include the large-dnode “zfs diff” fix (FireSnake) - Currently there is an outstanding patch PR for 0.8.3 (#9776) - it should be landing when we wrap up our testing so very soon (probably within this month!) - The goal is to have it pulled in for Ubuntu and Debian LTS - Let us know if there is a patch that you really want to see there - Changing the checksum algorithm at an existing dataset - even if no new blocks have been written - exporting and then importing that pool from a different version of ZFS hits an assertion error. [Allan Jude] - That was an oversight on the design of feature flags. - We should be able to handle this more gracefully. - A few ideas were thrown including: - Bump feature refcount for every dataset that has the property set - Being able to open the pool but not that dataset (property would show as “unsupported”) - Any further comments on this Ubuntu developer's proposal to enable encryption by default with a fixed passphrase: https://bugs.launchpad.net/bugs/1857398 (rlaager) - Is there any additional feedback that we haven’t already provided them? Feel free to add in the thread. - Tangent on secure-erase and changing encryption keys: - Secure erase and not having dataset’s being partially secure were two of the main motivators on the current encryption design. - The latter is ensured by setting encryption on at creation but not guaranteed as the encryption key may later be changed and will affect only new blocks. - Even if encryption key (user/wrapping key) is changed, new blocks can be read/manipulated if the old (compromised/public) key is known, and the old-key-wrapped master key is found (e.g. by forensic analysis of the disk). - The trade-off being usability and practicality varies wildly between cases. - Given the above tangent, we should really understand what the Canonical folks want to do and try to come up with the best practises and design. This includes communicating best practices, and potentially implementing something different than what we currently have. - We need to be more clear about the security implications of “zfs change-key” - PR filed <https://github.com/zfsonlinux/zfs/pull/9819> - Change encryption=on from aes-256-ccm to aes-256-gcm? See especially the comments starting here: https://github.com/zfsonlinux/zfs/pull/9749#issuecomment-568633557 (rlaager) - The two main motivators of this proposal are security and performance. - From a security standpoint, Mozilla and TLS default to gcm. - According to Richard’s estimates, performance could get a ~3x improvement with gcm. - There seems to be an overall consensus on this but we should really check with Tom Caputi. - encryption: from_ivset_guid check missing on resumed recv? <https://github.com/zfsonlinux/zfs/issues/9818>(Christian Schwarz) - turned into issue post-meeting, do not include in upcoming agenda - bookmark cloning & zcp bookmark support PR <https://github.com/zfsonlinux/zfs/pull/9571> (Christian Schwarz) - open design question: what about redaction bookmarks? <https://github.com/zfsonlinux/zfs/pull/9571/files#diff-4d2e1215100af304404ae6328e0bbc97R589> - reviewers needed once above question is resolved - outcome: - redaction object might be too large to copy it in syncing context, would have to be done in the background - => don’t implement redaction bookmark cloning at this point - => create thin bookmark: zfs bookmark #redactionbook #newbook - will not contain the redaction object itself On Mon, Jan 6, 2020 at 9:56 AM Matthew Ahrens <[email protected]> wrote: > The next OpenZFS Leadership meeting will be held tomorrow, January 7, > 9am-10am Pacific time. The agenda is pretty light this month, so if you > have any topics you'd like to discuss with the group, tomorrow will be a > good opportunity :-) > > Everyone is welcome to attend and participate, and we will try to keep the > meeting on agenda and on time. The meetings will be held online via Zoom, > and recorded and posted to the website and YouTube after the meeting. > > The agenda for the meeting will be a discussion of the projects listed in > the agenda doc. > > For more information and details on how to attend, as well as notes and > video from the previous meeting, please see the agenda document: > > > https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit > > --matt > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Td6ebc6df2e2a14bd-M0083049101bfc83d0fca4d37 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
