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
sdkmanager
and allow users to select which android tools version they want to use via the twoplatform
andbuild
options (see workaround section below). This can be done by introducing two newDS
variables: e.g.DS_ANDROID_SDK_PLATFORM
andDS_ANDROID_SDK_BUILD_TOOLS
- Make it easy to run Java commands prior to the scan
- Parse the output of the
androidDependencies
task (orapp:dependencies
ifapp
is the main module), similar to what's been proposed in Replace gemnasium-gradle-plugin with the htmlDe... (#337083) - Parse the
root.js
files created by thehtmlDependencyReport
task, as proposed in #337083
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/.bashrc
Shell 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