Gitlab Secure Files

In Version 15.7 Gitlab added support for project-level secure files. It can be quite useful when building CI/CD Pipelines for mobile Apps.

This post will show, how to use secure files for signing iOS Apps with fastlane. The concepts can also be used for Android apps and secure files can also help you if you’re not using fastlane (yet).

Most CI/CD Pipelines for iOS Apps use either Fastlane or Xcode Cloud. If you use Xcode Cloud, I don’t think any of the following is necessary.

Code signing using Fastlane

With Fastlane there are usually 3 Different approaches to do code signing

1. Use automatic signing and pray that everything works
2. Use Match. Match uses a different Git Repository or Cloud Storage to store all certificates and provisioning profiles. These Profiles can then be loaded by every Team member, that has access to the cloud storage
3. Use Sigh / Cert and either have the certificate on the CI Runner (Don’t do that. Seriously. Don’t). Or include the (encrypted) signing certificate to the git repo of the app.

Pros and cons of each method

• Using automatic signing might work, but I wouldn’t completely rely on it. Especially if you only want to set up your CI once and not having to touch it all the time.

• Match actually works quite well, but it’s usually an overkill to set it up. Especially if you have a smaller project, or the organisation doesn’t have multiple applications that need to be signed.

• Sigh / Cert also work well. The only downside is, that you are responsible for providing the certificates to Fastlane.

• Storing the Certificate in the git repository of the app, is currently (looking at you sideloading) not that big of an issue IF THE CERTIFICATE is NOT AN ENTERPRISE CERTIFICATE. You can currently only use the certificate to sign apps, which then need to be be uploaded to the App Store.

• On the other hand, even if you certificate get’s exposed, an attacker would still need to have it’s password which is usually injected to the CI Job as a protected and Masked CI/CD Variable.

What are gitlab secure files?

With Gitlab secure Files you can store up to 100 Files for each project. These files will then be stored securely outside of the project’s repository.

The location can be setup system wide for each gitlab instance. You can use local storage or object storage like Google Cloud, Amazon S3 or others.

Gitlab project-level secure Files was introduced in Gitlab 14.8 with a feature flag and was made available generally in Version 15.7.

Now let’s look at an example.

Head over to your gitlab project and go to Settings -> CI/CD. If your gitlab instance has secure files enabled you will see Secure Files as one of the options.

You can upload a new file by clicking on “Upload File”. This file can then be accessed by CI/CD Jobs run in that repositories.

Accessing Secure Files

To access the files in a CI/CD Jobs you should use Gitlab’s download-secure-files tool. It is a tool written in go that will handle authentication for you and will then download the file and further make sure, that the file is actually the file you wanted to download.

By default the downloaded file will be stored in the directory ./secure_files. So if you uploaded the file foo.bar it will be at ./secure_files/foo.bar

The directory can also be specified by setting the variable SECURE_FILES_DOWNLOAD_PATH inside the gitlab ci to whatever path you wish.

build:
  variables:
    SECURE_FILES_DOWNLOAD_PATH: './some/where/I/belong/'
  stage: build
  script:
    - curl --silent "https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer" | bash
    - bundle exec fastlane build

Conclusion

Gitlab’s secure files is actually a mixture of Fastlane’s Match (storing the files outside of the git repo) and sigh / cert.

You can easily upload your signing certificate and provisioning profiles using Secure files and download them on every build step, that needs them.

Additionally you could easily encrypt the certificate files using openssl or alternative encryption tools and then decrypt them after downloading inside the build step.

Once the Certificate has been downloaded you can use it with sigh / cert as usually.