On 2023-07-06, Andrew C Aitchison via Exim-dev <[email protected]> wrote: > On Thu, 6 Jul 2023, Jeremy Harris via Exim-dev wrote: > >> On 06/07/2023 17:21, Andrew C Aitchison via Exim-dev wrote: >>> I'm writing a CLIENTID extension for exim which will >>> add some variables to be used in the exim config. >>> >>> One of them, call it "token", is unsafe and cannot be safely untainted >>> (it is a string of "between 1 and 128 printable characters") so I am >>> thinking of exposing a second variable which is the string hex-encoded. >> >> That second one should also be tainted, in that case, > > Why should the hex-encoded version be tainted ?
Why should it not be tainted? why should it exist? > This token is somewhere between a username and a password. > It is shared with the associated imap service. > It is likely to appear in logfiles and be used as a rate-limit > key and in block lists. There's no need to untaint it for those uses, it will also work in all kinds of database lookups. > I don't have much or recent experience with user databases, and they > vary a lot, so I expect at least initially, that people will have to > write their own configurations to integrate it with their user database > and to communicate with the imap service (so that blocking or > unblocking in one does the same in the other). > > My observation from the exim lists is that people struggle to write > configs that work with tainted variables, so it seems important to > make safe variables available to the exim config. Tainting is a new feature so it hits established users by surprise when deployed, and then they post here. Usually only a little re-thinking is needed to get an untainted value when needed. -- Jasen. 🇺🇦 Слава Україні -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/ ## unsubscribe (doesn't require an account): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
