Security Concerns with debug.keystore and APK Generation

[dzuluaga]

Issue Description

We have identified several security and usability concerns related to the handling of the debug keystore and the APK generation process in our sample app. These issues potentially pose security risks and negatively impact the developer experience.

Concerns

1. debug.keystore checked into source code

   • The debug.keystore file is currently checked into the source code repository.
   • This poses a security risk, even for a sample app, as anyone can build another app using the same signature and potentially access the same services in Azure.

2. APK Generation in GitHub Actions

   • While using a keystore for APK generation in GitHub Actions is understandable, the current implementation may not follow best practices.
   • Recommendation: Store the keystore as a base64 encoded GitHub Secret and decode it during the GitHub Action execution.

3. Confusing Instructions in Sample App

   • The current instructions require developers to change MICROSOFT_CLIENT_ID and MICROSOFT_SIGNATURE_HASH in local.properties.
   • These values should be associated with the developer's Azure app and the signature hash retrieved from their local machine, not from the source code's debug keystore.
   • This has led to confusion and troubleshooting difficulties, as requests are being sent with two different hashes (one from local.properties and another from the debug keystore used to sign the APK).

Impact

• Security vulnerabilities due to exposed keystore.
• Potential misuse of Azure services.
• Poor developer experience, causing frustration and wasted time during setup and troubleshooting.

Proposed Solutions

1. Remove debug.keystore from the source code repository and update the .gitignore file accordingly.
2. Implement a secure method for storing and using the keystore in GitHub Actions, such as using base64 encoded GitHub Secrets.
3. Clarify and simplify the instructions in the sample app documentation, emphasizing the correct usage of local.properties and explaining the signature hash generation process.
4. Consider implementing a more streamlined setup process that reduces the potential for confusion between local and repository-provided keystores.

Questions

• Can we implement these changes to address the security risks and improve the developer experience?
• Are there any concerns or potential impacts we should consider before making these changes?
• What is the timeline for addressing these issues?

Please let me know if you need any further information or clarification on these points.

[adamTrz]

We've removed debug.keystore from source control and implemented on the fly keystore creation from GH Actions This issue should be fixed once https://github.com/openmobilehub/react-native-omh-storage/pull/57 is mergerd.

[dzuluaga]

Hey Adam,

Thank you for working on the keystore issue. I encountered a problem when building the APK locally—the APK is not stored in the expected folder but ends up in a different system directory. The error message is:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:validateSigningDebug'.
> Keystore file '/Users/diegozuluaga/tools/git/react-native-omh-storage/apps/sample-app/android/app/debug.keystore' not found for signing config 'debug'.

To address this, I suggest a potential solution that allows the use of the debug.keystore from GitHub Secrets while maintaining the default local configuration. Here’s how you could approach it:

1. Modify build.gradle: Adjust the signing configuration based on whether the build is running locally or in a CI environment.

   signingConfigs {
       debug {
           def isCI = project.hasProperty('isCI') ? project.getProperty('isCI').toBoolean() : false
           def debugKeystorePath = isCI ? "${rootProject.projectDir}/ci/debug.keystore" : "${System.getenv('HOME')}/.android/debug.keystore"
   
           storeFile file(debugKeystorePath)
           storePassword 'android'
           keyAlias 'androiddebugkey'
           keyPassword 'android'
       }
   }

2. Add to gradle.properties: Define the environment variable to distinguish between CI and local builds.

   # gradle.properties
   isCI=false

3. Set Environment Variables in GitHub Actions:

   - name: Build with Gradle
     run: ./gradlew assembleDebug -PisCI=true

This setup should help in using the correct keystore location depending on whether the build is running locally or on CI, ensuring that the APK is stored in the right folder in both cases.

However, please consider this as a suggestion. It’s important to assess whether this approach aligns with the best practices for your project. I recommend testing it in all environments to confirm it resolves the issue without introducing new problems.

Looking forward to hearing your thoughts!

Best,
Diego

[dzuluaga]

@Nataliagros @adamTrz Friendly ping.

[adamTrz]

Hi @dzuluaga I've added a CI check to distinguish android builds done locally and with Github Actions. You can check out successful build here: https://github.com/openmobilehub/react-native-omh-storage/actions/runs/10811047878