With a quick check, I did not see the problem on x86_64 the rpc-server do not shock on password).
I can confirm tis is coming from base64 decoding wrong.
I have applied that simle patch
$this->bbcode_second_pass_code('', '
--- libtransmission/rpc-server.c 2022-02-14 11:47:49.994162577 +0100
+++ libtransmission/rpc-server.c 2022-02-14 11:47:37.225361472 +0100
@@ -669,6 +669,7 @@
}
}
}
+ tr_logAddNamedError(MY_NAME, "Decoded password is: %s\n", pass);
if (server->isPasswordEnabled && (pass == NULL || user == NULL || strcmp(server->username, user) != 0 ||
!tr_ssha1_matches(server->password, pass)))
')
It spits out in your transmission log the password decoded from 'Authenctication' header
And the rpc-server is wrong in tranmission-cli-3.00-3 WHEN there is padding implied in the incoming base64
I mean, the rpc-server does not decode correctly the password in authentication header (which is base64 encoded) and adds an extra '>' when there is padding (either = or ==) in coded base64 header
This explains why RuneArch's password was ok for 14 characters but 13 or 15. because 13 or 15 implies padding
transmission dev have patched libb64 for something like that at a quick lookint the code