Android support for Dependency Scanning (gemnasium-maven)
Release notes
TODO: Announce Android support for Dependency Scanning
Problem to solve
GitLab Dependency Scanning supports Java Gradle projects but Android projects aren't supported because:
- The Android SDK isn't installed in the gemnasium-maven image used for the scan.
- There's no documentation on how to set up Dependency Scanning for Android projects.
- The possible workaround are too tied to implementation details of gemnasium-maven.
Intended users
User experience goal
Setup and usage are similar to Dependency Scanning for any Java Gradle project.
Proposal
We can either:
- Pre-install the Android SDK in the gemnasium-maven
- Pre-install Android's
sdkmanagerand allow users to select which android tools version they want to use via the twoplatformandbuildoptions (see workaround section below). This can be done by introducing two newDSvariables: e.g.DS_ANDROID_SDK_PLATFORMandDS_ANDROID_SDK_BUILD_TOOLS - Make it easy to run Java commands prior to the scan
- Parse the output of the
androidDependenciestask (orapp:dependenciesifappis the main module), similar to what's been proposed in Replace gemnasium-gradle-plugin with the htmlDe... (#337083 - closed) - Parse the
root.jsfiles created by thehtmlDependencyReporttask, as proposed in #337083 (closed)
Questions:
- Which versions of the Android should be pre-installed in the image?
- Should we make it easy to switch between versions using a new CI variable?
Further details
This CI configuration shared by @sabinecarpenter seems to work:
gemnasium-maven-dependency_scanning:
variables:
ANDROID_SDK_ROOT: "/path/to/android_sdk_root"
SECURE_LOG_LEVEL: debug
ANDROID_COMPILE_SDK: "29"
ANDROID_BUILD_TOOLS: "29.0.3"
ANDROID_SDK_TOOLS: "6514223"
before_script:
- export ASDF_DATA_DIR="/opt/asdf"
- . $HOME/.bashrc
- switch_to java "adoptopenjdk-${DS_JAVA_VERSION:-11}"
- # commands to install Android dependencies...
script:
- /analyzer run
This CI configuration shared by @ifrenkel seems to work:
prep android sdk:
image: registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven:2 # analyzer image has needed java but another java docker img can work as well
stage: pre-test
script:
- source ~/.bashrc # ensure java available to commands below
- apt-get update && apt-get install -y wget
- mkdir /tmp/sdktools
- wget $COMMAND_LINE_TOOLS_ARCHIVE -O /tmp/sdktools/tools.zip # install sdkmanager
- unzip /tmp/sdktools/tools.zip -d /tmp/sdktools/
- mkdir .prepped-android-sdk
- echo yes > answer # can't pipe yes to command below
- /tmp/sdktools/cmdline-tools/bin/sdkmanager --verbose --sdk_root=.prepped-android-sdk "platform-tools" "$ANDROID_SDK_PLATFORM" < answer
- /tmp/sdktools/cmdline-tools/bin/sdkmanager --verbose --sdk_root=.prepped-android-sdk "$BUILD_TOOLS" < answer
These could be documented workarounds but:
- They are fairly complex.
- They leak implementation details, in particular the existing of a
/root/.bashrcShell script to be source before running any command.
Implementation plan
TODO
This should cover:
- creating a dedicated test project
- adding new integration tests
- releasing a new MINOR version of gemnasium-maven
- updating user docs
Permissions and Security
No change
Documentation
To be documented in Supported languages and package managers
Availability & Testing
A new integration test is added to check Android support. This could either be:
- image integration test using fixtures directory (preferred)
- job integration test using an external test project
Available Tier
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
No
Links / references
Edited by Fabien Catteau