1

I inherited an Android Project where the previous maintainer stored the release and debug signing keystore and key aliases/passwords in plain text in the app’s build.gradle. This was then checked into a GitHub Git repository. The repo is only accessible to me so this isn't a big deal at the moment, but in the future more people may have access to the repo who I want to prevent from making a release signature.

signingConfigs {
        debug {
            storeFile file('debug.keystore')
            storePassword ‘<password in plaintext>’
            keyAlias ‘<alias in plaintex>’
            keyPassword ‘<password in plaintext>’
        }

        release {
            storeFile file(“<path to .jks file>“)
            storePassword ‘<password in plaintext>’
            keyAlias ‘<alias in plaintex>’
            keyPassword ‘<password in plaintext>’
        }
    }

I know this is a bad practice and I’d like to remove the plaintext passwords and aliases. At first I considered simply removing the plaintext and reading the passwords in from an external file that is not checked into the repo (https://developer.android.com/studio/publish/app-signing.html#secure-shared-keystore). However, it dawned on me that the passwords will still be in the Git history and easily discoverable. I then did some research and found that you can change the password on a keystore (Keystore change passwords). Great, but if I do that, would someone be able to just download the old version of the keystore before the password change from the Git repo and use the old password to generate a valid signature?

Community
  • 1
  • 1
Stephen
  • 1,373
  • 1
  • 12
  • 13

1 Answers1

0

Find the commit has of where the passwords were added. Then git rebase -i commitHash . Use edit on this commit, remove the passwords, then continue rebasing, It should conflict if passwords were changed afterwards so you can remove them as well. Then make new commit using external file. You should do this on all branches you have or better yet keep only master and do it there.

Git rewriting history

X3Btel
  • 1,408
  • 1
  • 13
  • 21
  • one should also call `git gc`, because while the commit is no longer reachable, unless it is garbage collected, it is still in the repository. It's important to do this on the remote, and if possible on all clients that checked out the repo when that commit was still there, as they may have downloaded it. – Lukas1 Apr 09 '21 at 15:47