Update bketelsen/crypt to fix CVE-2020-15114.

[dlorenc]

This picks up bketelsen/crypt#10. It doesn't look like they've done
a new tag yet, so going to the latest commit (as of 17DEC2020) is about all we can do.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

👋 Thanks for contributing to Viper! You are awesome! 🎉

A maintainer will take a look at your pull request shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

[dlorenc]

I see a few other PRs that also try to address this:

#964
#957

Let me know if there's anything else I can do to help here - this update will allow all the importers of spf13/viper to update and remove the deprecated/vulnerable jwt-go library.

[sagikazarmark]

As mentioned in #961 we are waiting for etcd 3.5 to be tagged for proper modules support.

[dlorenc]

Thanks for the reply!

Just to add some context, keeping this at the older version causes any other repo that uses viper to be flagged by vulnerability scanners as having the jwt-go CVE.

[sagikazarmark]

Yeah, I'm aware. That's actually a false alert, because it's not actually compiled in the final binary.

As far as I know 3.5 is pretty close and it'll improve modules support. Unfortunately, the currently it's not that good (and became somewhat worse with the last version)

[dlorenc]

Yeah, I'm aware. That's actually a false alert, because it's not actually compiled in the final binary.

Understood. I think it still could be problematic in things further up the dependency hierarchy that do use that codepath and viper at the same time, though.

As far as I know 3.5 is pretty close and it'll improve modules support. Unfortunately, the currently it's not that good (and became somewhat worse with the last version)

I'm not sure what the etcd relation is here. I'm sure I'm misunderstanding something though. This PR was simply the result of updating the crypt library then running "go mod tidy". Is there a downside to merging early updates like these rather than waiting?

I'm trying to stay in the habit of keeping my projects at zero flagged CVEs, even for false positives like this one. I figure it'll be easier to notice a real one when it happens if I'm at 0, rather than if I have a bunch of false positives to wade through.

[sagikazarmark]

I'm not sure what the etcd relation is here

It's twofold:

• The jwt library is a dependency because of etcd
• The particular etcd version pulled in by crypt is a bit problematic from modules point of view. At least in my tests, go getting Viper didn't always work. (A bit of backstory: etcd was moved to a new organization and go modules was added, but not as a new major version which caused a whole lot of trouble

I'm trying to stay in the habit of keeping my projects at zero flagged CVEs, even for false positives like this one.

Agreed. The reason I was holding this back is the one I explained above. I'll look into it again to see if things are better now, but I think without etcd 3.5 modules will not work perfectly.

github.com/bketelsen/crypt v0.0.4-0.20201105235121-f295231a095e

This is also not going to fly: it's not a tagged version.