search

besser82 / libxcrypt

Extended crypt library for descrypt, md5crypt, bcrypt, and others
GNU Lesser General Public License v2.1
189 stars 52 forks source link

Provide a commandline utility to create password hashes #64

Open gvegidy opened 5 years ago

gvegidy commented 5 years ago

Currently there is no commandline utility that I know of that

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

gvegidy commented 5 years ago

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

zackw commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 5 months ago

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.)