[Toybox] patch: add built-in versions of sha-2 family hash functions

[enh]

On Tue, Jun 8, 2021 at 11:54 PM Rob Landley <rob at landley.net> wrote:

> On 6/7/21 11:14 AM, enh wrote:
> > On Fri, Jun 4, 2021 at 10:54 PM Rob Landley <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >     I've always been slightly unclear on what getty.c _does_ and why
> it's separate
> >     from login.c. (Is it related to stty?)
> >
> >
> > in case i never sent the response to the list, TL;DR "yeah"...
> >
> > [i'm told that] if you're using real serial ports, you still need the
> baud rate
> > setting features. if you're using real serial cables in an electrically
> noisy
> > environment, you have another local getty patch that i honestly haven't
> > understood well enough to even try to work out whether it makes any
> sense to
> > upstream :-(
>
> I fairly regularly use stty with actual serial ports, so I'm familiar with
> that
> part. That's why I brought up "maybe this still useful bit is related"...
>
> The local getty patch is probably reading and ignoring data that comes in
> immediately after bringing the serial port up and changing the speed?


i didn't entirely follow, but aiui it was something to do with a
bios/bootloader that would suspend boot if it saw control characters, so
the hack was basically "you can't have control characters in your
username/password, so just ignore them until you've logged in".


> (Because
> you can get a little static when the hardware powers on, and especially
> when you
> plug/unplug actual serial cables. A common hack back in the day was to
> wait for
> DTR to assert and just drop data that comes in when it isn't.)
>
> What I don't understand is why it isn't stty+login. Or if you're going to
> build
> this functionality _into_ something, why it isn't directly in login? A
> glue tool
> like getty sending out /etc/issue is just weird.
>

yeah, it seemed like they'd be fine with a merger, but weren't exactly
_excited_ about it because it would mean changing something that already
works --- this is the kind of progress that helps the _next_ generation of
users, not the existing users :-)


> Long long ago modems dialed in at various rates and actually set the
> serial port
> to the rate of each call rather than keeping it fixed at the highest
> supported
> one and buffering the data. (Which is odd when you have cts/rts and such?
> It has
> to buffer anyway? But they wanted cheap...)
>
> But I had a 1200 baud modem on the commodore 64 that kept the serial
> connection
> at 1200bps when connecting at 300. (In part because it had no way to
> signal the
> C64 what speed it the other end had connected at.)
>
> By the time v.42bis was adopted in 1990
> (https://ieeexplore.ieee.org/document/403565) you HAD to set the serial
> port to
> a fixed rate faster than the hardware could actually GO (data
> compression!) and
> keep it there, and then the modem would buffer and handle the flow control
> for
> the actual data going through. (And before the ccitt standards the Hayes
> HST
> modems were doing something similar with a different wire protocol.) And
> this
> was backwards compatible all the way back to 300 baud (the new modems
> spoke the
> old protocols, but in the buffered way), so you haven't NEEDed what getty
> does
> even for "modem-over-actual-land-phone-line" for 31 years now?
>
> > aiui they were sometimes seeing XOFF sent to init, causing boot to hang.
>
> I always disable xon/xoff flow control. In-band signaling for flow control
> is
> just sad. (The Joe editor on SunOS had to handle the fact that "ctrl-K
> Ctrl-S"
> to save a cut and paste buffer was a common wordstar key binding, but
> Ctrl-S
> stopped terminal output until it got a Ctrl-Q. Wordstar originated on CP/M
> and
> took over the DOS world until Windows monopoly leveraged it out, and Unix
> wanted
> to keep the ASR-33 teletype happy because it was durable enough and simple
> enough to take apart and clean/oil to be available cheap secondhand...)
>
> The Apple II and Vic 20 had builtin keyboards and video display output,
> and IBM
> did an Ascii keyboard on a mass produced machine capable of running unix
> (hence
> xenix) in 1981 and had finalized the layout by the PC/AT in 1984. The
> Stanford
> University Network boxes that Sun commercialized had keyboards and
> displays. All
> the AIX hardware did too. x11 standardized GUI plumbing in 1987 (which
> made the
> NeWS guys with their competing postcript-based implementation sad; they
> went on
> to create Java at Sun,
> http://www.blinkenlights.com/classiccmp/javaorigin.html).
>
> I look askance at the continued default deployment any technology that
> last had
> good reason to exist before the birth of a sitting US senator.
>
> > (although i understand that XOFF/XON is useful in theory, i've been
> disabling it
> > since the early 1990s because i've haven't deliberately used it since
> the early
> > 1980s when computers were still slow enough for human reaction times to
> be
> > somewhat meaningful there.)
>
> In theory this is what  the "scroll lock" key was for on the 1981 IBM PC
> keyboard. In practice text output by programs running locally scrolled by
> too
> fast for it to matter, and third party modem control programs didn't
> reliably
> wire it up to rts/cts. (Because it didn't start with an LED so you
> couldn't tell
> when it was pressed, and leaving scroll lock on and then calling tech
> support
> because you got no output was most cost effectively fixed by disabling
> scroll
> lock support.)
>
> >     It'd be great if somebody could tackle stdbuf,...
> > (i thought we'd already argued that this means you'll have the
> glibc-provided
> > binary if you're using glibc, which means this doesn't make sense for
> toybox?)
>
> Good point. It was added to the roadmap at the request of the tizen people
> ages
> ago, but I'm happy to yank it out again now that I know more about it.
>
> I have no idea what the status of Tizen is, I hear conflicting things:
>
>
> https://www.theverge.com/2021/5/18/22440483/samsung-smartwatch-google-wearos-tizen-watch
>
> https://www.engadget.com/samsung-tizen-smart-tvs-195125512.html
>
> >
> http://lists.landley.net/pipermail/toybox-landley.net/2020-December/012158.html
> >
> >     Rich Felker said he had a simple way to do it, but we've never sat
> down to have
> >     him explain it to me.
> >
> >
> > (i'd be curious to hear that, because every implementation i'm aware of
> -- and
> > the Unicode standard --literally end up with a huge table *and*
> hard-coded
> > special cases in the code. the closest i've come to "clever" with this
> was to
> > hoist the hard-coded special cases out and have a separate "easy case"
> copy of
> > the loop. but that's only a run-time "simplification", and makes the
> > implementation strictly larger.)
> >
> > but more than that, i'd still like to hear an argument that trying to be
> clever
> > here makes any _sense_ :-)
>
> I did cc: Rich on the email. :)
>
> > i'd ask for a single real-world example where someone's actually using
> this, but
> > since BSD and GNU and Plan 9 trs don't, that doesn't exist.
> >
> > (and this ignores the question of "sure, but aren't we going to harm more
> > ASCII-only 'kernel build' users by accidentally taking their locale into
> account
> > than we are going to help imaginary Turkish AT&T lawyers still using the
> Unix
> > command line for writing their patent applications in 2021", to which
> i'm pretty
> > sure the answer is "yes, the only net result of implementing this would
> be that
> > we'd need to tell a bunch of people to set their locale to "C" for their
> > builds...".)
> >
> > fwiw, getting back to something you said earlier, i think *this* is
> where one
> > true awk "doesn't support utf-8" --- "convert Turkish input to
> upper/lowercase"
> > _ought_ to be something that awk can do that tr can't (because tr is all
> about
> > characters/bytes, but awk is all about strings), but one true awk can't
> do it
> > either. perl and python can. realistically i think anyone who falls into
> the
> > "no, i really do want to deal with all the weirdness of human scripts
> [in the
> > Cyrillic/Hangeul sense of the word]" category (a) should use and (b) is
> already
> > using python anyway. even the kernel and toybox use perl or C where awk
> would
> > do. "it's POSIX", sure, but "no-one who wasn't doing this kind of thing
> in the
> > 1990s has ever used it, and those of us who were don't want to write
> things that
> > only we can maintain".
>
> I basically want to hear Rich's idea for utf8 support in tr before doing
> the
> non-utf8 one.
>
> > your non-POSIX cut(1) extension covers 80% of the in-the-wild use of awk
> anyway
> > :-) if you still talk to any of the busybox folks, we should suggest
> they copy
> > that
>
> I hath poked. If they dowanna but would be interested in merging an
> external
> contribution, I can probably whip up a patch...
>
> > --- it would be nice for it to be a de facto standard so we can get it
> into
> > POSIX sometime around the 2040s... (and have made lives better for the
> folks who
> > don't care about standards and just want to "get things done" in the
> intervening
> > decades!)
>
> Indeed.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210609/27d6e76b/attachment-0001.htm>