Bump go-libp2p#586
Conversation
because otherwise, security scanners complain about this: https://osv.dev/vulnerability/GO-2024-3302 Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
|
Security scanners can be silenced if they produce nonsensical results. And if they can't, they're worthless and should not be taken seriously in the first place. |
Correct. But what makes you say it's a nonsensical result in this case? Actually, you were the one to provide the fix: is it not needed? |
|
We're going in circles: #585 (comment). |
"the idea is not to force any particular version" How exactly is go-libp2p-pubsub doing this? . The way go dependencies work, this line here makes sure a specific version is being used: Line 10 in c06df2f |
|
It is NOT necessary to bump dependencies in every single library that is only ever used transitively (like go-libp2p-pubsub, which is only used in conjunction with go-libp2p). Same reason we don't update to the quic-go release in masque-go or webtransport-go: Applications can just update their dependencies. This is the place where security scanners make sense. I'm going to disengage from this discussion now, and I'll leave it to @vyzo to deal with PR. |
|
You got me reading docs :D (which is a good thing). I guess it's misunderstanding on my side on what go.sum entries mean. Probably the security scan tool makes the same mistake. Feel free to ignore and close this PR. |
|
Nope, the scan is technically correct. If you were running go-libp2p-pubsub as a standalone program (which you don't, it's a library!), then you'd include a vulnerable quic-go version. Since go-libp2p-pubsub is always used with go-libp2p, it doesn't really matter if go-libp2p-pubsub specifies an old version, since the version defined by go-libp2p is used. |
2 participants
because otherwise, security scanners complain about this:
https://osv.dev/vulnerability/GO-2024-3302
Replaces this PR as per the comment