update go version to 1.20.x

[galargh]

Description

This PR upgrades go to 1.20.x. It also introduces automated migration rule for deprecated packages - see math/rand in https://tip.golang.org/doc/go1.20.

My proposal for the automated migration is as follows:

# 1. replace rand.Seed(*) with rand := rand.New(rand.NewSource(*))
#     if math/rand is imported
# 2. replace math/rand import with crypto/rand import
#     if crypto/rand is not imported yet and only Read from rand is called
# 3. add crypto/rand import as crand and replace rand.Read with crand.Read
#     if crypto/rand is not imported yet and methods other than Read from rand are called too

@marten-seemann WDYT? If you're okay with this migration, we can proceed with the release on 2023-02-08.

Testing

Before Merge

• deploy to https://github.com/protocol/.github-test-target

After Merge

• deploy to https://github.com/libp2p/go-libp2p-xor
• deploy to https://github.com/libp2p/go-libp2p-pubsub (won't work with https://github.com/libp2p/go-libp2p-pubsub/blob/973fef56e1e6fd6afc568ea3c1c2f654f7754d49/backoff.go#L46, CI should fail)

[marten-seemann]

I don't think this works. Consider the following code:

func NewStruct() *MyStruct {
     rand.Seed(1337)
     return &MyStruct{}
}

func (m *MyStruct() RandomNumber() int {
     return rand.Int()
}

[galargh]

@marten-seemann Yes, that's right. It's the case here for example: https://github.com/libp2p/go-libp2p-pubsub/blob/973fef56e1e6fd6afc568ea3c1c2f654f7754d49/backoff.go#L46 (from description; edit I just noticed uCI is not configured for it).

There, I'd expect the CI to fail and the PR to require manual intervention.

My assumption is that it's not the case in most of our packages and that this would work for the majority of the cases. I'm not aiming at 100% success rate. But that's exactly why I wanted your input on this because you definitely have a better view of the land.

One more thing I wanted to change was to replace rand.Seed with r := rand.Seed rather than rand := rand.Seed because the latter might actually hide some errors.

[galargh]

The alternative would be to do nothing which could be a fine starting point. We can see in practice how many repos are affected.

[galargh]

Let me try to retrieve how many might be caught in this.

[galargh]

Using seed (12):

[
  "filecoin-project/go-address",
  "filecoin-project/go-data-segment",
  "ipfs/go-ds-flatfs",
  "ipfs/go-ipfs-util",
  "ipfs/go-mfs",
  "ipld/go-storethehash",
  "ipni/go-indexer-core",
  "libp2p/go-libp2p",
  "libp2p/go-libp2p-testing",
  "libp2p/go-yamux",
  "libp2p/hydra-booster",
  "multiformats/go-multiaddr"
]

Using read but not crypto (29):

[
  "filecoin-project/go-address",
  "filecoin-project/go-data-segment",
  "filecoin-project/go-hamt-ipld",
  "ipfs/go-cid",
  "ipfs/go-cidutil",
  "ipfs/go-datastore",
  "ipfs/go-ds-badger",
  "ipfs/go-ds-badger2",
  "ipfs/go-ds-badger3",
  "ipfs/go-filestore",
  "ipfs/go-graphsync",
  "ipfs/go-ipfs-chunker",
  "ipfs/go-ipfs-cmds",
  "ipfs/go-ipfs-util",
  "ipfs/go-libipfs",
  "ipfs/go-merkledag",
  "ipfs/go-mfs",
  "ipfs/go-unixfs",
  "ipld/go-car",
  "ipld/go-ipld-prime",
  "ipld/go-storethehash",
  "libp2p/go-libp2p",
  "libp2p/go-libp2p-gorpc",
  "libp2p/go-libp2p-xor",
  "libp2p/go-mplex",
  "libp2p/go-msgio",
  "multiformats/go-base32",
  "multiformats/go-multiaddr",
  "multiformats/go-multibase"
]

[marten-seemann]

The alternative would be to do nothing which could be a fine starting point. We can see in practice how many repos are affected.

That would be my preference. The worst thing that'll happen is a slight performance hit, isn't it?

[marten-seemann]

Using seed (12):

[
  "filecoin-project/go-address",
  "filecoin-project/go-data-segment",
  "ipfs/go-ds-flatfs",
  "ipfs/go-ipfs-util",
  "ipfs/go-mfs",
  "ipld/go-storethehash",
  "ipni/go-indexer-core",
  "libp2p/go-libp2p",
  "libp2p/go-libp2p-testing",
  "libp2p/go-yamux",
  "libp2p/hydra-booster",
  "multiformats/go-multiaddr"
]

Using read but not crypto (29):

[
  "filecoin-project/go-address",
  "filecoin-project/go-data-segment",
  "filecoin-project/go-hamt-ipld",
  "ipfs/go-cid",
  "ipfs/go-cidutil",
  "ipfs/go-datastore",
  "ipfs/go-ds-badger",
  "ipfs/go-ds-badger2",
  "ipfs/go-ds-badger3",
  "ipfs/go-filestore",
  "ipfs/go-graphsync",
  "ipfs/go-ipfs-chunker",
  "ipfs/go-ipfs-cmds",
  "ipfs/go-ipfs-util",
  "ipfs/go-libipfs",
  "ipfs/go-merkledag",
  "ipfs/go-mfs",
  "ipfs/go-unixfs",
  "ipld/go-car",
  "ipld/go-ipld-prime",
  "ipld/go-storethehash",
  "libp2p/go-libp2p",
  "libp2p/go-libp2p-gorpc",
  "libp2p/go-libp2p-xor",
  "libp2p/go-mplex",
  "libp2p/go-msgio",
  "multiformats/go-base32",
  "multiformats/go-multiaddr",
  "multiformats/go-multibase"
]

It would probably make sense to filter out test files here.

[galargh]

The alternative would be to do nothing which could be a fine starting point. We can see in practice how many repos are affected.

That would be my preference. The worst thing that'll happen is a slight performance hit, isn't it?

Given the numbers, how about we automatically change (math/rand).Read to (crypto/rand).Read but we leave rand.Seed as is for the owners to fix?

[marten-seemann]

The alternative would be to do nothing which could be a fine starting point. We can see in practice how many repos are affected.

That would be my preference. The worst thing that'll happen is a slight performance hit, isn't it?

Given the numbers, how about we automatically change (math/rand).Read to (crypto/rand).Read but we leave rand.Seed as is for the owners to fix?

I'd prefer to leave that decision to package maintainers. If I remember correctly, math/rand.Read was significantly faster, and if you're generating large amounts of pseudorandom data (e.g. for tests), this might become relevant.

Since the function is deprecated, it will start showing up in staticcheck when we drop Go 1.19.

[galargh]

OK, I think that's fair enough. Let me revert the automatic fix changes and we'll proceed with the release today :)