Only thing I would say is take a look at Hans' comment #7631 (comment) regarding environment variables. Thoughts?

Sigh, looks like I should have reloaded the #7482 browser tab that's been sitting in my tab bar - a constant reminder about this pending item. Hence, I missed that @nhumblot already offered a PR.

Nicolas, how shall we proceed? I had considered your approach but took a different turn on purpose.

...regarding environment variables. Thoughts?

I had considered it, and of course it makes technical sense. However, I am still undecided as to whether the additional complexity is justified. Do we expect people to run mvn -X in their CI environments?

Hi @marcelstoer 👋

Thank you for your proposal. No worries, I can discard my PR so we focus on iterating on yours, I stalled my work on it.

Regarding the mvn -X in a CI - I've done similar temporarily when debugging. I know a guy that has options in the job that turn on verbose debugging in most of the tools used - specifically for when something goes awry. It would not be common or ever run; but it does happen.

@jeremylong @aikebah I feel we should do this hiding-sensitive-information-through-the-use-of-env-variables consistently across the project. Use the same coding pattern, naming scheme plus documentation for all affected parameters. I don't think it'd be helpful if I just followed what we have for the NVD API key and applied it for the OSS Index user/pw.

From what I can tell, the NVD API key is the only parameter so far that we treat like this? If I counted correctly, we have 7 '*password' and '*token' parameters, 8 for '*user', and 2 for '*key'. Hence, 24 - 1 new 'xxxEnvironmentVariable' parameters.

→ more unrelated refactoring than should be included in this PR

@marcelstoer I agree that it would be good to use same strategy for other cases of passwords information, however I consider those separate enhancements of existing functionality, so they could be taken care of outside the scope of this change-request which is all about enabling an alternative to communicate OSSIndex credentials to the Maven plugin.

Most user/pass settings are for on-prem, typically corporate, copies or reverse-proxies exposing open public information behind a login (typically due to corporate policies demanding 'only authenticated access on any system', even when it only exposes public data in mirrored form internally in the company infrastructure). Their usage is expected to be the exceptional case, whereas NVD API and OSSIndex logins are to be expected a regular case as they are a means to obtain a higher max request rate on publicly available resources.

I'll open an enhancement request around secrets/creds as env variables.