cracklib: generate the default dictionary on the target

Currently cracklib-native is used to generate the dictionary
database from the wordlist during install. Unfortunately the
database files are endian-specific and this results in
errors when the host and target endianness differ.

This patch creates the default dictionary files on the target
during post-install. In order to do this the default wordlist has
also been compressed, this enables an unmodified cracklib-format
to correctly parse the input file with both busybox and GNU gzip.
(These behave differently if the input is uncompressed, GNU
gzip behaves like cat while busybox returns an error).

Finally the cracklib-native package has been removed since
it is no longer used.

Signed-off-by: Martin Donnelly <martin.donnelly@ge.com>
---
 meta/recipes-extended/cracklib/cracklib_2.8.22.bb |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

On 4/25/13 8:28 AM, Martin Donnelly wrote:
> Currently cracklib-native is used to generate the dictionary
> database from the wordlist during install. Unfortunately the
> database files are endian-specific and this results in
> errors when the host and target endianness differ.
>
> This patch creates the default dictionary files on the target
> during post-install. In order to do this the default wordlist has
> also been compressed, this enables an unmodified cracklib-format
> to correctly parse the input file with both busybox and GNU gzip.
> (These behave differently if the input is uncompressed, GNU
> gzip behaves like cat while busybox returns an error).
>
> Finally the cracklib-native package has been removed since
> it is no longer used.

I thought we had fixed cracklib to have a fixed endian.  If not, this is a bug. 
  We want to avoid running things like the cracklib generation on the target if 
possible, as it impacts the first boot time and read-only roots.

(I'm fine with this as a workaround, but it's not the fix I'd like.)  I'd be 
happy if we simply fixed the cracklib-native to pass in an endian and have the 
right output generated.  (Note, we also have to consider structure 
alignment/packing as well.)

If there isn't already a bug in the Yocto Project bugzilla, can you add one?

--Mark

> Signed-off-by: Martin Donnelly <martin.donnelly@ge.com>
> ---
>   meta/recipes-extended/cracklib/cracklib_2.8.22.bb |   15 ++++++++++-----
>   1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-extended/cracklib/cracklib_2.8.22.bb b/meta/recipes-extended/cracklib/cracklib_2.8.22.bb
> index 7e398f4..9ebca33 100644
> --- a/meta/recipes-extended/cracklib/cracklib_2.8.22.bb
> +++ b/meta/recipes-extended/cracklib/cracklib_2.8.22.bb
> @@ -4,8 +4,7 @@ HOMEPAGE = "http://sourceforge.net/projects/cracklib"
>   LICENSE = "LGPLv2.1+"
>   LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
>
> -DEPENDS = "cracklib-native zlib"
> -DEPENDS_class-native = "zlib"
> +DEPENDS = "zlib"
>   PR ="r0"
>
>   EXTRA_OECONF = "--without-python"
> @@ -17,8 +16,14 @@ SRC_URI[sha256sum] = "feaff49bfb513ec10b2618c00d2f7f60776ba93fcc5fa22dd3479dd9ca
>
>   inherit autotools gettext
>
> -BBCLASSEXTEND = "native"
> -
>   do_install_append_class-target() {
> -	create-cracklib-dict -o ${D}${datadir}/cracklib/pw_dict ${D}${datadir}/cracklib/cracklib-small
> +	gzip ${D}${datadir}/cracklib/cracklib-small
> +}
> +
> +pkg_postinst_${PN} () {
> +if [ "x$D" = "x" ]; then
> +	create-cracklib-dict -o ${datadir}/cracklib/pw_dict ${datadir}/cracklib/cracklib-small.gz >/dev/null
> +else
> +	exit 1
> +fi
>   }
>

On 25/04/2013 15:25, Mark Hatle wrote:
> On 4/25/13 8:28 AM, Martin Donnelly wrote:
>> Currently cracklib-native is used to generate the dictionary
>> database from the wordlist during install. Unfortunately the
>> database files are endian-specific and this results in
>> errors when the host and target endianness differ.
>>
>> This patch creates the default dictionary files on the target
>> during post-install. In order to do this the default wordlist has
>> also been compressed, this enables an unmodified cracklib-format
>> to correctly parse the input file with both busybox and GNU gzip.
>> (These behave differently if the input is uncompressed, GNU
>> gzip behaves like cat while busybox returns an error).
>>
>> Finally the cracklib-native package has been removed since
>> it is no longer used.
>
> I thought we had fixed cracklib to have a fixed endian.  If not, this is
> a bug.  We want to avoid running things like the cracklib generation on
> the target if possible, as it impacts the first boot time and read-only
> roots.
>

I had a look for any patches which fixed this but couldn't see any, 
there were some related to using dictionaries between 32 and 64-bit 
machines of the same endianness but I maybe missed another one? I wasn't 
100% happy sending it for the issues you mention but thought it better 
to post it than not.

> (I'm fine with this as a workaround, but it's not the fix I'd like.)
> I'd be happy if we simply fixed the cracklib-native to pass in an endian
> and have the right output generated.  (Note, we also have to consider
> structure alignment/packing as well.)
>

Agreed, this would be best and it's something I'll look at when I've got 
the time.

> If there isn't already a bug in the Yocto Project bugzilla, can you add
> one?
>

Done, https://bugzilla.yoctoproject.org/show_bug.cgi?id=4419

-Martin