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. > The reason I put them into files is because they are credentials. The fact > that they are short or not doesn't matter. They are similar to username and > password. > So in my opinion storing a key in the config file shouldn't be allowed, > as it is a footgun. I've seen a few people putting that on github in public. > It isn't as obvious that that short base64url encoded string is a > credential. > > What exactly can the attacker do will depend on the ACME provider, > but it is a similar threat to the account key theft, may be worse or may be > not. Most of the time the config file and these files have the same permissions but I get your point. > 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. We do already have the userlists that are stored as strings in the configuration. That's clearly not ideal. > For a basic automation writing fields from a json file into files is simple, > simpler than templating a config. > I don't want to introduce a new file format in the configuration parser, it only adds a specific configuration parsing, we need things to be generic. > Though for that case there are also other ways automatian could be done it is > possible to register an account using Lego and then pass it to haproxy, that > should work and doesn't require haproxy to support EAB. > > > Some setups have a haproxy config that is immutable, and world readable, > like nixos setups. Having an haproxy configuration which is readable by everyone can be a real security issue unfortunately. > Literal values could be handled in addition to the file paths, but that adds > even more complexity. > > Overall I just don't think it is a great idea. > > I would much much prefer if creds were a single file though, fiddling with > two files isn't great, but inventing own file format for that also isn't > great. > File config does indeed add some complexity, it is true, I don't like that. > > So yeah, that was an intentional design choice, has downsides though, > I hope I made benefits clear too. Well in this case let's keep this implementation. 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, -- William Lallemand
