On Thu, Jun 26, 2014 at 07:18:31AM -0500, Rob Landley wrote: > On 06/26/14 00:20, Isaac Dunham wrote: > > On Wed, Jun 25, 2014 at 11:02:03PM -0500, Rob Landley wrote: > >> We don't need "-m help" when we can put the list of supported types in > >> the help text itself. (Unless this is used programmatically to > >> autodetect support? The ubuntu version outputs a lot of extra verbiage > >> that would make parsing hard, and the busybox-1.19.0 I have lying around > >> doesn't support -m help at all?) I've yanked it for now, I can put -m > >> help back if anybody's actually using it... > > > > I'd just been looking into bcrypt support, where it theoretically > > could be handy. bcrypt is supported on musl, some patched versions > > of glibc, and a lot of non-linux systems. > > To support it, we can either advertise bcrypt support everywhere and > > fail sometimes or else probe for it. > > Probing would be ideal, except that I'm not sure how you'd probe while > cross-compiling? (I can probe for a function existing, but not for > crypt() accepting an argument value. One's a build break, the other > requires executing code to see what it does.) I was actually referring to a runtime probe (check if it's supported and if if it isn't, act like "bcrypt" is invalid.)
And this is why -m help is relevant: if we do a runtime probe, -m help comes in very handy, since it could be dynamically modified based on what hashes actually work. <snip> > > Following this you need 22 characters of the usual sort for a salt; > > traditionally it's terminated with a '$', but musl at least does not > > require this. > > Patches welcome. I'm unlikely to add that myself but I'm happy to merge > it if other people think it useful. Alright. > Probably not this release though. I'm aiming for mondayish and focusing > on cleanup of what's already in the tree just now... That's fine. Thanks, Isaac _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net