From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 6B954385801B for ; Tue, 30 Nov 2021 11:25:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B954385801B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id EDB103048E28; Tue, 30 Nov 2021 12:25:43 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id BE15C425A442; Tue, 30 Nov 2021 12:25:41 +0100 (CET) Message-ID: <17e1d554c9a52598d2c7d27e7a40f17381285ba5.camel@klomp.org> Subject: Re: [PATCH v2] libebl: recognize FDO Packaging Metadata ELF note From: Mark Wielaard To: Luca Boccassi , elfutils-devel@sourceware.org Date: Tue, 30 Nov 2021 12:25:41 +0100 In-Reply-To: <40a5de54f089f344697ece88e11eb41e526462ac.camel@gmail.com> References: <20211119003127.466778-1-luca.boccassi@gmail.com> <20211121194318.105654-1-luca.boccassi@gmail.com> <40a5de54f089f344697ece88e11eb41e526462ac.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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 11:25:47 -0000 Hi Luca, 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/ */ > > +#define FDO_PACKAGING_METADATA 0xcafe1a7e > > + > > /* Note section name of program property. */ > > #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. 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. 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. 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). 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." 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. For Objects it should require that all names are unique. See section 4 in rfc8259. 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. 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). Cheers, Mark