4 ms·

> I’ve used it in lots of FLOSS projects, but the risk is lower there. How is the risk lower? It's basically an RCE vuln which can poison open source artifacts

• kuschku 5y ago
  If configured well, you run it in a CI stage that has no access to secrets whatsoever. All it can do is leak your source code. Which is an issue for closed source projects, but not open source ones.
  • g_p 5y ago
    Surely the "simple" fix for this is that Codecov runs (for public projects) by pulling the source from the public repo, like anyone else can, and gets a scoped "token" to post back a comment on the Github/Gitlab API. That way, Codecov doesn't get privileged access. I could almost see this work in private repos, albeit with an authenticated fetch token - I'm sure I've used a "deploy-only" key before with both GH and GL to do an authenticated pull. The repo would then be processed, and a response posted via commenting API. Am I missing something here in why it's necessary to involve Codecov in your build/CI stage itself? Is it truly doing dynamic analysis, or is this some (in)convenience factor that could be eliminated? It just strikes me this could sit entirely on the side, without access to anything (beyond the source itself). For enterprise, you could spin up an on-prem instance, and give it the API tokens for authenticated pulls etc.