From: Glenn Washburn <development@efficientek.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: grub-devel@gnu.org,
Denis GNUtoo Carikli <GNUtoo@cyberdimension.org>,
Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: [PATCH v3 0/9] Cryptodisk fixes for v2.06
Date: Mon, 21 Sep 2020 04:54:26 +0000 (UTC) [thread overview]
Message-ID: <22ad8064-9aef-43ee-8a17-b1f37a4dad2a@efficientek.com> (raw)
Sep 17, 2020 8:14:40 AM Patrick Steinhardt <ps@pks.im>:
> On Mon, Sep 07, 2020 at 05:27:27PM +0200, Patrick Steinhardt wrote:
>> this is the third version of this patchset, collecting various fixes for
>> LUKS2/cryptodisk for the upcoming release of GRUB v2.06.
>>
>> Besides my Reviewed-by tag, the only thing that changed is the final
>> patch by Glenn. Quoting him:
>>
>>> The main difference with this patch is that sector_size is renamed to
>>> log_sector_size, grub has enough inaccurate or misleading names.
>>> Additionally, rename LOG_SECTOR_SIZE to LUKS_LOG_SECTOR_SIZE and
>>> CRYPT_LOG_SECTOR_SIZE to GRUB_CRYPTODISK_IV_LOG_SIZE and moved to
>>> cryptodisk.h. Also a comment was reworded for clarity.
>
> A subset of these patches has been applied by Daniel, leaving us at
> (rearranged for better readability):
>
>> Glenn Washburn (6):
>> cryptodisk: Fix incorrect calculation of start sector
>> cryptodisk: Unregister cryptomount command when removing module
>
> Both were picked.
>
>> luks2: Fix use of incorrect index and some error messages
>> luks2: grub_cryptodisk_t->total_length is the max number of device
>> native sectors
>> cryptodisk: Fix cipher IV mode 'plain64' always being set as 'plain'
>> cryptodisk: Properly handle non-512 byte sized sectors
>
> These weren't yet and got some feedback.
>
>> Patrick Steinhardt (3):
>> json: Remove invalid typedef redefinition
>> luks: Fix out-of-bounds copy of UUID
>> luks2: Improve error reporting when decrypting/verifying key
>
> All three of these have been applied.
>
> @Glenn: seeing that all of my patches have been applied, do you want to
> take over your remaining four patches again? That'd probably make the
> process easier for both of us.
Sure, I can do that. I've been traveling for the last several weeks with little connectivity and limited time, which is why I haven't been active in addressing the responses on this thread. Thanks for helping move this forward
next reply other threads:[~2020-09-21 4:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 4:54 Glenn Washburn [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-08-23 10:59 [PATCH 0/9] Cryptodisk fixes for v2.06 Patrick Steinhardt
2020-09-07 15:27 ` [PATCH v3 " Patrick Steinhardt
2020-09-09 11:28 ` Daniel Kiper
2020-09-17 14:14 ` Patrick Steinhardt
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=22ad8064-9aef-43ee-8a17-b1f37a4dad2a@efficientek.com \
--to=development@efficientek.com \
--cc=GNUtoo@cyberdimension.org \
--cc=daniel.kiper@oracle.com \
--cc=grub-devel@gnu.org \
--cc=ps@pks.im \
/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.