Restore previous handling of long passwords #1295
Conversation
silvestre
added
the
allow-acceptance-tests
Configured passwords for the servicebroker and the healthendpoints were previously silently truncated to the first 72 bytes [1]. This change restores the truncation to the first 72 bytes, but adds an error level warning (as `lager` does not have a dedicated warning level), documenting this truncation, so previously configured passwords longer than 72 bytes will continue to work unchanged. Prior to this PR, passwords longer than 72 bytes would cause an error. [1]: golang/go#36546
silvestre
force-pushed
the
fix-password-restriction
branch
from
aabf9f6
to
5e630ad
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
I understand the purpose of adding the warning, but I don't understand why this PR also bumps the deployment's password to a length greater than this. It means that anyone trying to extract the generated password from the bosh vars store has to know about this and truncate similarly before using it. |
It just restores the previous settings. I'm not sure in what scenario someone extracting the password would have to truncate it themself? |
|
(forgive me, I'm having to refresh myself on something 4 months back..) But this change only performs auto-truncation on the submitted user/pass in the healthcheck endpoints. For the brokerserver, for instance, the warning and truncation is performed on the configured user/pass, but the submitted user/pass is just pulled directly from |
|
I see, but this is exactly the reason why the deployments password was bumped up to full length, so that our tests would catch any such issue. They are passing because I suppose this implicit truncation could be made explicit to prevent confusion. |
Configured passwords for the servicebroker and the healthendpoints were
previously (before #1249) silently truncated to the first 72 bytes.
This change restores the truncation to the first 72 bytes, but adds an
error level warning (as
lagerdoes not have a dedicated warninglevel), documenting this truncation, so previously configured passwords
longer than 72 bytes will continue to work unchanged.
Prior to this PR, since #1249, passwords longer than 72 bytes would cause an error.