[BUG] Getting error "plaintext_len: substring expression < 0" on MacOS

[rbetjes]

Before you open an issue please check which version you are running and whether it is the latest in stable / dev branch

I am running version commit 388f3a3 but I also tested with tag V3.2.0

Before you open an issue please whether this is a known problem by searching the issues

Couldn't find anything

Command line / docker command to reproduce

./testssl.sh -f google.com

Expected behavior

I would expect to not see the error "./testssl.sh: line 14257: plaintext_len: substring expression < 0"

Your system (please complete the following information):

• OS: MacOS Sonoma 14.6.1
• Platform: Darwin 23.6.0 x86_64
• OpenSSL + bash: Using OpenSSL 1.0.2-bad (Sep 3 2022) [~183 ciphers]

Additional context

The Bash version in MacOS does not support negative substring lengths.
I've already created a very simple fix for this, could create a PR.

[drwetter]

Hi @rbetjes,

thanks for filing the issue!

It is kind of strange as the CI run should cover that (macos-14) and I did not spot that on MacOS either. Bot are silicon architectures though. What bash version do you have?

What would be your fix?

[rbetjes]

Hi Dirk,

my (apple provided) bash version is: GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin23)

I replaced (amongst others) in line 14257 ${plaintext:0:plaintext_len} with ${plaintext:0:${#plaintext}-plaintext_len}. But now that I look at it, that is not correct.
However, the problem occurs when plaintext_len is negative (it's then -2) and that would only happen if plaintext is an empty string, wouldn't it?
So, I guess testing for an empty plaintext would solve it.
Is it even possible that sym-decrypt returns an empty string without the exit code being other than 0?

[drwetter]

Hi @rbetjes ,

ok. Need to look at it.... The bash version is the same (here: GNU bash, version 3.2.57(1)-release (arm64-apple-darwin24)

Q: ist that reproducible in your end? I just have another strange error here: https://github.com/testssl/testssl.sh/actions/runs/15162061607/job/42630305795?pr=2782 which is not reproducible and is kind of difficult then to fix.

[rbetjes]

Nope, just ran prove -v t/10_baseline_ipv4_http.t and it returned "All tests successful.".

[drwetter]

😃 Yeah, I figured that on my Mac already. Sorry, my question was more related on your issue.

[rbetjes]

Ow, actually I tested it with my patched version (sorry). If I revert to the original code test 10_baseline_ipv4_http.t fails. So, yeah I can reproduce that one and it seems to be related.
The error I get is the same as in my issue, but I don't see it in the automated test output following your link.

This is what I see (truncated):

#  Elliptic curves offered:     prime256v1 X25519 
# ./testssl.sh: line 14257: plaintext_len: substring expression < 0
# ./testssl.sh: line 14257: plaintext_len: substring expression < 0
#  TLS 1.2 sig_algs offered:    RSA-PSS-RSAE+SHA256 RSA+SHA256 

I guess the "PoC unit test on MacOS" only shows stdout and not stderr?

[drwetter]

I guess the "PoC unit test on MacOS" only shows stdout and not stderr?

Depends. Most of the runs redirect 2 to 1 , see t/10_baseline_ipv4_http.t.

So you can reproduce it, I can´t and it seems the mac runner cannot either...

Maybe you can debug that. Get back to that later,

[rbetjes]

Sure, I'll look into it.

[rbetjes]

Depends. Most of the runs redirect 2 to 1 , see t/10_baseline_ipv4_http.t.

The runs themselves redirect individually yes, but I think you also need to redirect the main invocation.
You could try to change the runner workflow from
prove -v t
to
prove -v t 2>&1

That way you should see the errors in the output. At least it does when I invoke it manually.

[drwetter]

That way you should see the errors in the output

That is correct -- when perl writes to stderr or on the shell level is no redir.

[drwetter]

Sure, I'll look into it

maybe you could put a set -x a few lines before that happens and a set +x a few lines later.

PS: For the testing there are cases where the redirect doesn't happen. That needs to be fixed. But that should happen on the shell level. If you like : PRs are open ;-)