[BUG] Getting error "plaintext_len: substring expression < 0" on MacOS
Closed this issue · 21 comments
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.
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?
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?
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.
Nope, just ran prove -v t/10_baseline_ipv4_http.t and it returned "All tests successful.".
😃 Yeah, I figured that on my Mac already. Sorry, my question was more related on your issue.
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?
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,
Sure, I'll look into it.
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.
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.
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 ;-)
The problem seems to originate in the gcm-decrypt function.
The calls to $OPENSSL2 redirect stderr to /dev/null, but when I remove the redirect I get:
Error configuring OpenSSL
140704609037760:error:26FFF074:engine routines:CRYPTO_internal:no such engine:/AppleInternal/Library/BuildRoots/4ff29661-3588-11ef-9513-e2437461156c/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/engine/eng_list.c:370:id=gost
140704609037760:error:26FFF066:engine routines:CRYPTO_internal:engine configuration error:/AppleInternal/Library/BuildRoots/4ff29661-3588-11ef-9513-e2437461156c/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/engine/eng_cnf.c:197:section=gost_section, name=default_algorithms, value=ALL
140704609037760:error:0EFFF06D:configuration file routines:CRYPTO_internal:module initialization error:/AppleInternal/Library/BuildRoots/4ff29661-3588-11ef-9513-e2437461156c/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/crypto/conf/conf_mod.c:224:module=engines, value=engine_section, retcode=-1
failed to load configuration
But only when the included "OpenSSL 1.0.2-bad (1.0.2k-dev)" openssl version is used.
Manual invocation of openssl like so:
bin/openssl.Darwin.x86_64 enc -aes-128-gcm
returns:
AEAD ciphers not supported by the enc utility
The supplied openssl does not return a calculated value, thus $plaintext in check_tls_serverhellodone is empty and the negative substring length problem occurs.
So, should the openssl config be fixed (and the redirect to /dev/null) or the negative substring length problem?
I would guess, all of the above.
And it turns out $OPENSSL2 points to /usr/bin/openssl which is "LibreSSL 3.3.6" on my system.
I cannot get it to return the "Error configuring OpenSSL" message when I invoke it manually though.
Yup, as expected .
Probably next week it’ll be done
Hi @rbetjes ,
when looking at it more closely I am not sure why this fails. Either it should be slow but working or automatigically switch, see PR #2727 .
Your LibreSSL version supports enc -aes-128-gcm and enc -aes-256-gcm.
Can you help either by debugging more closely and/or proving an example at which site this fails ?
I can reproduce it now by mimicking your setup under Linux, i.e. move /usr/bin/openssl away and instead of that linking /usr/bin/openssl from a freshly compiled LibreSSL 3.3.6 version.
The error above originates from OPENSSL_CONF which is not unset and used by LibreSSL instead of ~/bin/openssl.$(uname -s).$(uname -m)
So the fix is nullify OPENSSL_CONF when $OPENSSL2 is automatically chosen. But I am not 100% happy with the error handling wrt e.g. gcm-decrypt(). PIPESTATUS and/or testing for empty $plaintext would make it more robust.
Seems to work now, see pending PR
Sorry, I've been away a couple of days.
The change seems to work indeed, thank you very much.
Thank you for filing the issue and your persistence 😃