From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kmWeB-0002zj-5e for mharc-grub-devel@gnu.org; Tue, 08 Dec 2020 01:38:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmWe8-0002yN-QG for grub-devel@gnu.org; Tue, 08 Dec 2020 01:38:49 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:54085) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmWe0-00079p-7H for grub-devel@gnu.org; Tue, 08 Dec 2020 01:38:48 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C54F0E08; Tue, 8 Dec 2020 01:38:36 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 08 Dec 2020 01:38:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pks.im; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=POo4xGQuSIeeKiHIcwOtb8AR59s QURr9EiRWCgMi6Kg=; b=j8AoydD+YTqpA7z3q3g82/Lti5K0YFX0y2Zc8tLqZ3Z Wl7nMYSA8hjcrwcL1uFqKceDs+kF9miD9QYz805Y1dkNMwIfhziSVRSn1fCKm4YI V+JDvMUBUbIHTO6BXn4Le37u14VrNiY22e1k1+uj1ZxvFlSo/kjkX0O+5XTXNoXp UxkLrfEiRhNnJCotn+xmuMMmgdGgzmXxV27gB8Q/z4RBeer3p3Y6RtV4tGwurUki BboGkreq/hn9MZ7/aQV5ZP+Ardr32sKr/Xzc3R25eWzLUlZpJQUE5qU3PX/32wZe 0/ejlTXdISbpaPC+tVGPlr5OeXIgTnqVlb52o82Bo+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=POo4xG QuSIeeKiHIcwOtb8AR59sQURr9EiRWCgMi6Kg=; b=Nq9STxaDbzGJ2akJYb0Uxb 0ftiMmq8BG6aES5M8Zc3U0uzXFc5vfVy2f000atwcMN1haBGkW2obMkvLuJBuMjt jQTvhtQsmpflJsyU0OT/J6+jYKJcT0VW3rknTpHvDMHLTA36a3hS+6Pkf4C5zrRz MaomcpxYIAovCCpdM/I/EvG0R1rT0fjGaJDqOuCT2vmwMK1/roZxOJiH8zxRm88F 24CbBoWN795XIpz4s7d7ej1ZkjElomcxPgG4a8KMVLFSva9Evmd4z/2nFDZy1eYS 6NFUez9YUEE+30Odi5o1JQXICMcSVmHfHfu/ujky4D9OOhd4dSVKxBVoNws0N+jg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejhedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefrrghtrhhi tghkucfuthgvihhnhhgrrhguthcuoehpshesphhkshdrihhmqeenucggtffrrghtthgvrh hnpeehgfejueevjeetudehgffffeffvdejfeejiedvkeffgfekuefgheevteeufeelkeen ucfkphepjeejrdduledurdeguddrudehieenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehpshesphhkshdrihhm X-ME-Proxy: Received: from vm-mail (x4dbf299c.dyn.telefonica.de [77.191.41.156]) by mail.messagingengine.com (Postfix) with ESMTPA id F396F24005A; Tue, 8 Dec 2020 01:38:34 -0500 (EST) Received: from localhost (ncase [10.192.0.11]) by vm-mail (OpenSMTPD) with ESMTPSA id 368573f1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 8 Dec 2020 06:38:33 +0000 (UTC) Date: Tue, 8 Dec 2020 07:38:31 +0100 From: Patrick Steinhardt To: Glenn Washburn Cc: Daniel Kiper , grub-devel@gnu.org Subject: Re: [PATCH v7 05/17] luks2: Add json_slot_key member to struct grub_luks2_keyslot/segment/digest Message-ID: References: <35f47644cdc76e65a5d51a625c4a790fc10b437c.1607098915.git.development@efficientek.com> <20201207200239.dbxxfgaed74tiguc@tomti.i.net-space.pl> <20201207220644.49eebe57@crass-HP-ZBook-15-G2> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gim+8/RNS4Z6jjG+" Content-Disposition: inline In-Reply-To: <20201207220644.49eebe57@crass-HP-ZBook-15-G2> Received-SPF: pass client-ip=64.147.123.19; envelope-from=ps@pks.im; helo=wout3-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 06:38:49 -0000 --Gim+8/RNS4Z6jjG+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2020 at 10:06:44PM -0600, Glenn Washburn wrote: > On Mon, 7 Dec 2020 21:02:39 +0100 > Daniel Kiper wrote: >=20 > > On Sun, Dec 06, 2020 at 02:29:06PM +0100, Patrick Steinhardt wrote: > > > On Fri, Dec 04, 2020 at 10:43:34AM -0600, Glenn Washburn wrote: > > > > This allows code using these structs to know the named key > > > > associated with these json data structures. In the future we can > > > > use these to provide better error messages to the user. > > > > > > > > Get rid of idx variable in luks2_get_keyslot() which was > > > > overloaded to be used for both keyslot and segment slot keys. > > > > > > > > Signed-off-by: Glenn Washburn > > > > > > Personally, I'd have named them `json_slot_idx`. But you've already > > > done so much work on improving the code that I don't want this to > > > be the reason to not give an SOB, especially considering that it's > > > a strict improvement anyway. So: > > > > > > Signed-off-by: Patrick Steinhardt > >=20 > > I can change this to json_slot_idx before committing if Glenn does not > > object. Otherwise Reviewed-by: Daniel Kiper >=20 > Thanks Patrick for the sentiment. Looking at the luks2 spec, it says: >=20 > "JSON objects must have their names formatted as a string that > represents a number in the decimal notation (unsigned integer) =E2= =80=93 > for example =E2=80=9D0=E2=80=9D, =E2=80=9D1=E2=80=9D and must contain att= ribute _type_. According to > the _type_, the implementation decides how to handle (or > ignore) such an object. This notation allows mapping to LUKS1 API > functions that use an integer as a reference to keyslots objects." >=20 > So here, the spec is calling that value a "name", and saying that it > must be a string of decimal digits. Looking at the spec, the "name" of > the keyslot object does not need to correspond to the index into the > array of keyslot areas on disk. However it does in the canonical > implementation for use with LUKS1 API functions which require and > integer, as suggested in the quote above. >=20 > I'd say that these numbers are actually an id for the object of its > respective class. In the cryptsetup implementation, the "id" happens > to correspond to the index into the binary key area array, but that's > needn't be the case. My preference would be to name it "id" and second > choice would be just "idx" (since its usually an index into a physical > array of key areas or virtual array of segments and digests). >=20 > I don't think the "json" part of the name is warranted, because it > really has nothing to do with json. The "slot" part is really only > applicable to keyslots because digests and segments don't have an > equivalent slot aspect. So I suggest we name the struct member names > to just "id" instead. And where we just the index of the name-value > pair in the json associative array we use "json_idx" as a suffix. So > this would mean changing the argument keyslot_idx in > luks2_get_keyslot() to keyslot_json_idx. Optionally the local variable > "i" in luks2_get_keyslot() and luks2_parse_segment() could be renamed > to "json_idx" as well (I don't care either way about this though). >=20 > Glenn Sounds sensible to me. Based on your reasoning, I'm happy with either "id" or "key". So we may just as well just keep it as-is, as you prefer. Patrick --Gim+8/RNS4Z6jjG+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEF9hrgiFbCdvenl/rVbJhu7ckPpQFAl/PH2YACgkQVbJhu7ck PpTmqQ/9FbsaS5qo0Zx2jGUYNSlDrUnLRs1HZfkH0wWj/ejavV3ynTaQTm7yFg0w y6ckzVyjw/h1otcIi/DlcwKPozrx7qDYo2yFazvVYyh0fHJ/HrOeGgShjk+k9k+A 0gwZEXuiW81rH08as06etLBwA1z/rw+UMwlmWCNxGLLuI/9sUZPp289lr4rIOAAv XGlbOq4wcdqmZmPF5rJ3Y0hUZMzoiwX432f3bfceczmSEfQiZBTOHuget9MR4zIj PzvRHxa6QtgxjElxoOXw9MmLlxggT87A6Xv9hBxXGp6GJ223nf3vo50i7Z09REiw 07WXyhlpMJMWqaDWmzf6zdvyX6SEfKbI21Y5XtI2Y+wQFgh/WoyFMw2q+g+vJM5W 0J3K2xUgJh0WQ0GaXq+9iTRXFKKW3vETSjtfSYFWTExuDHqg6RU/QYY01m99hbIN 6w2Wrwj16GYdAmdsxMTqoaokvk+bBLMs05bPQkzq1J3JIuoNEUyhz7B9tbXALKD3 ZWx0UwIcTpgbJdhSkNcvJ3lUo6mKIzc8hTjFiidMJ+sbb3txGvJlNoMyxU0k+xu4 iaH/WdifRFZMXN8SBALGsPXu0JvAtZC5UH0Ypx+LSMH6mz1W9+Gheb0LkQ46nbRW /gnKCS7E0wjv8WccxKt5wrTFc4Y/g3vKTc5AMEX48Rzt+ElVMec= =2RE5 -----END PGP SIGNATURE----- --Gim+8/RNS4Z6jjG+--