Hi,
On Mon, Apr 27, Tomas Mraz wrote:
On Sat, 2020-04-25 at 00:40 +0300, Dmitry V. Levin wrote:
> Hi,
>
> I suggest to start a formal procedure of deprecating modules.
>
> For example, we could use a simple 3-step deprecation algorithm:
> - declare a module as deprecated in the upcoming release N,
> - do not build it by default right after release N,
> - remove it from the tree right after release N+1.
>
> I suggest starting with pam_tally (obsoleted by in-tree pam_tally2),
> pam_tally2 (obsoleted by out-of-tree pam_faillock), and pam_cracklib
> (obsoleted by out-of-tree pam_passwdqc and pam_pwquality), this means
> declaring them as deprecated in 1.4.0 release.
>
> This would mean making Linux-PAM releases more regular and more
> often,
> e.g. twice a year.
>
> Comments?
I agree although I could even agree with 2 step process - i.e. merge
the first two steps - Declare the three modules above as deprecated in
1.4.0 and do not build them by default.
Nobody is reading a deprecation notice, and if he read its, he stil
does not take action since he thinks he has plenty of time.
So I think we should do the first two steps together, too:
- declare as deprecated and disabled it by default, so people notice and
are enforced to get active, and if it is only by enabling the module
again
- remove it from the code.
There is one issue with deprecating these modules and that is that
the
replacement modules are out of tree. For pam_cracklib the situation is
a little bit less problematic as both out-of-tree replacement modules
are full projects buildable separately.
For openSUSE we switched now to pam_pwquality, it's really simple to do
automatically and up to now nobody noticed.
So I'm fine with disabling pam_cracklib.
On the other hand the
pam_faillock code is supposed to be built along the Linux-PAM modules.
So if we want to deprecate pam_tally* modules we should also integrate
pam_faillock instead. If not in 1.4.0 release then definitely before we
drop the modules completely.
We dropped pam_tally from SUSE ages ago. But it's interesting how long
people refuse to migrate to something else like pam_tally2, even if there
are all of their problems are solved.
That's the biggest problem with pam_tally2 vs pam_faillock, I don't see
an easy, automatic way to migrate, so the user acceptance will be low.
But dropping pam_tally* in favour of pam_faillock is fine with me,
since we added pam_faillock now, we should really disable the three
modules.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)