On Tue, 20 Jun 2023 at 04:18, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Tue, Jun 20, 2023 at 01:42:20AM +0100, Luca Boccassi wrote: > > On Tue, 20 Jun 2023 at 00:49, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > > > On Tue, Jun 20, 2023 at 12:04:39AM +0100, Luca Boccassi wrote: > > > > > diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst > > > > > index ede672dedf110..c33f783e74953 100644 > > > > > --- a/Documentation/filesystems/fsverity.rst > > > > > +++ b/Documentation/filesystems/fsverity.rst > > > > <...> > > > > > +- Trusted userspace code. Often, the userspace code that accesses > > > > > + files can be trusted to authenticate them. Consider e.g. an > > > > > + application that wants to authenticate data files before using them, > > > > > + or an application loader that is part of the operating system (which > > > > > + is already authenticated in a different way, such as by being loaded > > > > > + from a read-only partition that uses dm-verity) and that wants to > > > > > + authenticate applications before loading them. In these cases, this > > > > > + trusted userspace code can authenticate a file's contents by > > > > > + retrieving its fs-verity digest using `FS_IOC_ENABLE_VERITY`_, then > > > > > + verifying a signature of it using any userspace cryptographic > > > > > + library that supports digital signatures. Consider using `libsodium > > > > > + <https://libsodium.gitbook.io/doc/public-key_cryptography/public-key_signatures>`_ > > > > > + or `Tink <https://developers.google.com/tink/digitally-sign-data>`_. > > > > > + Other options include OpenSSL, JCA, and libgcrypt. > > > > > > > > Text looks good to me now, but please just drop the last sentence with > > > > the external projects links, as it seems best left as an exercise for > > > > the reader to find their preferred tooling that is appropriate to be > > > > used at the time of reading, as this will get out of date fast. > > > > > > > > <...> > > > > > > Well, a significant part of the motivation for this patch is that the "exercise > > > for the reader" approach has already been tried, for several years, but it is > > > not working well. People don't know what to use and need a little more help. > > > > > > I'm planning to add some example code to fsverity-utils, probably using > > > libsodium. After that, I'll make this documentation link to there. But for > > > now, I think the last two sentences of the above paragraph are helpful. > > > > That list does not help, quite the opposite - libsodium seems all but > > abandoned (last release 5 years ago, an unmaintained project is not > > exactly what you want for your crypto primitives) > > libsodium has an active maintainer. Last commit was 3 months ago. > > Also note that simple crypto libraries that focus on offering modern > cryptographic algorithms don't need to be updated often. You actually *don't* > really want to have to constantly update your crypto library because they e.g. > messed up their ASN.1 parser. If there is no ASN.1, that cannot happen. Maintenance is not only CVE-driven, no release for almost 5 years in a security-critical component to me looks like a red flag. And I maintain projects using libsodium (zeromq), so it's not like I've never seen it before. But when a package is shipped bit-by-bit identical across two different Debian releases it's usually not a sign of good health for the project. > > tink appears to > > be one of those google's sources-available-proprietary projects, which > > means that, as with everything else that google throws over the wall, > > it's at permanent risk of getting killed with little notice, among > > many other problems. > > Tink is an open source project licensed under the Apache license. Non-Google > contributions to Tink are being accepted on GitHub. If Google stops maintaining > Tink, it can be forked, like any other open source project. The website that was linked said a CLA was required. On top of that, I can't speak for this one in particular, but my experience with other google projects that were allegedly open source has been atrocious - the 'real' source tree being proprietary and private, with code occasionally synced to Github, and external contributors requiring an internal corporate 'sponsor' to get their changes merged internally first, passing invisible, private CI and getting reverted without much consideration when some more important, internal change conflicted, and with no way to find out till the internal real tree was thrown over the wall again at some point in the future. All of this while claiming it was just a normal open source project on Github. That's not open source, that's proprietary with sources-available. > Anyway, my intent was simply to list some modern crypto libraries. One of them > just happens to be from Google. I'm sorry if it may have appeared like I listed > a Google project because of it being from Google. That was not my intent. > > > If you really want to suggest something, OpenSSL > > seems like an appropriate choice of a widely available, supported and > > well-known solution that is the most likely to still be around and > > maintained in 5/10 years. > > Sure. Which is why I included OpenSSL in the list. > > Anyway, I'll go ahead and take your suggestion to omit the mentions of any > specific crypto libraries. I do agree that it could use some more thought, and > the main place for this information will be in fsverity-utils which will have > the example code. Thank you. It seems best to keep such recommendations, if any, together with the example code, yes.
