[oelmekki]

I could just pass an option to make pwgen generate longer passwords, really, but I find amusing the idea of generating the hash of 160 urandom level generated passwords :) Now that's random! Oh, and also, it looks like a hashed password, so special troll points if a cracker find the password and think it's its hash.

(note for people who may not know pwgen : it outputs 20 lines of 8 random passwords)

[agwa]

> (note for people who may not know pwgen : it outputs 20 lines of 8 random passwords)

Unfortunately, it only does this if STDOUT is a TTY. If it's a pipe, then it outputs a single 8 character long password. So I'm afraid you've been generating rather low entropy passwords by piping the output of pwgen through md5sum.

You can confirm this by piping pwgen through cat: pwgen | cat

[oelmekki]

Oh, you're right. Thanks for pointing that. Damn, that was an unexpected behavior (although, I can understand how it's helpful, when you want to get a password from a script/program that executes pwgen - but then I guess an option would have been enough).

[lathiat]

i simultaneously love and loathe programs that do this, I long for some kind of shell pipe negotiation.

Most annoying trying to use "watch" or "less" and have the color work. "watch --color juju status --color", ahh. :-)

[agwa]

Having used isatty in some of my CLI programs to alter the behavior depending on whether STDOUT is a TTY, I see the appeal. It allows the program to do the best thing depending on how it's being invoked.

However, more recently I've grown skeptical. It leads to surprises, and if a person isn't familiar with the finer details of file descriptors, they may wonder why piping a program changes its behavior. I think this example of someone shooting himself in the foot with pwgen has convinced me never to do this again.

[oelmekki]

Yeah, that's a hard one. Of course, there are strong arguments for "sensible defaults". But here is how it went :

First, I used pwgen to generate temporary passwords for new unix users. I read the man page at that time, probably saw the mention about different behavior regarding output capabilities and thought : "nevermind, this is not my use case". Years later, when I decided to pipe it, I thought I already knew the program, and certainly not thought : "hey, let's check the man page again to see if the behavior may be altered on a pipe". Especially since I did not think it was a big deal, I was not putting that in a codebase, I just wanted to generate a random password to upload gifs or something.

And that's the interesting thing : should I have wanted to put it in a codebase, I would have read the man page again carefully.

All of this points to one conclusion : consistent defaults for end users are more important than sensible defaults for developers. You can expect developers to pay special attention, so that's ok to alter behavior for them through flags rather than detection of what stdout is plugged in.

[amenghra]

You can use "simpler tools", such as `head -c 20 /dev/urandom | sha1`.

If head behaved differently when piped, you would probably know about that because it's a common thing to do.

[jwives]

md5sum is going to limit your generated passwords to 128-bits because you're limited to 32 hexadecimal digits, which are each represented by 4 bits. [a-z][A-Z][0-9] can be represented by ~6 bits, so 32 characters would allow for 190 bits of entropy.