Runner: 2.165.1 runner over mask log when using secrets with JSON/newline

[TingluoHuang]

Describe the bug
Log get over masked when using JSON with newline as secret

To Reproduce
Steps to reproduce the behavior:

1. add a secret variable (has new line):

TestJson=
{
}

1. Run a workflow which echo ${{secrets.TestJson}}
2. all e and f in the log get masked, which causes the log un-readable.

Expected behavior
A clear and concise description of what you expected to happen.

Runner Version and Platform

2.165.1

What's not working?

https://github.com/actions/canary/runs/439952952?check_suite_focus=true

[TingluoHuang]

for context, base64 result:

{ => ew==
} => fQ==

[TingluoHuang]

i think the problem is for secret with single char. (we break the multline json into multiple secret, so you get { and } as secrets)
ex: you have secrets => a
this will cause all the a in your log get masked.
however with the base64trim masker we newly added, in addition to a, all Y will also get masked since base64(a)=>YQ==.

I think the easiest fix would be if the len(secret)==1, then the new base64trim masker just no-op.

[thboop]

i think the problem is for secret with single char. (we break the multline json into multiple secret, so you get { and } as secrets)
ex: you have secrets => a
this will cause all the a in your log get masked.
however with the base64trim masker we newly added, in addition to a, all Y will also get masked since base64(a)=>YQ==.

I think the easiest fix would be if the len(secret)==1, then the new base64trim masker just no-op.

We can roll that as a temporary fix.

I don't think that's the only solution here, we shouldn't be registering { as a secret to begin with. { is going to be masked in all secret logs as well and I don't think that is desired behavior. Should we not register secrets < x length in the multiline scenarios to avoid registering {, } , [, ] for json users?