On 2023-07-06, Andrew C Aitchison via Exim-dev <exim-dev@???> 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):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
