[security] don't use credentials in examples

[xenoterracide]

it's pretty much never safe to use any kind of secret as an argument as the command line will record it in history, build tools often preserve these in logs too. There are ways to avoid both, but it's too easy to make a mistake.

[jjohannes]

Thanks for the feedback. In general, I think it is a good example. You can also set parameters through ENV variables. And if you use them only on systems like GH Actions, you can also configure things to use them via -P without being recorded/shown.

I like the example, exactly because of security. Credentials is something you NEED to put in from the outside. There is no other good example I can think of (almost) every build needs.

Because (event though I co-maintain this plugin) I think a good build setup does not have parameters, but models everything in the build through different task configuration. So that when you call Gradle from the command line yourself, the only thing you need to give is one (lifecycle) task. There are complex setups which needs parameters for good reasons (that was one motivation for creating this plugin). But I think a "standard Java build" should not.

That's why I can't think of another good general example from the top of my head.

But you are right that the README right now very prominently shows using -P from the local command line. Will keep this issue open for now to see what we can do.

[xenoterracide]

You should also not set secrets through environment variables. Parameters and environment variables are very bad ideas for credentials. It's very very easy for that data to leak.

[britter]

@xenoterracide how do you provide credentials for publishing to a repository when the build is running on a CI server? You need some way of supplying the credentials from the environment to the build process.

[jbduncan]

I was going to suggest environment variables, too. At least then it lets people avoid putting the secrets in the Gradle command. And short of having a secrets manager like Hashicorp Vault, SOPS or GitHub secrets, envvars are the best solution I can think of. 🤔

[xenoterracide]

It's only safe to provide credentials as files or via some other in memory process like http and something like hashiCorp vault. There any number of articles on the internet that describe why it's not safe to put credentials and environment variables or on the command line. I can do the googling if you'd like.

[britter]

Hey @xenoterracide, we're happy to accept a PR updating the documentation with a better example.

[xenoterracide]

you know what's funny, still mulling this over. I've rarely wanted to put credentials on the cli because I can usually store them in a config file, and they rarely change. Interestingly enough if they needed to be one off env vars (bad idea, but still) I know how to put those in a single command too.

most of the command line parameters I've ever wanted are actually related to runtime, not the build. Only thing I can really imagine is switching out something like the version of the jvm for test running, or something like that. The closest thing I personally have to this in my current builds is this block of code. I'm not actually certain that I could use this plugin to replace what I'm doing here (can it?). I (obviously?) never manipulate this on the cli by hand myself, and idea is cowardly refusing to tell me the full cli it's executing.

    val inIdea = providers.systemProperty("idea.active").map { it.toBoolean() }
    if (!inIdea.getOrElse(false)) {
      errors.addAll(
        listOf(
          "WildcardImport",
          "UnusedVariable",
          "UnusedMethod",
          "UnusedNestedClass",
        ),
      )
    }

[xenoterracide]

another thought might be setting the version, it's not sensitive and yet it's something that in CI you probably want to set dynamically as it changes on each release. Currently I'm trying to decide the best way to deal with it.

I'd rather see if you like a suggested example before writing a PR to change it. Motivation to PR has been low for a long time due to rejections and code "theft".