Re: State of Argon2 support

[Daniel Kiper]

On Fri, Jan 26, 2024 at 10:55:21AM +0100, Patrick Steinhardt wrote:
> On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou wrote:
> > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper <dkiper@net-space.pl> wrote:
> > >
> > > Adding Vladimir who knows GRUB history better than I...
> > >
> > > On Wed, Jan 24, 2024 at 01:23:55AM -0500, Nikolaos Chatzikonstantinou 
> > > wrote:
> > >
> > > [...]
> > >
> > > > My apologies for the repeated messages, but I came up with just one
> > > > more question that I'm curious about. To summarize my questions:
> > > >
> > > > 1. Where is the libgcrypt bundle from grub from? I think my
> > > > investigation has led me around version 1.7.0 of libgcrypt, but if I
> > > > can get a precise commit or version, that would be useful.
> > > >
> > > > ... and now to my new question:
> > >
> > > Vladimir, could you help with that?
> > >
> > > > 2. What is the reason libgcrypt is bundled as opposed to a regular 
> > > > dependency?
> > >
> > > I am not entirely sure I understand the question. Could you elaborate?
> >
> > By bundling, I mean that someone copied libgcrypt files into the GRUB 
> > project.
> >
> > To elaborate further, regular programs (not like GRUB which is a
> > bootloader) can link statically or dynamically to libraries; but also,
> > there's a third option, to dump the source code of a library directly
> > into the source tree of the project. To my understanding this third
> > option (which is not really a third linker option as it is not related
> > to the linker) is chosen when the project needs to include its own
> > patch set to the library. I am curious if GRUB has patched libgcrypt
> > for some reason, and is that why libgcrypt is bundled with GRUB?
>
> Yeah, the libgcrypt version carried by GRUB is heavily patched so that
> it compiles within the non-libc environment that GRUB uses. That is the
> whole crux of this topic -- if libgcrypt was simply a vanilla version
> then it shouldn't be all that hard to update.
>
> I think in the long term it would be great indeed if we could refrain
> from patching libgcrypt to the widest extent possible so that future
> updates become easier. I guess that would require something of a "shim"
> header that makes available all of the prerequisites that are currently
> missing for libgcrypt to compile.

I concur! However, it would be nice to have simple mechanism which allow
us to disable unused features. I am not sure it will be possible without
patching libgcrypt heavily.

Daniel