Viktor Dukhovni via Postfix-users:
> On Sun, Aug 13, 2023 at 01:47:05PM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > > Any votes for JSON? :-)
> > >
> > > { "account": "user:foo", "base64password": "AAAABBBBCCCC" }
> >
> > Before other people start to chime in, let me set some expectations.
>
> My suggestion of JSON is largely in jest. After taking generality to
> extremes, we can recoil in horror, and implement the simple solution.
>
> The only part of the suggestion that plausibly has modest merit is
> represent the password as a base64 binary blob. When passwords are
> non-ASCII, their representation in config files is no longer well
> defined. Who knows what encoding was used when the password was
> created, and what encoding is used by the maintainer of the config file.
>
> Therefore, treating the password as opaque binary data rather than text
> has some technical merit. On the other hand, non-ASCII passwords for
> accounts used by an unattended MTA to submit mail will be quite rare,
> and are likely not worth inconveniencing the majority.
I think the problem was with ':' in a login name. Postfix does not
care about ':' in passwords in smtp_sasl_password_maps fields
(the imlpementation uses split_at(), not argv_split()).
With base64, data entry is not user-friedly; it would require
tooling. JSON is less unfriendly than raw basee64, but would still
benefit from tooling, because it is easy to make a mistake when
crafting JSON by hand.
One problem is that both base6 and JSON provide a backdoor to inject
line breaks into Postfix configuration values. There would have to
be explicit code to reject such things. By design, Postfix does not
support line breaks in configuration values. The benefit is that
none of the code needs to worry about newlines that could mess up
headers, SMTP commands, file pathnames, shell command lines, the
content of generated files, so on. This is a reason why Postfix
uses base64 sparingly.
There is a tool that given a JSONschema will generate a parser in
C that populates a C structure, at github.com/badicsalex/json_schema_to_c
(~300 LOC). This depends on github.com/zserge/jsmn (~500 LOC). The
generated parser is much bigger, over 35 kLOC for the example. This
would be better than hand-written parsers (I'd never trust those),
or generic parsers that produce a generic parse tree and increase
application code complexity.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
