Ability for gradle to mask passwords when info-level debugging is enabled

Help/Discuss
1

Hi,

Is there an option for gradle to mask passwords or other properties when info-level debugging is enabled?
When we run a gradle deployment for our specific environment we see unmasked passwords when info-level debugging is enabled.
Can we suppress that and if so, how is that done?

Thanks,

Peter

2

Not specifically, as there shouldn’t be a case where Gradle core logs a password at any level when using the built-in DSL for the features that accept credentials.

What do you mean by deployment? Traditional “deployment” would most likely be handled by a third-party plugin or possibly custom code in the build.

Depending on the source, your option is find a different plugin that treats credentials better, or fix the code. You’ll need to figure out what is logging it currently.

In any case, if you need to access credentials, it is probably best to use something (like Gradle - Plugin: nu.studer.credentials) that can encrypt the values so that you don’t store them anywhere as plain text. Of course, this won’t help if you decrypt them and hand them off to something that logs them, but it can separate them from non-sensitive properties.

3

hi @jjustinic actually there are cases where gradle leaks secrets. something i came across recently as well. pls find details here Secret Leaks in gradle daemon logs : Gradle printing out every key as well as value

4

While this is a very old thread, your example is not any different than what was being discussed here.

If you provide credentials to the build environment through plain-text environment variables, unless there are compensating controls, it is possible to see them. For example,

repositories {
    maven {
        url "https://example.com/m2"
        credentials {
            username = System.getenv("REPO_USERNAME")
            password = System.getenv("REPO_PASSWORD")
        }
    }
}

The Maven repository’s credentials.password field doesn’t have an option to not log it because it simply wouldn’t have been logged. The REPO_PASSWORD could be logged though as the author of this script has chosen to use a plain-text environment variable to provide it in the DSL.

Compensating controls could be running in a CI environment that masks all provided secrets that appear anywhere in the output or using code in the build script that decrypts an encrypted value provided in a more secure manner. The build script author needs to be aware of the implications of how providing values certain ways impacts the security of those values.

The nuances of what was being talked about in the thread are harder to understand because it seems like all Gradle related, but it was conceptually the same as you don’t need to worry about getting a more secure door lock if you’re just taping the key on the door or never locking it.