On 06/05/2026 16:13, William Lallemand wrote:
> On Wed, May 06, 2026 at 02:33:40AM +0300, Mia Kanashi wrote:
>> I'm not sure about crt-base. At least introducing an option just for EAB
>> doesn't seems to make that much sense, I will remove that base
handling for
>> now.
>
> We probably don't need to use any prefix system in that case, we
don't have one
> for maps and acls file, so it's not important. Users can just use
> default-path
https://docs.haproxy.org/dev/configuration.html#default-path which
> does a chdir() before the configuration parsing.
Had same thinking. And if someone wants to add something like *-base
just for EAB, that could be done in a backwards compatible way, unless
they would want to change some other behavior too.
>> Some other clients allow to put them in the config, but at least
those that
>> are servers allow to load from the file.
>> Nginx, Caddy, Stalwart do, out of the major ones.
>> In some cases like in Stalwart you can even specify PEM files inline.
>>
>> Caddy and Stalwart have interpolations to load from env or file.
>> Nginx does weird thing where id is specified in the config, but key
>> is in the separate file or inline in the config, that is just weird.
>>
>> I think if I made them literal options in haproxy, then:
>> 1. would replace files usage with env vars basically.
>> 2. would introduce a footgun because of lack of strong permission
>> separation.
>>
>> It is not like that is completely unworkable, you can split a single
>> config file into two after all, and make one part have different
>> permissions.
>> Some users may also have a different security model for the config file.
>>
>> Using env vars is also common for this, but I'm not sure, files work
better?
>> I'm ok with env variables but not ok with literal values.
>> For usecase of using systemd-credentials it better be a file path.
>>
>> HAProxy doesn't have "embed file as inline str" thing, without that
>> preprocessor
>> directive there is a big incentive to specify creds directly in the
config.
>>
>
> Environment variables are processed natively in the haproxy
configuration file,
> you can replace any word by a variable.
Yeah, that's what I meant by "would replace files usage with env vars"
HAProxy could also have like ${file:./something} that reads it from a file
instead of an env variable, maybe could be an a RFC, though not sure how
needed
that is, that is what I meant by "embed file as inline str" thing, something
that is for files and not env variables.
> Let me know if you need some help to split the patches, I can rework them
> myself if you don't have time.
>
> I won't have much time after thursday so it would be great if I can
merge that
> today or tomorrow, so they can land in the 3.4.0 release.
>
> Regards,
It is ok, I will submit new version today as soon as I can.
