Re: [PATCH pve-common v4 01/17] json schema: add multiline string format

["Max R. Carrara" <m.carrara@proxmox.com>]

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 might
> >> just want a multiline schema flag. (Where by default we'd reject
> >> newlines. This could potentially remove a whole class of possible future
> >> section-config related bugs…)
> >
> > 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 as
> > 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 boolean
> >> 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 => 'multiline'` and
`isMultiline => 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 => '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