RandomAlphaString fix for 32-bit

[abe-winter]

In 32-bit builds, RandomAlphaString can crash with 'index out of range'

Note: golang won't let you compile a simple array[-1] because it knows negative numbers shouldn't be array indices, but this sample will repro if you want to see the failure:

package main
import "math"
import "math/big"
import "crypto/rand"
func main() {
	arr := []int{1,2,3}
	for i := 0; i < 20; i++ {
		val, _ := rand.Int(rand.Reader, big.NewInt(math.MaxInt64))
		index := int(val.Int64()) % len(arr)
		println("index", index, "val", arr[index])
	}
}

Then

GOARCH=386 go build main.go && main

(if you're on M1 mac, do GOARCH=arm)

[dgottlieb]

I appreciate the very local fix. I'm not sure I grok what a 32-bit build has to do with int(bigInt.Int64()) -> a negative number. I'm curious if we know whether we're:

• Working around a golang bug or
• We mis-read/neglected reading the golang documentation describing this behavior of big.Int

So as a devil's advocate to the fix here, I feel the complexity of maintaining this is the use of a cryptographically secure number generator. Which goes through this bigint stuff.

I don't think we need cryptographic secure number generation here. There's no (documented) production use of the function in rdk/app/goutils. And if we do need cryptographic generation, we shouldn't expose some string-ifying function for it and let users dictate how long the output should be.

Can we instead just do:

alphas = fmt.Sprintf("%s%s", alphaLowers, strings.ToUpper(alphaLowers))

...
idx := math/rand.Intn(len(alphas))
val := alphas[idx]

?

[abe-winter]

int(random_positive_64_bit_number) on a 32-bit platform can be negative from truncation I think

[dgottlieb]

Oh I see now. The reproducer is much more clear about what's going on than this code. Thanks for adding that to the PR description!

If my above suggestion is too much code slinging for a "just fix it" issue can we just change:

	maxIntBig       = big.NewInt(math.MaxInt64)

to MaxInt32 instead?

The 64-bit numbers here are just to make the selection "as uniform as possible". 32-bit is perfectly fine to be effectively uniform selection.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ abe-winter
❌ Abe Winter

---

Abe Winter seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

For security reasons, this PR must be labeled with safe to test in order for tests to run.

[benjirewis]

Thanks!