add MVN_REPO_URL envvar as an alternative repository manager to download the jar from

[Macadoshis]

Issue #18

[tjarrettveracode]

@523 , can you take a peek at this change to make sure you don't have concerns about the suggested implementation?

[julz0815]

This change would open this action to pull-in and run whatever is behind the configured repo URL. This most probably is posing a big security risk, specifically talking about on-prem GitHub installations.

[Macadoshis]

@julz0815

This change would open this action to pull-in and run whatever is behind the configured repo URL. This most probably is posing a big security risk, specifically talking about on-prem GitHub installations.

I agree. But what about said on-prem GH installations having no access to maven.apache.org at all ? You're then only releasing your GH action from this security issue, to your consumer having no other way to have it work than forking your repo and hard-coding their own repo instead of repo1.maven.apache.org.

Btw, said security issue is the responsibility of the consumer, not veracode nor your stateless GH action. I can add a bold-style disclaimer in the README to point this nowarranty if you want.

Also, even though an on-prem MVN repository would be pointing to a corrupted vosp-api-wrappers-java.jar wrapper (if I'm understanding correctly that's where the security issue lies), it will fail when calling veracode http endpoints, and at worst cause credentials theft of the client tokens, but again that's the responsibility of your consumer not yours. A disclaimer in the README on the usage of a different MVN_REPO_URL would discharge you from any further complaint.

Just my 2 cents, but please avoid your consumers having to fork just for this very minor and common-sense (see mvn-wrapper project) feature.