On Mon, 2020-04-27 at 15:24 +0300, Dmitry V. Levin wrote:
On Mon, Apr 27, 2020 at 10:11:20AM +0200, 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.
OK, I don't mind this simpler 2 step process as well.
> The third step would be done in 1.5.0 release. If we do some 1.4.x
> releases in-between they would of course keep the situation the
> same as
> in 1.4.0.
>
> 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.
I don't think a deprecation in favour of out-of-tree modules is
problematic
in principle as long as the alternatives are properly buildable
modules.
pam_cracklib became obsolete long time ago, e.g. in ALT we stopped
building this module ~19 years ago.
> 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.
I agree. Can't we just take pam_faillock in then?
How much would it take to integrate pam_faillock in 1.4.0 release?
Not that much. I'm going to submit a PR as that is imho easier to work
on iteratively than a on a mailing list patch review.
Historically Thorsten did not want to add pam_faillock as another
locking module along with pam_tally and pam_tally2 but if we deprecate
them and remove them later, I think this objection would be moot.
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]