Remove safe credentials reference

[ljacomet]

Following the details in #22618 and the comment that some checks were removed from 7.6, we need to fully remove the "safe credentials" documentation reference and add something about the risks of having credentials be part of the configuration cache entries.

One thing that should be determined is if credentials inside a gradle.properties are saved or if only the checksum of that file is saved.

[cloudshiftchris]

Below is the snippet / instructions I've been using to analyze what is stored in CC. In regards to gradle.properties, it looks like the individual properties there are NOT stored in CC. It appears some form of hash/checksum is stored for each gradle.properties file.

plugins {
    `java-library`
    `maven-publish`
}

version = "1.0.2"
group = "com.example"

/*

# clearout CC, run build to populate CC
rm -rf .gradle/configuration-cache; ENV_SECRET=ANOTHER-SECRET ./gradlew  publish -PfooBar=BAZ_SECRET -PmySecureRepositoryUsername=secret-user -PmySecureRepositoryPassword=secret-password --info --configuration-cache

# dump out all files in CC
find .gradle/configuration-cache

# hexdump the build fingerprint (path will vary)
hexdump -C .gradle/configuration-cache/aqvxhqqm6jsa3zloo4iteoqug/buildfingerprint.bin

For this example, there are six secrets:

1) Environment variable ENV_SECRET (value: ANOTHER-SECRET);
2) Gradle property fooBar (value: BAZ_SECRET);
3) Gradle property mySecretRepositoryUsername (from "safe" credentials) (value: secret-user)
4) Gradle property mySecretRepositoryPassword (from "safe" credentials) (value: secret-password)
5) ValueSource output (value: VALUESOURCE_SECRET)
6) Gradle property "someProp" (value: gradle_properties_secret) from gradle.properties (in the project dir)

The first 5 of the above secrets is present, in clear text, in the stored configuration cache.
The sixth secret, from gradle.properties, is not present in CC (it appears that Gradle stores a hash of gradle.properties, not individual properties themselves)

 */
publishing {
    publications {
        create<MavenPublication>("library") {
            from(components.getByName("java"))
        }
    }
    repositories {
        maven {
            name = "mySecureRepository"
            credentials(PasswordCredentials::class)
            url = uri("https://foo.com")
        }
    }
}

val fooTask = tasks.register("foo") {
    inputs.property("envVar", providers.environmentVariable("ENV_SECRET"))
    inputs.property("gradleProp", providers.gradleProperty("fooBar"))
    inputs.property("valueSource", providers.of(MyValueSource::class, {}))
    doFirst {
        println(inputs.properties["envVar"])
        println(inputs.properties["gradleProp"])
        println(inputs.properties["valueSource"])
    }
}

tasks.named("publish") {
    dependsOn(fooTask)
}

abstract class MyValueSource : ValueSource<String,ValueSourceParameters.None> {
    override fun obtain(): String? {
        // in real code this would be externally-resolved via API call, keystore, etc
        return "VALUESOURCE_SECRET"
    }
}

[ljacomet]

Thanks a lot for sharing this and helping us.
So leveraging gradle.properties might be a way to protect credentials when CC is in use. Might need playing a bit more with the shared build script above to have a full picture.

[cloudshiftchris]

Using gradle.properties shifts the problem from "clear text credentials in CC" to "clear text credentials in gradle.properties", which reduces a few risks but overall isn't great:

• users zipping up their project dir (assuming using ~/.gradle/gradle.properties) would not inadvertently share credentials. This is presumably the case today for many use cases
• awkward to get properties into gradle.properties for CI (likely folks are using -P or env variables, which end up in CC)
• any compromise of the code or filesystem has equivalent access to gradle.properties or CC cache files, which store credentials in clear text

Plus, it assumes the credentials are static. In my use case it's a ValueSource that grabs temporary credentials from an API call (that further integrates AWS SSO/MFA for the user as required). This, and other 'dynamic' variations, aren't addressed by using gradle.properties.

Not sure what the implementation lift is on this, but as a starting point:

• introduce a type "Secret" that can be used say from a ValueSource to indicate a value that shouldn't be cached;
• for properties (regardless of how they are specified - gradle.properties, -P, -D, env) check if these are 'secret' values, e.g. -Pfoo.bar=secret(baz)

That gets us to an OK point, and can be built on to have expiring secrets, etc in the future (per thoughts in #22618)

[ljacomet]

Sorry, I should have been more specific. My reflections concern this particular issue, not the general solution we need to provide for CC.
The risks you list about gradle.properties are not new and potentially known. So folks having need of secrets and wanting to use CC could have different imperfect options on how to handle that today.

[cloudshiftchris]

I see. Thanks for clarifying. If I understand correctly the approach (for the current state of CC) would be "put sensitive items in gradle.properties" (which is not a new recommendation) and not in CC.

[ljacomet]

Changes are in for Gradle 7.6.1