[exim-dev] Re: Variable names

Top Page
Delete this message
Reply to this message
Author: Andrew C Aitchison
Date:  
To: Jeremy Harris
CC: exim-dev
Subject: [exim-dev] Re: Variable names
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 ?
As an implementation detail it is currently untainted.
If someone decoded the hex it would pose a risk,
but I am prepared to assume that they will understand that they
do that at their own risk.

Exim is able to guarantee to the exim config that the hex-token is a
string of (not more than 256) hex digits, so I don't see a need for it
ti be tainted. Am I missing some other risk ?

There is actually another variable which is "between 1 and 16
characters comprised of only alphanumeric and dash characters" (ASCII
by RFC5324, I think). I *was* assuming that this would also be an
untainted variable.

> so I don't see it buys you anything. But - why does it matter if
> the value is tainted? How is it expected to be used?


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.

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.

The overall point of the exercise is to be able to, say, disable a
user's laptop but still allow them to read and send mail from their
phone or web-mail, should exim or the imap service believe that the
laptop is misusing the mail service.

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew@???


--
## 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/