From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 770B41FF0B3 for ; Wed, 11 Nov 2026 14:50:47 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 2C6DF2167B; Wed, 11 Nov 2026 14:50:44 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 11 Nov 2026 14:50:39 +0100 Message-Id: Subject: Re: [PATCH pve-common v4 01/17] json schema: add multiline string format To: "Thomas Lamprecht" , "Wolfgang Bumiller" From: "Max R. Carrara" X-Mailer: aerc 0.18.2-0-ge037c095a049 References: <20261106154554.2182986-1-m.carrara@proxmox.com> <20261106154554.2182986-2-m.carrara@proxmox.com> <5b33c71e-8ed3-45dc-a106-c8b4f64e405a@proxmox.com> In-Reply-To: <5b33c71e-8ed3-45dc-a106-c8b4f64e405a@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1794405039679 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.305 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: UKR6FQQUWLGI2EEFFVD5S6YHRAYGX6IN X-Message-ID-Hash: UKR6FQQUWLGI2EEFFVD5S6YHRAYGX6IN X-MailFrom: m.carrara@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com, Alfonso Kuen , Thomas Ellmenreich , Jakob Klocker X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed Nov 11, 2026 at 12:38 PM CET, Thomas Lamprecht wrote: > Am 11.11.26 um 11:56 schrieb Max R. Carrara: > > On Tue Nov 10, 2026 at 2:39 PM CET, Wolfgang Bumiller wrote: > >> Given that right now, newlines are almost never wanted/allowed in our > >> API (apart from comments), there's a case to be made here that we migh= t > >> just want a multiline schema flag. (Where by default we'd reject > >> newlines. This could potentially remove a whole class of possible futu= re > >> section-config related bugs=E2=80=A6) > > > > If a fear of SectionConfig bugs is preventing us from simply adding > > multiline strings, we should seriously consider migrating the > > SectionConfig *file format* to something different in the long term. > > unescaped newline will cause issues in most (non-binary) formats, lets > not overreact here... Many modern formats like TOML and HJSON support multiline string literals. Or am I misunderstanding something here? > > >> Also, consider that on the rust side, 'format', 'enum', 'pattern', and > >> the verify-functions are part of the `ApiStringFormat` *enum*, so you > >> can only have one, [...] > > > > Which is something we should change eventually then, since validation > > keywords are independent unless explicitly stated otherwise, at least a= s > > per section 3.1.1 of this draft: > > > > https://json-schema.org/draft-07/draft-handrews-json-schema-validation-= 00.pdf > > > > Sure, you could argue that it doesn't make sense to have `format`, > > `enum`, and `pattern` co-exist for the same property, but the spec > > doesn't place any restrictions on this. > > > > > >> [...] and we do not have *named* formats at all. > > > > Why not? > > > >> > >> Thomas also played around with the thought of adding a multiline boole= an > >> to string schemas, so this may be a good time to come to a decision > >> here. > >> > >> IMO, while not strictly being part of any JSONSchema/openapi spec, it > >> would be fine to have that. Also, I'm quite sure that whenever we use > >> patterns or other formats, a pattern which does not want to opt into > >> multiline support should be written in a way which does not allow > >> newlines *anyway*, so for the most part it would act as a hint, but > >> additionally provide a safe-guard just in case. > > > > NAK -- I don't think we should deviate from the spec just to make a > > FWIW we're not exactly spec conform nor fully support all potential > variants now and I hardly see why one has to bend backward to do either > here. That's what I'm trying to point out here; we seem to "bend backward" to adapt things like JSONSchema to SectionConfig, instead of doing it the other way around. I'm not arguing in favor of supporting the entire JSON schema spec or fully support all sorts of variants; of course it's more prudent and practical to only implement what we need. > We should strive for consistency inside the project, that's > currently mostly ensuring rust and perl side are not disagreeing in > relevant cases to make future migration effort. I completely agree, and that's what I'm trying to argue in favor of here. I think we make it harder for ourselves by trying to work around the SectionConfig file format's peculiarities, instead of having a file format that actually allows us to express what we need. (And I would personally also like to avoid more JSON blobs in SectionConfig) > > I want an actual useful and safe system for our implementation > "dialect", not punish ourself in the name of spec conformity. I don't think that we are punishing ourselves here for spec conformity at all; we can conform to the spec and still have a safe system. FWIW, I double-checked the spec and custom keywords are indeed spec-conformant [0], so we wouldn't actually be "deviating" from anything here anyway. In that case, both `format =3D> 'multiline'` and `isMultiline =3D> 1` approaches are fine by me -- but that still doesn't address the fact that SectionConfig does not handle multiline strings at the moment, unless the implementor handles it themselves. (Side note: If we keep adding more custom keywords, defining them in a custom vocabulary schema wouldn't hurt, perhaps; even if we just use it for documentation purposes and to make it easier for ourselves to keep the Perl & Rust implementations in sync.) > > > > multiline string format work. The `format` key handles it already, and > > any frontend helpers that convert the schema of a property to UI > > elements can check for this format and adjust the element's type > > accordingly. > > > > This is already what this series does, and unless I have missed > > something, works just fine without any additional contortions. > > > > The exception here is that SectionConfig, due to how its file format is > > designed, does not allow reading / writing multiline strings, which > > means that properties with `format =3D> 'multiline'` would have to be > > handled as a special case. We already do this for many other properties > > in `encode_value` / `decode_value` anyway -- and in the case of the > > `multiline` format, the call site can opt to reading from / writing to = a > > file for that particular property. > We handled quite a few issues with newline being an potential escape > vector in all kind of config formats, it needs to be treated carefully > and also passed around carefully. Allowing to build on a lower-level > guarantee that something cannot contain newlines can help make all > safer much easier. It would be interesting to know which issues you mean in particular, because then we could look for a common pattern. Perhaps you already did, but having that context certainly wouldn't hurt. [0]: https://json-schema.org/draft/2020-12/json-schema-core#section-6.5