Re: exim

Unfortunately I like/use exim for years - pretty simple config file syntax.

from here:

https://seclists.org/oss-sec/2023/q3/254

So... I suppose those fixes were shared also with Exim's OpenBSD manteiners?

--

Next contact with ZDI was in May 2023. Right after this contact we
created project bug tracker for 3 of the 6 issues. 2 high scored of them
are fixed (OOB access). A minor scored (info leak) is fixed too.

Fixes are available in a protected repository and are ready to be
applied by the distribution maintainers.

The remaining issues are debatable or miss information we need to fix
them.

We're more than happy to provide fixes for all issues as soon as we
receive detailed information.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--

On 9/30/23 10:37, Theo de Raadt wrote:
> Stuart Henderson<stu@spacehopper.org> wrote:
>
>> With OpenBSD release fast approaching and considering the lack of solid
>> information about the vulnerabilities, I think we should probably mark
>> mail/exim BROKEN for now.
> That's almost too kind.
>
>> And also consider whether we want to keep this in ports at all...
>> The response to this was much weaker than I'd expect from maintainers
>> of software like this (note that it is a huge setuid root binary so
>> it'd really be nice if they were a bit more active on that front)
> Lacking any elements of privsep design. In this regard, it is a very
> strange piece of software.
>
> sendmail was so terrible decades ago, that qmail showed up as
> privsep-based-upon-file-moves. That was privsep program #2. Then
> postfix, called vmailer at the time, showed up with privsep via other
> forms of object movement, which is privsep program #3. (openssh then
> showed up as privsep program #4. In my version of history, privsep
> program #1 is the BSD auth subsystem, which is a piece of libc executing
> gid-hidden setuid/setgid-if-needed service programs with their own
> address spaces). Many years later, sendmail even grew some aspects of
> privsep. But exim? No...... it's a newer piece of software using
> old design rules.
>
> It's a bad piece of software to expose users to, via the ports/packages.
> Perhaps right after the ides of March next year, we should just move exim
> into base.
>