From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 3A66AA0032;
	Fri, 24 Jun 2022 17:06:13 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id D202B40A89;
	Fri, 24 Jun 2022 17:06:12 +0200 (CEST)
Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com
 [209.85.214.172])
 by mails.dpdk.org (Postfix) with ESMTP id 60C3E400EF
 for <dev@dpdk.org>; Fri, 24 Jun 2022 17:06:11 +0200 (CEST)
Received: by mail-pl1-f172.google.com with SMTP id c4so2351213plc.8
 for <dev@dpdk.org>; Fri, 24 Jun 2022 08:06:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=QAJg8sTTfJq/FcrUzmrKsXtEa6rCUJeVWPxDTI0X3GI=;
 b=WeeypEceLQKTvQprvFjc7+MLfQF9H4aqp/t96LQ2Z3NOhK8ZSwVo/bQCsSF5zptQ/t
 0m1N7kGVb/5yIQQwKuX1E+0HyOBGiJ2dlstOOo9sqEKH/+3aVX+vGSW8jnFQft9Iu5xm
 Fm9HvxyBVJ0KOHCgP2IxlFxm9izQMGpa1RuzmrHW1dS1VVhQvduakafYlkXnhk4RT+H1
 IHfSWGLAViNbnT1QAytYCC5shkdlqDOYKscQjjnxm8u9rfsXsdjMnnMcj3vk3/4r5x8G
 szXvvNGWRhGHvhY1kZDyAnHZz0BNz4bCwsD/muN2rZEXdGXxYsddl14iaFP5k+bawSHS
 koug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=QAJg8sTTfJq/FcrUzmrKsXtEa6rCUJeVWPxDTI0X3GI=;
 b=ZPaGznX/cIdAFAL91HFdoLBdHbQSiZtp41xhBILegDg0+Ec+qflInvZTEZyvsrGksM
 HGaQ477jx7IvN/wqjHNS4POOGmv2MudOreGAlUqWDWD0vEForkM5aiIbLUAPd7eT9lho
 HYSAdlstm1+Ew/DuhLgq5QYf3c9Fc9yFEnM7aCj/loYWLGiTQaMN+rTsesymkq87F8w4
 kvcSSd4ZUNGWp48tp+Js2+Vk3Q9D0gG9chwFq0K1u2duCM0H6rsatktZZwyR1uOR8iXu
 Uiad0g5gvKAbXcaEzMYlGD8EtUT5y4IlHucxwWYtvlawl8EjfDdtkvAHsPTyav2i5ELq
 o9rA==
X-Gm-Message-State: AJIora+yRil3juoU+oM5lNRg1ZTB4d4JLLJUck7DX+ws/szkuf6Bcg4N
 lTUvX4aJXBMHFa3bmcfT+fvHNw==
X-Google-Smtp-Source: AGRyM1vlSp+3dzd7Ts5dXSmYd/JhFz6T9K3CYOTWWv5QZkQTVBI+i4lOEP6vgCYXtz3jTmXSeIC3Cg==
X-Received: by 2002:a17:902:f787:b0:16a:1e2b:e97 with SMTP id
 q7-20020a170902f78700b0016a1e2b0e97mr28660511pln.27.1656083170348; 
 Fri, 24 Jun 2022 08:06:10 -0700 (PDT)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
 by smtp.gmail.com with ESMTPSA id
 h27-20020aa79f5b000000b0051c79bd5047sm1848328pfr.139.2022.06.24.08.06.09
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 24 Jun 2022 08:06:09 -0700 (PDT)
Date: Fri, 24 Jun 2022 08:06:06 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com>
Cc: "Bruce Richardson" <bruce.richardson@intel.com>, <dev@dpdk.org>,
 <ciara.power@intel.com>, <fengchengwen@huawei.com>
Subject: Re: [RFC PATCH 2/6] telemetry: fix escaping of invalid json characters
Message-ID: <20220624080606.66ca25dd@hermes.local>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87174@smartserver.smartshare.dk>
References: <20220623164245.561371-1-bruce.richardson@intel.com>
 <20220623164245.561371-3-bruce.richardson@intel.com>
 <98CBD80474FA8B44BF855DF32C47DC35D8716B@smartserver.smartshare.dk>
 <20220623113934.372b059e@hermes.local>
 <98CBD80474FA8B44BF855DF32C47DC35D8716C@smartserver.smartshare.dk>
 <YrVvJpDMGpCxu8J6@bricha3-MOBL.ger.corp.intel.com>
 <YrWdGYgO1GJU+0yl@bricha3-MOBL.ger.corp.intel.com>
 <98CBD80474FA8B44BF855DF32C47DC35D87174@smartserver.smartshare.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Fri, 24 Jun 2022 13:29:46 +0200
Morten Br=C3=B8rup <mb@smartsharesystems.com> wrote:

> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Friday, 24 June 2022 13.17
> >=20
> > On Fri, Jun 24, 2022 at 09:00:38AM +0100, Bruce Richardson wrote: =20
> > > On Thu, Jun 23, 2022 at 08:48:21PM +0200, Morten Br=C3=B8rup wrote: =
=20
> > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > > Sent: Thursday, 23 June 2022 20.40
> > > > >
> > > > > On Thu, 23 Jun 2022 20:34:07 +0200
> > > > > Morten Br=C3=B8rup <mb@smartsharesystems.com> wrote:
> > > > > =20
> > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > > > Sent: Thursday, 23 June 2022 18.43
> > > > > > >
> > > > > > > For string values returned from telemetry, escape any values =
=20
> > that =20
> > > > > > > cannot
> > > > > > > normally appear in a json string. According to the json =20
> > spec[1], =20
> > > > > the =20
> > > > > > > characters than need to be handled are control chars (char =20
> > value < =20
> > > > > > > 0x20)
> > > > > > > and '"' and '\' characters. =20
> > > > > >
> > > > > > Correct. Other chars are optional to escape. =20
> > > > >
> > > > > For json_writer (which I wrote for iproute2 and could have been =
=20
> > used =20
> > > > > here).
> > > > > The switch handles: \t \n \r \f \b \\ " ' as special cases. =20
> > > >
> > > > RFC 8259 chapter 7 says:
> > > >
> > > >    All Unicode characters may be placed within the
> > > >    quotation marks, except for the characters that MUST be escaped:
> > > >    quotation mark, reverse solidus, and the control characters =20
> > (U+0000 =20
> > > >    through U+001F).
> > > >
> > > > I have no preference for either, as long as '/' and other non- =20
> > control characters are not (unnecessarily) escaped. =20
> > > >
> > > > Using tested and maintained code like json_writer could be =20
> > beneficial. If you hold the copyright, there should be no license
> > issues. =20
> > > > =20
> > >
> > > I will take a look at json_writer. =20
> >=20
> > Took a quick look at json_writer, and it's certainly an option. The
> > main
> > gap compared to what we have in our current implementation is that
> > json_writer is designed around a stream for output rather than an
> > output
> > buffer. Now while we can use fmemopen to make our buffer act as a
> > stream
> > for writing, and the write apis should prevent it overflowing, we still
> > hit
> > the issue of the result of truncation not being valid json. The current
> > implementation tries to handle truncation more gracefully in that any
> > fields which don't fit just don't get added.
> >=20
> > I'll think about it a bit more, and see if there is a way that it can
> > be
> > made to work more cleanly. =20
>=20
> It sounds like json_writer provides a more advanced API, adding a lot of =
overhead for wrapping it into the Telemetry library. Since we only need a v=
ery simple encoder, perhaps copy-paste-modify is more viable. Or just proce=
ed with your RFC code.
>=20
> Regardless, the API and underlying code probably needs extra scrutiny, so=
 it doesn't become an attack vector into the control plane of a DPDK applic=
ation.

I wrote it based on the model used by some Java library.
Other JSON libraries were more concerned with parsing JSON.