Hi Cyril, On Mon, 18 Dec 2017 at 01:39:35 +0100, Cyril Brulebois wrote: > Guilhem Moulin <guil...@debian.org> (2017-12-18): >> On Sun, 17 Dec 2017 at 18:12:21 +0100, Cyril Brulebois wrote: >>> I've added this as a todo item, along with looking into src:argon2 >>> and src:json-c. I'll try to look into that next week (ping welcome), >>> but we'll need to get those packages past NEW; it would be >>> appreciated to only start the cryptsetup transition once >>> dependencies can be satisfied, to avoid breaking d-i daily builds >>> purposefully. >> >> Ack. I see mejo has just requested the transition slot in #884618, >> that means we should we block that bug by #88052[56], right? > > That would look good yes.
Done. >> Not sure what's upstream's intention regarding making `cryptsetup >> luksFormat` create LUKS2 devices by default, but at this stage it seems >> precipitated to switch to LUKS2 in d-i: I'd rather stick to upstream's >> default, especially considering the following snippets of their v2.0.0 >> Release Notes: >> >> “Please note that […] the LUKS2 on-disk format itself are new >> features and can contain some bugs.” >> — >> https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/v2.0.0-ReleaseNotes#L15 >> >> (And FWIW it's possible to later in-place convert a device from LUKS1 to >> LUKS2 format using `cryptsetup convert`, although it of course won't >> magically upgrade the crypto & PKDF algorithms.) > > Alright; feel free to poke us again for partman-crypto when the new > format looks mature enough so that we see about adding support for it. Will do :-) >>> Alternatively, instead of waiting for udebs to be available for the >>> dependencies, maybe support for those two libraries could be patched >>> out temporarily in the cryptsetup udebs? >> >> For libargon2-0 it should be a matter of changing the default PBKDF >> back to pbkdf2, but I don't see a way to drop the libjson-c3 >> dependency unless we compile cryptsetup without LUKS2 support (LUKS2 >> headers contain metadata stored in JSON format [1]), which is not >> trivial AFAICT. > > Alright, thanks for your input, that's going to guide my looking into > these packages during the week; I'll investigate as soon as I'm done > with urgent matters. Awesome, thanks! -- Guilhem.
signature.asc
Description: PGP signature
