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

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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...

>> 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. 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 want an actual useful and safe system for our implementation
"dialect", not punish ourself in the name of spec conformity.


> 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.