packaging an alternate dictionary for cracklibs?

[Matthew Miller]

The cracklibs-dict package is ... quite ... comprehensive. It weighs in at
almost 10MB on disk. Modern password guidance emphasizes length rather than
complicated checks, and this 10MB payload is increasingly irrelevant. I'd
like to provide an alternative, using a list of the 10,000 most common
passwords found in password breeches. This compresses down to about 1k, so
it's significant space savings, and may result in less user frustration
while still giving some real protection against the worst choices -- and
meeting security checklist items like "passwords checked against a
dictionary".

The problem is that cracklib seems to have a compile-time option for where
to find its dictionary. cracklib-dicts is already a subpackage, and a
cracklib-10k-worst or something alternative package could just be a drop-in
replacement... except of course it would conflict. Is this an okay use of
Conflicts? If not, what _should_ I do?


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Wed, Dec 2, 2020 at 2:08 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  The cracklibs-dict package is ... quite ... comprehensive. It weighs in at
>  almost 10MB on disk. Modern password guidance emphasizes length rather than
>  complicated checks, and this 10MB payload is increasingly irrelevant. I'd
>  like to provide an alternative, using a list of the 10,000 most common
>  passwords found in password breeches. This compresses down to about 1k, so
>  it's significant space savings, and may result in less user frustration
>  while still giving some real protection against the worst choices -- and
>  meeting security checklist items like "passwords checked against a
>  dictionary".
>
>  The problem is that cracklib seems to have a compile-time option for where
>  to find its dictionary. cracklib-dicts is already a subpackage, and a
>  cracklib-10k-worst or something alternative package could just be a drop-in
>  replacement... except of course it would conflict. Is this an okay use of
>  Conflicts? If not, what _should_ I do?
>  
Each subpackage can have virtual Provides+Conflicts to indicate one
*must* be installed:

Provides: cracklib-dictionaries
Conflicts: cracklib-dictionaries

Then cracklib itself can do the following:

Requires: cracklib-dictionaries
Suggests: cracklib-dicts-10k-worst

And cracklib-dicts-full (replacing old cracklib-dicts) would do the following:

Obsoletes: cracklib-dicts < %{version}-%{release}
Provides: cracklib-dictionaries
Conflicts: cracklib-dictionaries



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Matthew Miller]

On Wed, Dec 02, 2020 at 02:11:50PM -0500, Neal Gompa wrote:
>  Each subpackage can have virtual Provides+Conflicts to indicate one
>  *must* be installed:
>  
>  Provides: cracklib-dictionaries
>  Conflicts: cracklib-dictionaries
>  
>  Then cracklib itself can do the following:
>  
>  Requires: cracklib-dictionaries
>  Suggests: cracklib-dicts-10k-worst
>  
>  And cracklib-dicts-full (replacing old cracklib-dicts) would do the following:
>  
>  Obsoletes: cracklib-dicts < %{version}-%{release}
>  Provides: cracklib-dictionaries
>  Conflicts: cracklib-dictionaries 
Is there a way for subpackages to actually contain different files with the
same path/name?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Patrick Riehecky]

On Wed, 2020-12-02 at 15:26 -0500, Matthew Miller wrote:
>  On Wed, Dec 02, 2020 at 02:11:50PM -0500, Neal Gompa wrote:
>  > Each subpackage can have virtual Provides+Conflicts to indicate one
>  > *must* be installed:
>  > 
>  > Provides: cracklib-dictionaries
>  > Conflicts: cracklib-dictionaries
>  > 
>  > Then cracklib itself can do the following:
>  > 
>  > Requires: cracklib-dictionaries
>  > Suggests: cracklib-dicts-10k-worst
>  > 
>  > And cracklib-dicts-full (replacing old cracklib-dicts) would do the
>  > following:
>  > 
>  > Obsoletes: cracklib-dicts < %{version}-%{release}
>  > Provides: cracklib-dictionaries
>  > Conflicts: cracklib-dictionaries
>  
>  Is there a way for subpackages to actually contain different files
>  with the
>  same path/name?
>  
>  
My initial reaction is I'd be inclined to use 'alternatives'[1] to
achieve this.... 

Pat


[1] https://github.com/fedora-sysv/chkconfig

[Neal Gompa]

On Wed, Dec 2, 2020 at 3:27 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Wed, Dec 02, 2020 at 02:11:50PM -0500, Neal Gompa wrote:
>  > Each subpackage can have virtual Provides+Conflicts to indicate one
>  > *must* be installed:
>  >
>  > Provides: cracklib-dictionaries
>  > Conflicts: cracklib-dictionaries
>  >
>  > Then cracklib itself can do the following:
>  >
>  > Requires: cracklib-dictionaries
>  > Suggests: cracklib-dicts-10k-worst
>  >
>  > And cracklib-dicts-full (replacing old cracklib-dicts) would do the following:
>  >
>  > Obsoletes: cracklib-dicts < %{version}-%{release}
>  > Provides: cracklib-dictionaries
>  > Conflicts: cracklib-dictionaries
>
>  Is there a way for subpackages to actually contain different files with the
>  same path/name?
>  
Yes. You can declare each (sub)package to do something like so:

%package -n cracklib-dicts-full
RemovePathPostfixes: .dicts-full

...

%install
install -pm 0644 sourcefile
%{buildroot}/path/to/location/cracklib-dicts.dict.dicts-full

...

%files -n cracklib-dicts-full
/path/to/location/cracklib-dicts.dict.dicts-full

The end result will have cracklib-dicts-full containing
/path/to/location/cracklib-dicts.dict


--
真実はいつも一つ！/ Always, there's only one truth!

[Matthew Miller]

On Wed, Dec 02, 2020 at 03:30:30PM -0500, Neal Gompa wrote:
>  Yes. You can declare each (sub)package to do something like so:
>  
>  %package -n cracklib-dicts-full
>  RemovePathPostfixes: .dicts-full 
Neat! That's a new trick for me. Thanks!

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader