config.nix validation?

config.nix validation?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 692 bytes --]

Should the values from config.nix be validated in any way?  They are
obviously trusted, but it is very easy for the users to make mistakes
that could cause extremely confusing problems.  For instance, the
update patch doesn't support URLs with a query string or a fragment
specifier.  In fact, such URLs could get mangled.  There are other
URLs that tools like curl will accept but which will break the build.

Should these be validated with regular expressions before use?
That will result in build-time errors that at least somewhat point
to the source of the problem, rather than mysterious build-time or
runtime misbehavior.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: config.nix validation?

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> Should the values from config.nix be validated in any way?  They are
> obviously trusted, but it is very easy for the users to make mistakes
> that could cause extremely confusing problems.  For instance, the
> update patch doesn't support URLs with a query string or a fragment
> specifier.  In fact, such URLs could get mangled.  There are other
> URLs that tools like curl will accept but which will break the build.
>
> Should these be validated with regular expressions before use?
> That will result in build-time errors that at least somewhat point
> to the source of the problem, rather than mysterious build-time or
> runtime misbehavior.

Is there a way we could prevent those URLs getting mangled?

Assuming no, we don't know of anybody currently using the configuration
mechanism, so I wouldn't spend much time on it personally, but that
doesn't necessarily mean that you shouldn't.  Do it in separate patches
at least though so it doesn't hold up higher priority stuff.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: config.nix validation?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1819 bytes --]

On 11/9/25 06:13, Alyssa Ross wrote:
> Demi Marie Obenour <demiobenour@gmail.com> writes:
> 
>> Should the values from config.nix be validated in any way?  They are
>> obviously trusted, but it is very easy for the users to make mistakes
>> that could cause extremely confusing problems.  For instance, the
>> update patch doesn't support URLs with a query string or a fragment
>> specifier.  In fact, such URLs could get mangled.  There are other
>> URLs that tools like curl will accept but which will break the build.
>>
>> Should these be validated with regular expressions before use?
>> That will result in build-time errors that at least somewhat point
>> to the source of the problem, rather than mysterious build-time or
>> runtime misbehavior.
> 
> Is there a way we could prevent those URLs getting mangled?

Only with some additional complexity.  The URLs for SHA256SUMS and
SHA256SUMS.gpg are built by string concatenation, which breaks if there
is query string or fragment identifier.  Also, certain characters in
URLs will cause globbing in curl.  These characters are invalid and
should have been %-encoded.

> Assuming no, we don't know of anybody currently using the configuration
> mechanism, so I wouldn't spend much time on it personally, but that
> doesn't necessarily mean that you shouldn't.  Do it in separate patches
> at least though so it doesn't hold up higher priority stuff.

The updater requires the configuration mechanism to work.  Therefore,
I expect it to be used much more frequently in the future.  The only
sensible defaults are those used by Spectrum itself, and the
corresponding URLs and signing keys don't exist yet.

Should these patches be part of the same patch series or a separate
one?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: config.nix validation?

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 11/9/25 06:13, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>> Should the values from config.nix be validated in any way?  They are
>>> obviously trusted, but it is very easy for the users to make mistakes
>>> that could cause extremely confusing problems.  For instance, the
>>> update patch doesn't support URLs with a query string or a fragment
>>> specifier.  In fact, such URLs could get mangled.  There are other
>>> URLs that tools like curl will accept but which will break the build.
>>>
>>> Should these be validated with regular expressions before use?
>>> That will result in build-time errors that at least somewhat point
>>> to the source of the problem, rather than mysterious build-time or
>>> runtime misbehavior.
>> 
>> Is there a way we could prevent those URLs getting mangled?
>
> Only with some additional complexity.  The URLs for SHA256SUMS and
> SHA256SUMS.gpg are built by string concatenation, which breaks if there
> is query string or fragment identifier.  Also, certain characters in
> URLs will cause globbing in curl.  These characters are invalid and
> should have been %-encoded.
>
>> Assuming no, we don't know of anybody currently using the configuration
>> mechanism, so I wouldn't spend much time on it personally, but that
>> doesn't necessarily mean that you shouldn't.  Do it in separate patches
>> at least though so it doesn't hold up higher priority stuff.
>
> The updater requires the configuration mechanism to work.  Therefore,
> I expect it to be used much more frequently in the future.  The only
> sensible defaults are those used by Spectrum itself, and the
> corresponding URLs and signing keys don't exist yet.
>
> Should these patches be part of the same patch series or a separate
> one?

Up to you, as long as they come later in a series than everything more
urgent.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]