All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Colin Walters <walters@verbum.org>
Cc: linux-fscrypt@vger.kernel.org
Subject: Re: new libfsverity release?
Date: Sun, 17 Jan 2021 09:56:53 -0800	[thread overview]
Message-ID: <YAR6ZUIpfLmwg5Bo@sol.localdomain> (raw)
In-Reply-To: <cc99418f-4171-4113-9689-afcf46695d95@www.fastmail.com>

On Sun, Jan 17, 2021 at 09:20:32AM -0500, Colin Walters wrote:
> There's been a good amount of changes since the last libfsverity release.  I'm primarily interested in
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git/commit/?id=f76d01b8ce8ce13538bac89afa8acfea9e2bdd57
> 
> I have some work in progress to update the ostree fsverity support to use it:
> https://github.com/ostreedev/ostree/pull/2269
> 
> Anything blocking a release?

Not really.

> 
> While I'm here, some feedback on the new library APIs:
> 
> - ostree is multi-threaded, and a process global error callback is problematic for that.  I think a GLib-style "GError" type which is really just a pair of error code and string is better.

It would be annoying for all library functions to dynamically allocate an
extended error structure on failure, because callers will forget to free it.  So
that's not a very good solution either.

Couldn't you allocate a per-thread variable (e.g. with pthread_setspecific())
that contains a pointer to your context or message buffer or whatever you need,
and use it from the error callback function?

Anyway, I can't change the API because it is stable now, and other people are
already using libfsverity.

> - Supporting passing the keys via file descriptor or byte array would be nice; or perhaps even better than that we should just expose the openssl types and allow passing pre-parsed key+certificate?

It sounds like you're interested in using the in-kernel signature verification
support.  Can you elaborate on why you want to use it (as opposed to e.g. doing
the signature verification in userspace), and what security properties you are
aiming to achieve with it, and how you would be achieving them?  Keep in mind
that userspace still needs to verify which files have fs-verity enabled.

- Eric

  reply	other threads:[~2021-01-17 17:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 14:20 new libfsverity release? Colin Walters
2021-01-17 17:56 ` Eric Biggers [this message]
2021-01-18 18:40   ` Colin Walters
2021-01-19 18:27     ` Eric Biggers
2021-01-17 15:56 Colin Walters

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=YAR6ZUIpfLmwg5Bo@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=walters@verbum.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.