grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 3/5] argon2: Import Argon2 from cryptsetup


From: Daniel Kiper
Subject: Re: [PATCH v3 3/5] argon2: Import Argon2 from cryptsetup
Date: Mon, 16 Mar 2020 21:03:24 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Mar 16, 2020 at 06:52:30PM +0100, Patrick Steinhardt wrote:
> On Mon, Mar 16, 2020 at 06:21:06PM +0100, Daniel Kiper wrote:
> > On Fri, Mar 13, 2020 at 02:13:49PM +0100, Daniel Kiper wrote:
> > > On Tue, Mar 10, 2020 at 07:58:30PM +0100, Patrick Steinhardt wrote:
> > > > In order to support the Argon2 key derival function for LUKS2, we
> > > > obviously need to implement Argon2. It doesn't make a lot of sense to
> > > > hand-code any crypto, which is why this commit instead imports Argon2
> > > > from the cryptsetup project. This commit thus imports the code from the
> > > > official reference implementation located at [1]. The code is licensed
> > > > under CC0 1.0 Universal/Apache 2.0. Given that both LGPLv2.1+ and Apache
> > > > 2.0 are compatible with GPLv3, it should be fine to import that code.
> > > >
> > > > The code is imported from commit 62358ba (Merge pull request #270 from
> > > > bitmark-property-system/master, 2019-05-20). To make it work for GRUB,
> > > > several adjustments were required that have beed documented in
> > > > "grub-dev.texi".
> > > >
> > > > [1]: https://github.com/P-H-C/phc-winner-argon2
> > > >
> > > > Signed-off-by: Patrick Steinhardt <address@hidden>
> > >
> > > [...]
> > >
> > > > diff --git a/grub-core/lib/argon2/argon2.c 
> > > > b/grub-core/lib/argon2/argon2.c
> > > > new file mode 100644
> > > > index 000000000..c77f7f6ff
> > > > --- /dev/null
> > > > +++ b/grub-core/lib/argon2/argon2.c
> > > > @@ -0,0 +1,232 @@
> > > > +/*
> > > > + * Argon2 reference source code package - reference C implementations
> > > > + *
> > > > + * Copyright 2015
> > > > + * Daniel Dinu, Dmitry Khovratovich, Jean-Philippe Aumasson, and 
> > > > Samuel Neves
> > > > + *
> > > > + * You may use this work under the terms of a Creative Commons CC0 1.0
> > > > + * License/Waiver or the Apache Public License 2.0, at your option. 
> > > > The terms of
> > > > + * these licenses can be found at:
> > > > + *
> > > > + * - CC0 1.0 Universal : 
> > > > http://creativecommons.org/publicdomain/zero/1.0
> > > > + * - Apache 2.0        : http://www.apache.org/licenses/LICENSE-2.0
> > > > + *
> > > > + * You should have received a copy of both of these licenses along 
> > > > with this
> > > > + * software. If not, they may be obtained at the above URLs.
> > > > + */
> > > > +
> > > > +#include <grub/dl.h>
> > > > +
> > > > +#include "argon2.h"
> > > > +#include "core.h"
> > > > +
> > > > +GRUB_MOD_LICENSE ("GPLv3");
> > >
> > > I think we should change that if the license above is different.
> > > Anyway, I am trying to get in touch with FSF license team. I have not
> > > got a reply yet... I will see what is possible in my company...
> >
> > Got an unofficial reply that we cannot remove current license from the
> > Argon2 reference source code package. However, we can add GPLv3 header
> > after current license header. Hence, I would suggest heading in that
> > direction. Still waiting for final confirmation.
>
> Thanks for handling this issue. So if I got that right, we can keep
> their header intact, add an additional header for GPLv3 and then we're
> fine with using `GRUB_MOD_LICENSE ("GPLv3")`? If so, then I'm happy to
> do that.

This is my understating too. Though I will be sure when I get a reply
from lawyers...

> > Sadly usual turn around is about two weeks...
>
> While I could still try to squeeze into v2.04, I think the most sensible

s/v2.04/v2.06/?

> way forward would be to defer Argon2 support to v2.06. There's still

s/v2.06/v2.08/?

> some open questions, and I'm not sure I feel comfortable with hitting
> master so close to the pending release. Let me know if you feel
> otherwise.

I have the same feeling. So, if it is not very critical for you to have
this in 2.06 I would suggest to deffer development until the release.
In the mean time I think we will be able to hammer out solutions for
your open questions.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]