https://gradle.com/ logo
Join Slack
Powered by
but I'd rather avoid dumping it to a file
# community-support
m
but I'd rather avoid dumping it to a file
🧵 1
v
Please do not split topics across several threads. This makes following the conversation in the threads view very hard as the context of the other messages is missing. If you have additional information either edit the original message or post to its thread. Regarding the problem, nor sure what password you are talking about. But if you for example mean the last parameter of 
useInMemoryPgpKeys
in the 
signing
extension, that is a plain 
String
, so even dumping to a file in a task will probably not help as at configuration time the file will not yet be produced or you are reading a stale version of it from a former run. Maybe with Gradle 10 if things got propertyized.
m
Hey, this could be a standalone topic - not sure, that's why I created it as standalone
v
Not sure what you mean
You created three threads instead of one
m
ah, that you mean, yeah, sorry
👌 1
the thing is, that there is android.signingConfigs where one can create static configs
there you'd put all credentials
v
Ah, Android, very important detail you left out
Android is always special, and I have no idea about Android 😄
m
🙂 I'm so only android that I tend to forget it
v
But the basic of what I said stays the same
But you might have more luck in #CJYS1DAP5 where it is then also clear that you are talking about android 🙂
m
got it, thanks
👌 1
Just in case anybody will read this - one can do all the code within modules's build.gradle.kts, no need for gradle tasks
t
Your release/upload signing config is probably the most important set of secrets to protect. Typically what I do is generate a debug keystore to commit to git so all devs can use it, and just hardcode the alias/pw/etc. then only put those key fingerprints for our non prod package IDs. For release, the signing key is stored either as a base64 encoded string in repository secrets, or in some other protected storage mechanism (IE: AWS S3 or SM). Then similarly the alias, password is stored in a json format in the same manner. After that it is loaded into place via setup steps in our GHA config so gradle can use them for only the jobs that need it in an attempt to ensure no human has direct access beyond the time window of creating/storing it.
m
yep, I'd like to improve on former - not to store it globally if possible (but even your approach is not that problematic)
out of curiosity, how do you transfer keystore from secure storage to gradle?
by writting a file?
t
I use bash to load it from gha secrets to a file/env vars. Then the signing config block just checks for the file path being present in the env to decide what to do.
initWith is a decent way to shortcut so if you don't have the files it just falls back to the debug keystore config
m
got it, thanks
one more question - how do you treat other secretes in debug mode - like keys for some protected libraries, google_services file and such
t
most of them are still in git because they are effectively required to be present for local builds. probably a dumb hill for me to go to battle on but if security starts trying to force you to store everything in something like Vault only for you to have to write gradle tasks to copy them to every computer that is going to run the build you have not improved security at all, but only made doing the job more difficult for no reason
m
yeah, true, I never know how to handles those - as you said, they always end up in .apk or .aab anyway
t
Personally I think that issue is one that google should provide something for to securely get them on the phone at install time but without them being inlined to the apk bytecode
m
That certainly help, but we don't have that and wee might never :(
Open in Slack
PreviousNext
Powered by