January OpenZFS Leadership Meeting

[Matthew Ahrens]

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 <mahrens at delphix.com> 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
>