feat: add Dockerfile and launching script for it

[vadim-belous]

Add multi-stage Dockerfile and launching script for it

Stages:

• Build .jar with Gradle
• Copy it to the new container and run it via OpenJDK

I considered simplicity of use. Now, there’s no need to write complex docker commands. You just need to use the following script (./docker/apktool.sh) and pass the required arguments for Apktool

Usage:

Clone the repo and move to it. Then build the image and use the shell wrapper to run apktool via docker:

git clone https://github.com/iBotPeaches/Apktool
cd Apktool
docker build --platform=linux/amd64 -t apktool:latest -f Dockerfile .
./docker/apktool.sh d example.apk -o decompressed_example_apk
./docker/apktool.sh b decompressed_example_apk -o assembled_example_apk.apk

[iBotPeaches]

I like this now. I'll take a detailed look soon. Thanks!

[vadim-belous]

Yes, if we don’t specify a particular user in the Dockerfile, processes in the container will run as the superuser (root). This is indeed a security issue. I resolved this issue by switching to a nonroot user, after changing the container image from openjdk:11 to the distroless version (gcr.io/distroless/java:11`). After switching the image, I ran the tests, and everything works correctly

Additionally, replacing the image provided the following benefits:

• the image size was reduced threefold (from 1GB to ~350MB).
• containers running from such an image are not vulnerable to LOTL (Living Off The Land) attacks. Specifically, due to the absence of a command-line shell and certain other system utilities, an attacker cannot perform further post-exploitation via a Docker container based on a Distroless image

I also checked the Dockerfile using the Hadolint security linter (this can also be done online via this link), and it reported 0 issues. Therefore, the configuration is currently quite secure. Thank you for pointing that out

P.S. on the screenshot, I used the Docker CLI manually for debugging. It can also be run normally via the /docker/apktool.sh script

[iBotPeaches]

thanks! This is looking good. Do you see any benefit to publishing this container to GitHub registry so it doesn't have to always be built?

[vadim-belous]

It would be great if this image was uploaded to the GitHub Container Registry or to a registry like Docker Hub or Google Container Registry. This approach would make it easier for end users to work with Apktool, as they wouldn’t have to build the Docker image every time

Additionally, this method offers a less obvious benefit: people could use the image uploaded to the GitHub Container Registry to build their own images. They could also reference the image path on ghcr.io in their Docker Compose or Kubernetes manifests and CI pipelines (GitHub Actions, GitLab CI, Jenkins, etc.). At the same time, users would still have the flexibility to build the image on their local machine, for example, after making specific changes, and push it to their private Docker registry if needed

It would also be a good idea to automate the build and push process to the registry using CI (GitHub Actions)

[vadim-belous]

Is this okay, or do I need anything else for my commits to be approved?

[iBotPeaches]

It looks good - I just haven't figured out my publishing plan for the container.