Provide a commandline utility to create password hashes

[gvegidy]

Currently there is no commandline utility that I know of that

• actually uses lib(x)crypt and does not reimplement the hashes itself (like htpasswd)
• is commonly available on most linux distributions (there is for example "mkpasswd", hidden in the "whois" package on Debian and derivatives, but which is not packaged on Fedora)
• offers easy access to all the new hash methods of libxcrypt like yescrypt

So when you search for tips how to create a password hash on the command line, you get either recommendations to use tools which are limited in the choice of hash functions they offer, or don't work on your distribution at all.

I think the change from the glibc-embedded libcrypt to a separate libxcrypt is a good opportunity to provide such a tool and make it available on a broad selection of distributions. I think the best solution would be if you provide it directly with libxcrypt and suggest to maintainers to provide it in a package named "libxcrypt-tools" or similar.

[rfc1036]

Maybe you want to talk to the Fedora maintainer then, and have this fixed? My whois package is present in all Linux distributions, mkpasswd does all that, supports all hashes in libxcrypt at the time of its release and will continue adding new ones in the future.

[zackw]

@rfc1036 Oh, is that why the Debian whois package now has a dependency on libcrypt2? It seems to me that the whois package is not an obvious place to look for a utility like this. I'd be willing to consider shipping it as a demo/utility with libcrypt, if you'd like to contribute it.

Having said that, your tone makes it sound like you are rejecting the bug and furthermore you think OP should go jump in a lake. If you can't be more polite, kindly do not be the first responder to bugs here in the future. I do not want anyone who goes to the trouble of submitting bugs to this project to think they have been blown off by the maintainers.

[besser82]

@gvegidy @ppisar I've filed a bug with the maintainer of the whois package in Fedora. I hope he will add the mkpasswd binary for use with libxcrypt.

[besser82]

@ppisar Would you mind me - using my proven packager powers - to add the binary to the package for F29+, if you don't have time to do it?

[ppisar]

I would mind. The executable already exists in a different Fedora ("expect") package. The tool is exclude from whois package on purpose. Please continue discussion in the Fedora bug report.

[gvegidy]

I can fully understand why Fedora does not package mkpasswd from whois, because I do not think whois is an obvious package to look for such a tool. Also there is the conflict with the mkpasswd program from expect which does something different (it's main purpose is to create a random password, but it also has limited options to forward it to /bin/passwd).

I think the best solution to all these problems would be to

• use a new name for such a tool which does not conflict with common binary names
• distribute this tool in a tarball that is named in a way that suggests that it has to do something with lib(x)crypt, shadow or password handling

[gvegidy]

@rfc1036 would you consider splitting mkpasswd out of the whois package and into a separate package?

[zackw]

@rfc1036 On a box running Debian unstable,

$ /usr/bin/mkpasswd --method=help
Available methods:
sha512crypt     SHA-512
sha256crypt     SHA-256
md5crypt        MD5
descrypt        standard 56 bit DES-based crypt(3)

$ /usr/bin/mkpasswd --version
mkpasswd 5.4.0

Copyright (C) 2001-2018 Marco d'Itri
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ldd /usr/bin/mkpasswd 
	linux-vdso.so.1 (0x00007ffd925c6000)
	libcrypt.so.2 => /lib/x86_64-linux-gnu/libcrypt.so.2 (0x00007f68b1f57000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f68b1d9a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f68b1fb0000)

That doesn't look like "all hashes in libxcrypt" to me. (I can file this as a separate bug somewhere if you'd prefer to track it that way -- just lemme know wqhere.)

[gvegidy]

@zackw I compiled the latest version of mkpasswd from https://github.com/rfc1036/whois and it is able to use scrypt, yescrypt and so on

[besser82]

@gvegidy Are you fine with the current solution, we now have in Fedora?

---

@rfc1036 I have two proposals about how we can solve this for the majority of libxcrypt users:

1. How about renaming the mkpasswd tool to mkpassphrase?
2. If you agree to relicense that tool to BSD 2-clause, we can start to ship it with libxcrypt, so any of our consumers can get it.
3. In Fedora I can ship the tool in the libxcrypt-tools package then.

[gvegidy]

@besser82 When wearing my end user hat, everything will be fine soon when the conflict with the expect package is resolved.

When wearing a packager hat, I still have a bit of an unpleasant feeling about taking the source from a network database interface tool to build a password hashing program. I would very much prefer if @rfc1036 would release mkpasswd as a separate package or if it is transfered to libxcrypt.

[rfc1036]

An historical note first: the whois package also contains the mkpasswd program because the RIPE whois client provided a similar tool at least as far as 1998, and somebody being confused by this every now and then never looked to me like a valid justification to split an already tiny package.

@zackw due to boring reasons libxcrypt updates in Debian are currently stuck in NEW, but I expect that this will be solved very soon. But my current plan is to stop shipping libcrypt2 and coordinate replacing libcrypt1 with the libc maintainers. At that point mkpasswd will automatically support again all the algorithms.

@besser82 if this is what you think is best then feel free to fork mkpasswd, relicense it as appropriate and change it as much as you please. For the time being I will continue to maintain it in the whois package because it is a fun toy and because I still have the (probably misguided) goal of supporting old/weird/proprietary UNIX systems as well.

[ppisar]

Before you publish the fork under a difference license, please check authors of all the lines of your new fork and ask them for the new license. It's not only Marco d'Itri. Especially the translations in po/*.po files. And I can assure you that I don't give you a permisson to use my work under a different license. You would have to remove the po/cs.po file.

[gvegidy]

@besser82 Why do you want to relicense it?
It currently is GPLv2+. The library parts of libxcrypt are LGPLv2.1. Having libxcrypt-tools licensed GPLv2+ or GPLv3 would be a good match, wouldn't it?

[Woi]

May this be closed? mkpasswd is available in Fedora 37:

$ rpm -qf $(which mkpasswd)
mkpasswd-5.5.15-1.fc37.x86_64

$ mkpasswd -m yescrypt
Password: 
$y$j9T[...]

[gvegidy]

mkpasswd is now available in many distributions, Fedora among them. So from a users perspective this is solved.

But I still think it would be better to have a native commandline utility as part of libxcrypt in the long run. This would allow faster and easier development of additional library options, things like the salt customization in the linked mkpasswd-issue 119 or some additional complexity configuration for a new algorithm.

Also while whois doesn't look like it is going away anytime soon, the Regional Internet Registrys (RIRs) are slowly but continuously working on replacing whois with RDAP. In the long run this could lead to distributions no longer packaging whois.

[zackw]

I may eventually get around to implementing this utility, but I have a long list of higher priorities. For clarity, we currently have a "no more GPL or LGPL code" contribution policy, which is why we have not just stolen @rfc1036's implementation. (I am willing to consider changing that policy, but only if we get a definitive "no we're not interested" response from the BSDs re using libxcrypt as their official libcrypt (which would necessitate removing the small amount of LGPL code that we currently have.)