Control: clone -1
Control: reassign -2 release-notes
Control: retitle -2 release-notes: document deprecation of .pam_environment

On Sun, Jan 15, 2023 at 04:55:10PM +0300, Michael Tokarev wrote:
> On Sun, 28 Aug 2022 07:58:19 +0200 Francesco Potortì <> 
> wrote:
> > My log is full of these:
> >  sshd[4180530]: pam_env(sshd:session): deprecated reading of user 
> > environment enabled
> This comes from /etc/pam.d/sshd:
> session    required user_readenv=1 envfile=/etc/default/locale
> I'm not sure this is sshd issue or pam issue really: if it is deprecated
> in pam_env, sshd should not be using it, or it should not be deprecated.
> Removing user_readenv=1 fixes this.

There's now for this,
but as noted there I have documentation concerns about simply removing
this.  Copying my comments from there:

  This is going to have extensive fallout, the exact nature of which is
  hard to predict.  So far this deprecation has been the equivalent of
  posting a notice in the bottom of a locked filing cabinet stuck in a
  disused lavatory with a sign on the door saying "Beware of the
  Leopard".  The Debian PAM packages don't ship the upstream NEWS file,
  and even if they did, the notice there is extremely brief.  You can
  see a deprecation warning if you read /var/log/auth.log, but who has
  time for that unless something is going wrong? Besides, the people who
  are most affected will be users who have .pam_environment files in
  their home directories, and as far as I can tell nobody has gone to
  any particular effort to notify them.

  At a bare minimum, this needs an entry in debian/NEWS.  But I'd go
  further: I think this should be documented in Debian's release notes
  (repository at for a
  release before we make this change.  That won't inform everyone, but
  it should reduce the number of people caught unawares by this.  Any
  other practical ideas for informing affected users would be welcome.

  Also, we need to track down an actual reason for this change.
  "Security concerns" is not verbose enough to be convincing on its own.
  I found,
  which is not much better ("Due to problematic security ...").  My best
  guess is that upstream got fed up after dealing with things like, but I'm really just
  guessing, and proper documentation would actually explain this sort of
  thing rather than just waving a security flag.

I'm cloning this bug for the release notes, and CCing the PAM maintainer
for comments.


Colin Watson (he/him)                              []

Reply via email to