We have been shipping sudo_logsrvd by accident as we were not aware of
that program existing. I would like to apologize for that.

sudo is a complicated beast and a suid binary to make it worse. Hence,
the sudo maintainers would like to keep sudo's complexity as little as
possible. Especially, we would like to avoid depending on a library with
such a horrible track record as OpenSSL. Since OpenSSL is needed to
transmit the log trail securely, the SSL dependency is closely tied to
sudo_logsrvd.

I would like to ask the users of sudo_logsrvd about the importance of
having sudo_logsrvd. The sudo team is currently not in a position that
it is possible to seriously test and support input/output plugins and
log shipping. Therefore, if nobody steps up to help, the features are
going to be removed during the trixie cycle, making trixie the last
version of Debian that might support input/output logging and logsrvd.

Please note that willingness to help is a long-term commitment on an
understaffed team. We are not looking for a person who drops two --enable
lines into debian/rules, tries two experimental calls of sudo and the
vanishes again.

Greetings
Marc

Hi Marc!
Actually, it's me whih should do so, as I volunteered a long time ago to
take care of that, and then disappeared. Sorry for that.  I got covered
in work after some layoffs while still keeping project :/


I see that you already clarified on the sudo list, that openssl can be
disabled at configure.  So my proposal would be:

* Add --disable-openssl to the "normal" sudo binary package
  * Question: Should we also disable logsrv support in the package,
    given that it you transfer logs securely?
* Add openssl as builddepends.  That will enable openssl support in
  the sudo-ldap pacakge.


If possible / desidred before Trixie (so more or less right now):

* Split of logsrvd into a seperate binary package.

If not possible before Trixie:
* Would a low priortiy debconf question to sudo-ldap whether logsrvd should be
  enabled be a good idea?


Considerationts post trixie we could:
Rename sudo-ldap to "sudo-full" and the normal sudo to sudo-minimal and a
transition package sudo pointing to sudo-minimal?


Best regards,
  Alexander

Hi Marc!
Actually, it's me whih should do so, as I volunteered a long time ago to
take care of that, and then disappeared. Sorry for that.  I got covered
in work after some layoffs while still keeping project :/


I see that you already clarified on the sudo list, that openssl can be
disabled at configure.  So my proposal would be:

* Add --disable-openssl to the "normal" sudo binary package
  * Question: Should we also disable logsrv support in the package,
    given that it you transfer logs securely?
* Add openssl as builddepends.  That will enable openssl support in
  the sudo-ldap pacakge.


If possible / desidred before Trixie (so more or less right now):

* Split of logsrvd into a seperate binary package.

If not possible before Trixie:
* Would a low priortiy debconf question to sudo-ldap whether logsrvd should be
  enabled be a good idea?


Considerationts post trixie we could:
Rename sudo-ldap to "sudo-full" and the normal sudo to sudo-minimal and a
transition package sudo pointing to sudo-minimal?


Best regards,
  Alexander

Hi,

sudo-ldap will go away after the trixie release. That has been announced
for a long time, mainly because we don't enough ldap knowledge on the
team and because an alternative is available.

I'd like to ship sudo as minimal variant and a sudo-full as full
variant, with logsrvd in a separate package. But, given that we're going
into soft freeze in two weeks, I'd like to not touch the packaging of
sudo before trixie.

I planned to explore sudo_logsrvd in a test environmtn in later spring,
but if you're back then I don't need to do that. I'm happy about that.

Greetings
Marc