[Pkg-shadow-devel] Removing shadowconfig

[Chris Hofstaedtler]

Hi,

I would like to remove the shadowconfig utility, which is a
Debian-specific thing. Below is an overview of the current state;
why IMO it should go away; and how.

Background
----------

shadowconfig is currently documented as (thanks Alejandro!):

> Synopsis
>        shadowconfig on|off
> 
> Description
>        shadowconfig on will turn shadow passwords on.
> 
>        shadowconfig off will turn shadow passwords off.
> 
> Errors
>        shadowconfig  will print an error message and exit with a nonzero code if it finds anything awry.  If that happens,
>        you should correct the error and run it again.  Turning shadow passwords on when they are already on, or  off  when
>        they are already off, is harmless.
> 
> Caveats
>        Turning shadow passwords off and on again will lose all password aging information.

Implementation details:

The implementation for "off" is straight forward, it calls various
tools from the passwd Debian package (pwck, grpck, pwunconv,
grpunconv).

For "on", we have two implementations. One again calls the tools
(pwck, grpck, pwconf, grpconv).
The other implementation runs when /etc/passwd and /etc/group are
unchanged from base-passwd's master files, and then creates
reproducible /etc/{passwd,shadow,group,gshadow} files from the
master files.

Defaulting to shadow passwords: passwd.postinst runs shadowconfig on
unconditionally on first install. Thus all new systems that get
passwd installed will have shadow passwords.
Upgrades of passwd do not enable shadow passwords.

Rationale
---------

Turning off shadow passwords has no - to me - known usecase.
Removing shadowconfig would remove needless complexity and some
maintenance upkeep. It would also remove a Debian-specific thing
that (I believe) no other distro has.

Proposal
--------

Option A: limited to src:shadow:

Move the "shadowconfig on" implementation into passwd.postinst,
keeping it limited to new installs of the passwd package.
Drop the shadowconfig utility and manpage, and the Debian patches
introducing them.

Option B: Interim step:

Drop "shadowconfig off", and see if users show up.

Option C: maybe, not thought out:

A more global approach could have base-passwd set up shadow
passwords. I have not looked into this at all and also not discussed
it with Colin Watson (base-passwd maintainer).

-----

I plan to implement option A for trixie, targetting end of January
2025.

If you have a good usecase for keeping shadowconfig, please reply.
Even more so if you have a good usecase for "shadowconfig off"!

Chris