All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: linux-fscrypt@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
	Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH] fscrypt: align Base64 encoding with RFC 4648 base64url
Date: Sun, 25 Jul 2021 20:59:05 -0700	[thread overview]
Message-ID: <YP4zCXWV2N1Ys+lh@sol.localdomain> (raw)
In-Reply-To: <20210718000125.59701-1-ebiggers@kernel.org>

On Sat, Jul 17, 2021 at 07:01:25PM -0500, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> fscrypt uses a Base64 encoding to encode no-key filenames (the filenames
> that are presented to userspace when a directory is listed without its
> encryption key).  There are many variants of Base64, but the most common
> ones are specified by RFC 4648.  fscrypt can't use the regular RFC 4648
> "base64" variant because "base64" uses the '/' character, which isn't
> allowed in filenames.  However, RFC 4648 also specifies a "base64url"
> variant for use in URLs and filenames.  "base64url" is less common than
> "base64", but it's still implemented in many programming libraries.
> 
> Unfortunately, what fscrypt actually uses is a custom Base64 variant
> that differs from "base64url" in several ways:
> 
> - The binary data is divided into 6-bit chunks differently.
> 
> - Values 62 and 63 are encoded with '+' and ',' instead of '-' and '_'.
> 
> - '='-padding isn't used.  This isn't a problem per se, as the padding
>   isn't technically necessary, and RFC 4648 doesn't strictly require it.
>   But it needs to be properly documented.
> 
> There have been two attempts to copy the fscrypt Base64 code into lib/
> (https://lkml.kernel.org/r/20200821182813.52570-6-jlayton@kernel.org and
> https://lkml.kernel.org/r/20210716110428.9727-5-hare@suse.de), and both
> have been caught up by the fscrypt Base64 variant being nonstandard and
> not properly documented.  Also, the planned use of the fscrypt Base64
> code in the CephFS storage back-end will prevent it from being changed
> later (whereas currently it can still be changed), so we need to choose
> an encoding that we're happy with before it's too late.
> 
> Therefore, switch the fscrypt Base64 variant to base64url, in order to
> align more closely with RFC 4648 and other implementations and uses of
> Base64.  However, I opted not to implement '='-padding, as '='-padding
> adds complexity, is unnecessary, and isn't required by the RFC.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  Documentation/filesystems/fscrypt.rst |  10 +--
>  fs/crypto/fname.c                     | 106 ++++++++++++++++----------
>  2 files changed, 70 insertions(+), 46 deletions(-)

Applied to fscrypt.git#master for 5.15.

- Eric

      parent reply	other threads:[~2021-07-26  3:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-18  0:01 [PATCH] fscrypt: align Base64 encoding with RFC 4648 base64url Eric Biggers
2021-07-19  6:00 ` Hannes Reinecke
2021-07-23  8:16 ` Eric Biggers
2021-07-23 18:01   ` Jeff Layton
2021-07-26  3:59 ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YP4zCXWV2N1Ys+lh@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=hare@suse.de \
    --cc=jlayton@kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.