> For most use cases, this is clearly entirely the correct behaviour. In > those rare cases where someone really, really, wants to have an empty > password for an automatically created user, it would be nice if > user-setup would allow this directly, rather than requiring workarounds > such as reset with late_command.
Can you please provide some convincing use-cases for situations where someone "really, really" wants to have an empty password? I'm not at all convinced we should add this. IMO this adds needless complexity and code paths that will seldom be used and probably never tested. It also makes it possible to create an inherently insecure system, something we've always tried to avoid. And finally the documentation of such extremely rarely used options can only confuse users. I also don't see why it should be possible to do this for the normal user account, but not for the root user account. A few comments on the patch itself: > +# Allow preseeding whether to permit a blank password for created > non-root user > +Template: passwd/allow-password-empty > +Type: boolean > +Default: false > +Description: for internal use only The description should be "for internal use; can be preseeded" (in line with other similar templates). The second line of the description should hold a short description of the template (which is now in the comment; the comment can then be dropped): "Permit empty password for non-root account". Also, the name of the template does not indicate in any way that it's restricted to the non-root account. So to summarize: I don't yet see the necessity of adding this feature, especially as creating a passwordless account can trivially be be scripted during preseeding, it is insecure, and the implementation is inconsistent.
signature.asc
Description: This is a digitally signed message part.
