Re: single user machine, one "user" now(?) has no password (I didn't do it). [edited for clarity]

On Fri, Feb 20, 2026 at 07:28:46PM -0800, Samuel wrote:
> sha256 hash (file ends with newline):
> SHA256 (pwgenerator) =
> 740470dc3ea3911a19c7165d3439136ff8fb180a7f65ad31c6086a91957b77e4

(unimportant side-note): I couldn't get the code to match this checksum, which
is not surprising given that you've retyped it and probably introduced or
removed whitespace unintentionally.

> #!/bin/ksh
>
> set -e

Do not use 'set -e' here. Or anywhere. Not in this script nor in any other
new script that you write.

> trap 'error=$?; if (($error)); then print -ru2 -- "$0: line $LINENO:
> $error"; fi' ERR

This trap only writes to STDERR. If it's triggered early on, then there will
be no output to STDOUT. Your other script will happily pass that null input
to 'encrypt'.

> if [ -t 1 ]; then
> tput clear || exit 1
> tput cup 0 0 || exit 1
> tput el || exit 1
> fi

Why have you done this in such a complicated way using tput instead of just
calling 'clear'?

What is the point of the final clear to end of line?

In fact, what is the point of homing the cursor? All modern terminals that
you are likely to be running on already home the cursor with the clear
sequence.

What if your system hits some kind of resource limit and cannot spawn tput
here?

That would be an obvious way to cause the situation you described - an empty
password field being created by your other script.

> LENGTH=20
> VARIATION=4
> set -A P
> set -A Q

Why the use of set -A here?

> while :; do
> for i in $(dd if=/dev/random bs=4 count=1 2>/dev/null |
> hexdump -e '/1 "%u\n"')

Do you think that this is guaranteed to print four decimal numbers to stdout,
one per line?

Bad assumption. Test this:

$ echo -n '0000' | hexdump -e '/1 "%u\n"'

Hexdump replaces duplicated lines with '*' by default.

Any idea how your shell script interprets that '*'?

Try this:

$ for i in $(echo '00' | hexdump -e '/1 "%u\n"') ; do echo $i ; done

... and you'll see a directory listing.

So part of your script that expects four lines each with a decimal number on
each line, will instead receive any number of non-numeric entries.

This even potentially _creates an exploit_, because if somebody had write
access to the directory that you're running this script in, they could create
files with numeric filenames and influence the generated password.

Password generator runs as normal, but the output is no longer truely random.

At this point, we can clearly see that this script is fundamentally broken,
and I don't see any point in further analysing it.

I suspect that this was either written by an LLM, or you have been studying
some very ancient books about UNIX-like systems.

Either way, not a good approach.

My instinct tells me that something in this script triggered the error handler
which passed a null input to 'encrypt', and due to the lack of error checking
in your other script allowed an empty password field to be written to the
password file.

BUT, and this is probably the most important part - don't be discouraged from
learning about shell programming or whatever you were trying to do. We learn
by making mistakes.

If you have any more questions feel free to ask.