[FIXED] Make sure to use byte slice to receive proper copy

[derekcollison]

Empty public key was being used.

Huge thanks for the report from @tinou98!

Signed-off-by: Derek Collison derek@nats.io

[coveralls]

Pull Request Test Coverage Report for Build 6598807631

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.4%) to 80.115%

---

Totals
Change from base Build 6225067835:	0.4%
Covered Lines:	419
Relevant Lines:	523

---

💛 - Coveralls

[philpennock]

I don't think this is needed. I think it's fine to apply as a comprehension change, but I think the logic before was correct.

Notably, the prior state was that the input was an array, not a slice, and that the [:] did not force a capacity limit and thus a reallocation.

https://go.dev/play/p/c3N6VcA-L1Q

See that test code, and how using y := x[:] before copying into y also updates x.

So I don't think there's a security issue here. But it's good to be clear, so approving the changes.

[aricart]

LGTM

[philpennock]

Okay, so the actual problem is caused by missing that Go is pass-by-value and when you're passing in an array, you get a copy of the array, so the passing in of the slice over the array results in the called function getting a new slice value over the same array, and being able to modify the caller.

[philpennock]

Please update the title before merge, because "Make sure to use byte slice to receive proper copy" is ... the opposite of true? You're using a byte slice so that you're not getting a copy of the underlaying data and can instead modify the original.

[derekcollison]

The title I believe is correct, we would copy the byte array on the stack, so when we copied it into that copy, it was lost. Using the slice we do get the data correctly when we return.