On Sun, Dec 18, 2016 at 4:19 PM, Antoine Beaupré <[email protected]> wrote:
> [replying to a bunch of people at once, sorry for the confusion, but i > want to reduce the amount of emails here.] > > On 2016-12-17 20:44:32, Allan Odgaard wrote: > > On 18 Dec 2016, at 6:40, Antoine Beaupré wrote: > > > >>> I like the idea of using /dev/urandom directly, but piping it into > >>> base64 is a terrible idea. > >> > >> […] > >> pwgen -ys, half the time, generates a password i can't copy-paste by > >> simply double-clicking on it (because of symbols like [>;.]). > > > > I’ve also had minor issues with characters like backslash, apostrophe, > > double-quote, and backtick. > > > > As for BSD’s base64, I am on macOS with the man page for base64 > > stating February 8, 2011 (Mac OS X 10.7) and the default is to encode > > input, no required argument. > > Interesting. I was based my conclusions on: > > https://www.freebsd.org/cgi/man.cgi?query=base64 > > OS X may not use the same base64 as FreeBSD? I must admit I don't have a > BSD box on hand to test this anymore... :/ > > I just wanted to point out that your search ( at least the link ) includes ports, which is where base64 is. In FreeBSD base there is b64encode and b64decode which are synonymous with uuencode/uudecode -m Something like the following would work head -c 18 /dev/urandom | b64encode -r - Best regards Andreas > On 2016-12-18 03:10:35, Lenz Weber wrote: > > Please use /dev/urandom for this, not /dev/random. It is an absolutely > > acceptable source of randomness and does not block, which will give a > > better user experience. > > (for better information see this talk: > > https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy ) > > /dev/urandom doesn't seem to exist in OpenBSD, as far as I could tell > when i did my research, but I don't have an OpenBSD box on hand to test > this either. > > /dev/random is unlikely to block for the amount of data we're extracting > from the pool except in extreme circumstances (e.g. you're generating a > password immediately after boot). so i don't think it's harmful to use > /dev/random in this specific case. furthermore, /dev/random and > /dev/urandom are links on *BSD systems that support urandom, from what i > can understand... > > and yes, i watched that talk, thanks. :) > > > try triple-clicking - should work in most consoles ;) > > triple-clicking selects the whole line, so includes a newline which will > break some sites/setups. > > On 2016-12-18 04:41:30, Chris Warrick wrote: > > On 18 December 2016 at 00:40, Antoine Beaupré <[email protected]> > wrote: > >> pwgen has a long history of generating insecure passphrases. up until > >> 2014 (pwgen 2.07, shipped only in Debian jessie, and Ubuntu Vivid) > > > > That was 2 years ago. And if you insist on using outdated distros, how > > secure can your gpg setup be? > > Are you aware of pre-2014, Debian7-specific GnuPG vulnerabilities that > we don't know about? > > Or am I supposed to regenerate all my primary keys every two years > because we're in the future now? > > 2 years may seem like a long time for you, but for me it's very short. I > know it's a controversial topic, but I happen to believe we're not > supposed to rewrite and/or reinstall all our software everything every 2 > years. > > I build software that lasts. > > >> On 2016-12-17 18:08:16, Tobias Girstmair wrote: > >>> I'm against it. IMHO the `pass` philosophy is to utilize UNIX tools > instead of rolling one's own. > >> > >> I believe that "head", "base64" and "tr" are UNIX tools. > > > > You are introducing a dependency on GNU coreutils, though. > > I believe this dependency is already present in different forms > elsewhere in the code. And if you are refering to base64 when you refer > to coreutils, note that OS X's implementation seems to work similarly to > GNU coreutils. I was just being careful in the commit log in that it may > not work on other platforms, but I have (obviously) not been able to > test every base64 implementation out there. > > But you are right, GNU is, litteraly, Not Unix, and deliberately so. I > meant UNIX in the wider "unixen" sense. > > >> It's not like i implemented a password generator in pure bash (which > >> would be $RANDOM, and probably horrible). > >> > >>> `base64` is not compatible with any password rules that require a > special character. > >> > >> actually, it is, often. i have observed that base64 will yield a + or / > >> sign in about one out of 3 generated passwords. > > > > Not nearly enough: > > * some places may dislike + or / > > * some places may insist on having one of a set of characters, and +/ > > may not be part of this set > > * base64 cannot guarantee having a symbol/number/capital letter in output > > * controlling output length of base64 is hard > > as others said: one algorithm can't fit them all, unfortunately. that's > why pwgen had all those knobs, which, i should not here, are not > actually all supported by pass. > > i think you are setting an impossible criterion, that is not attained by > the current implementation: > > 1. pwgen -sy may also include + or / which some places may dislike (-n > would work around that, but then wouldn't have any special character) > > 2. pwgen -sy *may* have the characters some places insist on having, but > there's no garantee of that either > > 3. pwgen -sy cannot garantee having a symbol/number/capital letter in > output either > > 4. it's true that pwgen output length is easier to control than > base64... > > ... but I wouldn't call controling the length of base64 "hard". it's a > simple calculation (+33%) that a lot of people are aware of. > > >> pwgen -ys, half the time, generates a password i can't copy-paste by > >> simply double-clicking on it (because of symbols like [>;.]). you might > >> argue that you're supposed to use -c, but that is optional and there are > >> reasonable use-case where you can't use the clipboard to transport the > >> password. > > > > Nonsense. If you want to copy-paste the password, then just use -c in > > the first place. If you don’t, then there’s nothing to complain about. > > You may not be aware that -c sends the password to the non-default xclip > CLIPBOARD selection, instead of the usual XA_PRIMARY. This makes it > harder to copy-paste in terminals, for examples. > > > Regarding your double-click issues, please send complaints to whoever > > wrote your terminal emulator. > > Somehow I don't think it's productive to open bug reports against xterm > or rxvt because triple-click doesn't do what a password manager expects > it to do. > > But then maybe that's all just me. I don't want to fight y'all for this, > it's just a suggestion, and I see there's a lot of resistance to > changing this, so I'll just move on to other greener fields. > > Anyways, Jason said he didn't like my implementation (specifically that > "using bas64 is a horrible idea") and will work something on his own. So > it's probably pointless to debate this further at this point. > > Have fun. > > A. > > -- > People arbitrarily, or as a matter of taste, assigning numerical values > to non-numerical things. And then they pretend that they haven't just > made the numbers up, which they have. Economics is like astrology in > that sense, except that economics serves to justify the current power > structure, and so it has a lot of fervent believers among the powerful. > - Kim Stanley Robinson, Red Mars > _______________________________________________ > Password-Store mailing list > [email protected] > https://lists.zx2c4.com/mailman/listinfo/password-store >
_______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
