search

NeoA11y / SpeakTouch

[WIP] A free software screen reader for Android.
8 stars 0 forks source link

Add Gradle dependency verification metadata #116

Closed PatrykMis closed 7 months ago

PatrykMis commented 7 months ago

Description

Speak Touch is an accessibility service with access to screen content and user input, emphasizing the need for rigorous security measures. This pull request introduces Gradle dependency verification metadata.

To generate this metadata, the following command should be executed each time a dependency is updated:

./gradlew --write-verification-metadata sha512 clean build --no-daemon --rerun-tasks

Why is this important?

  1. Security First: Given the nature of our accessibility service, which interacts with screen content and user input, prioritizing security is paramount. The inclusion of dependency verification metadata ensures the ongoing integrity and security of the dependencies used in our project.

  2. Protection Against Supply-Chain Attacks: In the event of unauthorized changes to dependencies or potential supply-chain attacks, the verification process serves as an early warning system, fortifying the accessibility service against potential security threats.

This pull request underscores our commitment to security, ensuring a robust and secure environment for the Speak Touch accessibility service.

More reading: Android Security: Securing Your Gradle Builds from Baddies.

Irineu333 commented 7 months ago

Very good! I saw some time ago a news about a supply-chain attack on npm, but I didn't go in depth to understand how it is done and how to protect against it. In this sense, you are being a true security analyst for Speak Touch

Irineu333 commented 7 months ago

⚠️ I am receiving a verification error in the lib org.codehaus.groovy:groovy:3.0.1 when trying to synchronize the gradle. 

Dependency verification failed for org.codehaus.groovy:groovy:3.0.17
One artifact failed verification: groovy-3.0.17.pom (org.codehaus.groovy:groovy:3.0.17) from repository Gradle Libs
Irineu333 commented 7 months ago

Some questions and considerations:

  1. What are the purposes of the arguments --no-daemon --rerun-tasks?
  2. Is any ci/cd needed to run the verification? Or will it fail in Validate Gradle Wrapper?
  3. To get the most out of this security, should we have an action to generate the apk and aab, right? If done locally, it could be bypassed.
PatrykMis commented 7 months ago

I am receiving a verification error in the lib org.codehaus.groovy:groovy:3.0.1 when trying to synchronize the gradle.

Are you using InteliJ or Android Studio? Which version? It can be bug related to https://youtrack.jetbrains.com/issue/IDEA-258328 and have a workarround.

  1. What are the purposes of the arguments --no-daemon --rerun-tasks?

I do that to make sure no task will be skipped and also to not use currently running Gradle deamons.

  1. Is any action needed to run the verification? Or will it fail in Validate Gradle Wrapper?

It just fail if something can't be validated if gradle/verification-metadata.xml is present.

  1. To get the most out of this security, should we have an action to generate the apk and aab, right? If done locally, it could be bypassed.

Everything can be bypassed, like removing sha-256 hash from gradle-wrapper.properties. It just ads one more layer of protection. Anyway, if we'll build as an action, the apk/aab should be signed, too which is not we want. Finally, the apk should be signed by admin - you before it will be published as release and to stores like Accrescent / Play Store.

I'm considering to make an action for push/pull though, to check independantly if everything is valid before merging pull request. Let me know and I'll do it in separat PR.

Irineu333 commented 7 months ago

Are you using InteliJ or Android Studio? Which version? It can be bug related to https://youtrack.jetbrains.com/issue/IDEA-258328 and have a workarround.

I use Android Studio, Android Studio Hedgehog | 2023.1.1 RC 3.

It just fail if something can't be validated if gradle/verification-metadata.xml is present.

I understand, but my question is whether the validation will be done by a specific pipeline. I will do a test by sending a commit changing a dependency, and see if the Validate Gradle Wrapper fails

Irineu333 commented 7 months ago

The Validate Gradle Wrapper did not fail. So, a GitHub action is needed to check this

PatrykMis commented 7 months ago

Exactly. Validate Gradle Wrapper checks wrapper jar checksum only.

Irineu333 commented 7 months ago

Anyway, if we'll build as an action, the apk/aab should be signed, too which is not we want. Finally, the apk should be signed by admin - you before it will be published as release and to stores like Accrescent / Play Store.

Why don't we want it to be signed? We can encode the keystore in the GitHub secrets to sign automatically.

PatrykMis commented 7 months ago

Do you have more trust to GitHub servers than your own machine?

PatrykMis commented 7 months ago

I will rebase this PR. It seams InteliJ Idea 2023.1 has this issue, and Android Studio version you use is based on this version.

Android Studio is the customized fork of InteliJ.

Irineu333 commented 7 months ago

Do you have more trust to GitHub servers than your own machine?

Well, since I have a separate machine for work, I trust it a lot. I can't say what would be more likely; some failure on GitHub allowing the leakage of the keystore or me inadvertently installing malicious software on my machine. I think either scenario is quite unlikely, I would like a pipeline to generate the APK more for convenience really.

PatrykMis commented 7 months ago

Ok, shall I do it in separate Pr or just here?

Irineu333 commented 7 months ago

I will rebase this PR. It seams InteliJ Idea 2023.1 has this issue, and Android Studio version you use is based on this version.

Android Studio is the customized fork of InteliJ.

I can use the latest version of IntelliJ while waiting for a new release of Android Studio, but then it's necessary to indicate the reduced compatibility in the README.

PatrykMis commented 7 months ago

I've just added a workarround. Can you try now?

Irineu333 commented 7 months ago

Ok, shall I do it in separate Pr or just here?

If you are talking about github action to generating the APK/AAB, I wasn't suggesting doing it now. We can discuss more about this. But I think a GitHub action to run the dependency check is necessary, it would be annoying to find out that the validation is failing after merging the pull request.

We need to ensure that the develop and master branches are always functioning, eliminating human errors. So, I will add this action as a requirement for merging the pull request

Irineu333 commented 7 months ago

Ok, shall I do it in separate Pr or just here?

It worked!

Irineu333 commented 7 months ago

It worked: https://github.com/NeoA11y/SpeakTouch/actions/runs/7025152507/job/19115407206?pr=116