Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=2490

Fabian Groffen <grobian@gentoo.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |grobian@gentoo.org

--- Comment #1 from Fabian Groffen <grobian@gentoo.org> ---
what seems like a test replicating the scenario that affected me:

- create a user, with password, unlocked
- in authenticators section, create PLAIN driver with
server_condition = "${if pam{$2:$3}{1}{0}}"
- try to deliver email in authenticated mode using aforementioned user

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2490

--- Comment #2 from Jeremy Harris <jgh146exb@wizmail.org> ---
What's needed for the Exim project is an actual test script plus config file,
plus any supporting data files, that can be run as part of the project
regression
testsuite. Having to modify the test platform /etc/password (or equivalent) is
probably not tolerable.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2490

--- Comment #3 from Fabian Groffen <grobian@gentoo.org> ---
Well, since you already demand root access for the build animals, I guess
running useradd isn't an issue. But I'd be very happy to setup a bunch of
users for the test suite to use to verify instead as well.

I'm not familiar with Exim's testsuite nor with the tools around it that it
uses to interact, etc. I try to provide as much resources as I can to improve
on the testing part.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2490

--- Comment #4 from Jeremy Harris <jgh146exb@wizmail.org> ---
While technically feasible, I don't think modifying the test system
configuration
at that level is acceptable. The test needs to be a thing that anybody can run
without a manual configuration step, and without worrying that their system
might be adversely affected. Of course, this presents a bit of a problem
with something testing a security component...

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2490

--- Comment #5 from Fabian Groffen <grobian@gentoo.org> ---
I'm a bit confused, setting up a build animal has proven to me one needs a
dedicated, isolated VM, because of the the vast requirements especially in sudo
escalation.

Testing this and other machanisms as this without faking tricks, such as
chroots, ld_preloads etc. requires full access. Faking tricks may not even be
sufficient to test the full scheme.

The ways in which Exim 4.94 broke production systems on multiple levels (not
just this bug) seems to warrant doing animal testing that requires invasive
control/access to the test host.

That users who run tests themselves cannot, and/or should not run those tests
by default, seems obvious to me. In fact, testing is skipped, there appears to
be no make check or make test available. Is there? Anyway, perhaps this bug
is not the right medium to discuss such things.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##