Dear Maintainer,


   * What led up to the situation?

was seeking to run radicale with PAM authentication. I installed the python3-pam
package, and the service, was able to recognize it, however the interface it was
expecting was all wrong.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I updated radicale/auth/pam.py to reflect the interface that is in python3-pam
 version 0.4.2-19.

   * What was the outcome of this action?

The service now supports PAM authentication, I am able to login/logout and it
stops me when I put in bad creedentials.

   * What outcome did you expect instead?

This is the expected outcome.

Quoting Robert Ismo (2025-11-01 23:32:18)
[...]
[...]

Looks like this bugreport is tied to bug#562702. Tagging accordingly.

Thanks for the patch - I will apply that now.

 - Jonas

Quoting Jonas Smedegaard (2025-11-06 19:09:39)

Looking closer, I have decided to not apply your patch after all:

Debian package python3-pam seems badly maintained upstream, but more
importantly calling PAM requires granting the web server access to
shadow group, which is a security risk.

You are of course free to take that risk, but I won't maintain a patch
for doing that.

What I recommend is to use the more convoluted approach of running a
dedicated authentication proxy as documented in the Debian package.

Since you have invested the time in making the patch, you might prefer
the more lightweight approach over my recommended safer one.  If so,
then I encourage you to propose upstream to include not one but two
PAM plugins, with the second one having your patches applied.  If
upstream chooses to adopt your patch, then I will not get in the way of
distributing it as well - I just won't invest time in maintaining it
specifically for Debian when I find it unsafe and not strictly needed.

Kind regards, and sorry for not accepting your work,

I will keep this bugreport open, for others running into the same issue
who might prefer your lightweight fix over my convoluted and safer one.

 - Jonas

Quoting Jonas Smedegaard (2025-11-06 19:45:10)

Your patch is now included with the radicale source package, but
commented out. That way it should be slightly easier for someone
prefering lightweight over secure to rebuild the package.

Thanks again,

 - Jonas

Hello, thank you for the feedback.
It seems the radicale package has the pam implementation for a newer
version of the python3-pam package, are you suggesting getting a
python3-pam-x.y.z package into upstream? I would be down. do you have
any guidance on how I would do this? I am on the debian-mentors mailing
list, would I reach out there for this?

Quoting Robert Ismo (2025-11-06 21:14:23)

 1. suggest upstream to add a fork of their PAM plugin with your patch
    applied
 2. package for Debian the python PAM module needed for the upstream
    PAM plugin.

Yes, for the 2nd option it makes sense to reach out to the
debian-mentors team, indeed.

Enjoy, whichever path you choose :-)

  - Jonas

I'm all for dropping features for whatever reason. I suggest three things:

1) Remove the option from /etc/radicale/config, so people don't think they can enable it.
2) Comment in the readme that PAM won't work for the reasons you provided. This will stop people from relying on the upstream documentation or other tutorials online (which say it should just work).3) Change the error message to journald when radicale is started with PAM enabled, which currently reads "An exception occurred during server startup: PAM authentication requires the Python pam module", implying that PAM authentication will work with the right packages. This is what I thought until I found this bug report. It should probably say "PAM authentication is not supported" instead.
The benefit to you is that fewer people like me will bother you trying to understand why it's not working (if they don't stumble upon this bug first). I'm not sure whether an undocumented feature worse than a documented unfeature.

Hi Borden,

Quoting Borden (2026-03-14 01:49:28)

As I wrote in my 1st reply, I will not get in the way of people wanting
to setup a lighter but also less secure system, so I will not remove
options. It seems I am therefore not convinced that 1) is a good idea,
but please do try be even more specific, if you think that some
concrete edits would be sensible without hiding options for more
adventurous users.

Same for 2): Can you suggest concrete changes to the documentation?
That would help me reflect on whether I find that an improvement over
the existing texts, and something that I feel that I am ok maintaining.

Thanks,

 - Jonas

13 Mar 2026, 21:17 by jonas@jones.dk:
If users want to patch radicale to authenticate over plain text or black magic, they can. Upstream has instructions on how to install through pip and git. It seems easier and safer to maintain patches against source than against Debian's updates.

Directing determined users to upstream seems far less aggravating to fielding complaints and bug reports. At least for me it is.