[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#511069: ITP: libcrypt-salt-perl -- generate salt to be fed into crypt()

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov <dmn@debian.org>

* Package name    : libcrypt-salt-perl
  Version         : 0.01
  Upstream Author : Jonathan Steinert <hachi@cpan.org>
* URL             : http://search.cpan.org/dist/Crypt-Salt/
* License         : same as Perl (Artistic or GPL-1+)
  Programming Lang: Perl
  Description     : generate salt to be fed into crypt()

 The single exported subroutine in this module is for generating a salt
 suitable for being fed to crypt() and other similar functions.
 Variable length salts can be generated, the default salt is two
 characters long.


The package is a dependency of 'clive-utils', which is spun-off 'clive'
upstream and rewritten in Perl.

FTP-masters, the actual code in this package would be the following
function, the rest is POD, makefiles etc stuff.

 sub salt
    my $length = 2;
    $length = $_[0] if exists $_[0];

    return join "", ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[map {rand 64} (1..$length)];

There was a recent rejection[1] of a similar package.

    [1] http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/2008-December/017000.html

I hope someone can suggest a better place for that module. Separate
package, containing only few lines of code is not very nice indeed.

salt() is mostly useful with crypt(), which is part of core Perl. I
wonder if perl-modules package would be appropriate carier?

The 'join "", ...' part seems like taken straight from crypt()
documentation (perldoc -f crypt).

Finally there's always the option of patching clive-utils and putting inside
its own salt(). My problem with this is that I think code reuse is good,
even in small-scale.

dam            JabberID: dam@jabber.minus273.org

Attachment: signature.asc
Description: Digital signature

Reply to: