`mitchellh/copystructure`, `mitchellh/mapstructure` and `mitchellh/reflectwalk` are now archived and not anymore maintained, what to do with that?

[mathieu-benoit]

mitchellh/copystructure, mitchellh/mapstructure and mitchellh/reflectwalk are now archived and not anymore maintained, what do with that?

Should we use other libraries for that to avoid any CVEs coming from these dependencies? Don't want to overthink but just trying to understand the risks and options here if someone can shed some lights?

[Abhishek9639]

Greetings @mathieu-benoit,

I’d like to work on this issue. I have gone through the details and understand the concern regarding archived dependencies and possible approaches to handle them.

Could you please assign this issue to me?
Thanks!

[mathieu-benoit]

Hi @Abhishek9639, sure thing, thanks!

The recommendation would be, before implementing anything, to make sure options and alternatives are discussed here on the issue or in the #score-dev channel in the CNCF Slack. Thanks!

[Abhishek9639]

Thanks for the suggestion. I’ll discuss the options here (or in the Slack channel) before proceeding with the implementation.

[Abhishek9639]

Hi @mathieu-benoit,
I spent some time looking into this and wanted to share what I found before jumping into any code.

So I ran go mod graph and checked where these three libraries are actually used:

• mitchellh/mapstructure - This is the only one that's a direct dependency. It's used in internal/provisioners/templateprov/template.go where we call mapstructure.Decode() to decode template output. The good news is that go-viper/mapstructure/v2 exists as a maintained fork and it's basically a drop-in replacement (same API, just different import path). We actually already pull it in as an indirect dep through compose-go/v2.

• mitchellh/copystructure and mitchellh/reflectwalk - These are both indirect dependencies. They come in through Masterminds/sprig/v3 (sprig uses copystructure, which in turn uses reflectwalk). Since we don't import either of them directly in our code, we can't really remove them without either replacing sprig itself or waiting for sprig to drop them upstream.

One thing worth noting score-go also depends on mitchellh/mapstructure, so even if we swap it out here in score-compose, it'll still come in as a transitive dep through score-go until that gets updated too.

Here's what I'm thinking for an approach:

1. Start by replacing mitchellh/mapstructure with go-viper/mapstructure/v2 in score-compose. This is a small, low-risk change.
2. Open a separate issue on score-go for the same migration.
3. For copystructure/reflectwalk, we could look into replacing sprig with something like go-sprout/sprout down the line, but that's a bigger conversation.

Does this sound reasonable? Happy to go a different direction if you have something else in mind.
Thanks

[mathieu-benoit]

Super insightful information, much appreciated, @Abhishek9639!

About the move to go-viper/mapstructure/v2, this seems to indeed be the recommendation: mitchellh/mapstructure#349.

Based on all what you described, here is the proposal:

1. Open a PR in score-go to move from mitchellh/mapstructure to go-viper/mapstructure/v2 --> we'll double-check everything in there --> chore(deps): replace mitchellh/mapstructure with go-viper/mapstructure/v2 score-go#176
2. Once this PR in score-go is merged and released, let's integrate it in score-implementation-sample and do the same move from mitchellh/mapstructure to go-viper/mapstructure/v2: https://github.com/score-spec/score-implementation-sample/tree/main --> build(deps): Bump github.com/score-spec/score-go from 1.12.1 to 1.13.0 in the ci group score-implementation-sample#88
3. Once these above are validated, let's integrate it in score-compose and do the same move from mitchellh/mapstructure to go-viper/mapstructure/v2 --> chore(deps): replace mitchellh/mapstructure with go-viper/mapstructure/v2 #450
4. Bump github.com/score-spec/score-go from 1.12.1 to 1.13.0 in the ci group score-helm#34
5. chore(deps): replace mitchellh/mapstructure with go-viper/mapstructure/v2 score-radius#59
6. chore(deps): replace mitchellh/mapstructure with go-viper/mapstructure/v2 score-k8s#280

After that, for the rest, let's regroup and see what are the options. For example, for Masterminds/sprig, we can see this associated open issue there: Masterminds/sprig#456.

Thanks!

CC: @chris-stephenson @astromechza in case you have any comment here.

[Abhishek9639]

Thanks for the clear plan, @mathieu-benoit. I'll start with the score-go PR first and work through the steps from there. Will open it soon.

[Abhishek9639]

Hi @mathieu-benoit,
Just a heads up. I've opened the PR for step 1 over in the score-go repo: score-spec/score-go#176.
Thanks