From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 2ADD13858402 for ; Tue, 30 Nov 2021 12:37:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2ADD13858402 Received: by mail-ed1-x536.google.com with SMTP id t5so86458363edd.0 for ; Tue, 30 Nov 2021 04:37:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=xAwwmBV12WG77Y8nTuPbA4Eh7xGlGoHZFCvulQtyoDs=; b=3c27u0gMtDheoijyJi9lrNJ2r9Xe9l0mRAusKmflofz7CFXWXQBFtinjDNWwS61wG1 Qr6FPKEeUzjuynTV82JLDbT90D35FKzUpQhyxZFe25C6Rx/a9j7qG063LAdbmSBUft3v GMwJfbF9R1HgbYovZG77mOheDy19tFxSebhAGIIxeV3tIY5eAzYdTWrgdf+q2DlLH9R5 DoeYkca6mup1uCNm2/1lRTZnjH/+IqP/MzMTCKInUvQYmKDx2hZR0mgC4NP0WweFxsbU stQu8nwwLoC747TxHhIYZbmPof6ay6c9BslQFOmPvAD6SUZ3l3U2xQs+5RqWAIyAfy+1 bi6w== X-Gm-Message-State: AOAM5322lYs7OBA7mYAoiqBIoSxi9U7wg7syuCKKOVEgJnbkZXoR8VMy g/MSoSUBLbiD7E/nIt21IH2VedyzaZ8= X-Google-Smtp-Source: ABdhPJwp+Ek1so2psu41uWtu/vB0o4HJPntLfHLQJNHbwscT7/Azza2Nm/QkoxgHFtpplEbj+02Ikw== X-Received: by 2002:a05:6402:440b:: with SMTP id y11mr84019426eda.25.1638275871214; Tue, 30 Nov 2021 04:37:51 -0800 (PST) Received: from ?IPv6:2a01:4b00:f41a:3600:df86:cebc:8870:2184? ([2a01:4b00:f41a:3600:df86:cebc:8870:2184]) by smtp.googlemail.com with ESMTPSA id cw5sm9851657ejc.74.2021.11.30.04.37.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 04:37:50 -0800 (PST) Message-ID: Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note From: Luca Boccassi To: Mark Wielaard , elfutils-devel@sourceware.org Date: Tue, 30 Nov 2021 12:37:49 +0000 In-Reply-To: <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> References: <20211119003127.466778-1-luca.boccassi@gmail.com> <20211121194318.105654-1-luca.boccassi@gmail.com> <40a5de54f089f344697ece88e11eb41e526462ac.camel@gmail.com> <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-cVU3E9tSKHXYQdLv4y4q" User-Agent: Evolution 3.42.1-1 MIME-Version: 1.0 X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 12:37:54 -0000 --=-cVU3E9tSKHXYQdLv4y4q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2021-11-30 at 12:25 +0100, Mark Wielaard wrote: > Hi Luca, >=20 > On Thu, 2021-11-25 at 17:02 +0000, Luca Boccassi via Elfutils-devel > wrote: > > +/* Packaging metadata as defined on=20 > > > https://systemd.io/COREDUMP_PACKAGE_METADATA/=C2=A0*/ > > > +#define FDO_PACKAGING_METADATA 0xcafe1a7e > > > + > > > =C2=A0/* Note section name of program property.=C2=A0=C2=A0 */ > > > =C2=A0#define NOTE_GNU_PROPERTY_SECTION_NAME ".note.gnu.property" > >=20 > > I could move this definition to an internal header if the change to > > elf.h blocks this patch, if you prefer? Let me know. >=20 > It looks like it will be integrated into glibc elf.h later this week. > I'll resync elf.h then and apply the other half of your patch. >=20 > While looking at how to implement the json parsing of the note data I > noticed a couple of things that could be clarified in the spec to make > this more clear and less ambiguous. >=20 > The spec says "a key-value JSON format", "JSON payload" and "a JSON > string with the structure described below". Which isn't very exact, or > seems to describe multiple different JSON concepts which aren't exactly > the same thing. A JSON string is something different from a JSON object > (which is the only JSON value that has a key-value format). And it > doesn't really make clear what the encoding of the JSON itself is (it > cannot be a JSON string, because that itself is expressed in an > specific character encoding itself). >=20 > What I think the spec should say is something like: > "The note data is a single JSON object encoded as a zero terminated > UTF-8 string." >=20 > The spec does explain the requirements for JSON numbers, but doesn't > mention any for JSON strings or JSON objects. It would be good to also > explain how to make the strings and objects unambiguous. >=20 > For Objects it should require that all names are unique. See section 4 > in rfc8259. >=20 > For Strings it should require that \uXXXX escaping isn't used and that > only control characters that have an explicit escape sequence are used > (\b, \n, \f, \r, \t) [if you allow them in the first place, they are > probably confusing and it may be good to simply say that Strings should > not contain any control characters or use \uXXXX escaping]. See section > 7 and section 8 in rfc8259. >=20 > That should get rid of various corner cases that different parsers are > known to get wrong. Especially \uXXXX escaping is really confusing when > using the UTF-8 encoding (and it is totally necessary since UTF-8 can > express any valid UTF character already). >=20 > Cheers, >=20 > Mark Thanks, see: https://github.com/systemd/systemd/pull/21578 --=20 Kind regards, Luca Boccassi --=-cVU3E9tSKHXYQdLv4y4q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEE6g0RLAGYhL9yp9G8SylmgFB4UWIFAmGmGx0ACgkQSylmgFB4 UWJ0Hgf/SYAYSQTZ4FzTxkI/hi1Wxgk2QoA2lVjt/jiHeLRo6H6jJ2rAxUoFhFRs n0Rhd1w/vr4kXceP/LlFl2UGzzgno3+zm/IjpUzcYyhaooCJaTcfIn/w36jeL5Bv iIbRtTOZ1tBEk4Ck7EtXnil4V3KGOubZDM6ctZZFCiNIo0mbJ/DlJn4csHR/6HFY yRNUT7Dtt/uLhZx0KPEMoaOzSgwsZWLDrpdbciDPZz/5RVxMTQ9qP7p20fAOhxKW P/kmZtsuQ5UrXontSU1tuDXPDSChbdO0xjIqjpIO181eNLS2Vk2TZbMDblOe2qYN zBFsjmsfPLDDC/6NVetPYSdOk97/0A== =PTkr -----END PGP SIGNATURE----- --=-cVU3E9tSKHXYQdLv4y4q--