Why should the match certificate repository be private and not public, if the contents are encrypted anyway?

[janpio]

Generated README in the match repo after init says:

Important: Make sure this repository is set to private and only your team members have access to this repo.

same in the instructions in the documentation:

1. Create a new, private Git repo (e.g. on GitHub or BitBucket) and name it something like certificates. Important: Make sure the repository is set to private.
   https://docs.fastlane.tools/actions/match/#setup

But at the same time:

When running match for the first time on a new machine, it will ask you for the passphrase for the Git repository. This is an additional layer of security: each of the files will be encrypted using openssl. Make sure to remember the password, as you'll need it when you run match on a different machine.

To set the passphrase to decrypt your profiles using an environment variable, use MATCH_PASSWORD.
https://docs.fastlane.tools/actions/match/#passphrase

Why should the match repo be private, if the contents are encrypted anyway?
What sensitive information can be gathered from looking at the encrypted files?
Is it just an additional layer of security?

[Sajjon]

If we suggest that the user inputs a unique, cryptographically secure password, typically generated by and saved in a password manager (e.g. 1Password), surely that is enough in terms of security. We could even suggest a minimum number of chars for reaching high entropy (in 1Password we can use up to 64 chars)?

[janpio]

If the only thing to protect is the content of the certificates, then I agree. But maybe the author had other information in mind when giving these instructions?

[joshdholtz]

I guess I'm going to ask a useless question first of... if its encrypted and nobody can do anything with it, why should it be public? 😉

But my real answer is... private isn't necessarily "required" but it is the more secure approach.

1. The profiles and certificates contents aren't encrypted but the filenames are not (right now). The profile file names are stored in the format of <type_of_cert>_<bundle_id>.mobileprovision. All of the bundle ids would be open for the public to view. I don't know exactly what somebody could do with view bundle ids but we usually redact them from the output when people copy/paste fastlane logs into issue so it also doesn't seem like something that should be super public.
2. Even though contents are 256 AES encrypted, it is still possible for someone to brute force decrypt them easier if they actually had the files (which they can get from a public repo). The repo being private (behind Github's or Bitbucket's authentication system) adds another strong layer of security which prevent any of the brute forcing from happening.
3. We (at fastlane) also want to also protect ourselves from as much as possible. So suggesting that the encrypted contents are also stored in a private repo also benefits us because we suggested the best possible security (even though this is technically "use at your own risk" kind of thing)

So TL;DR - private repo not required but there isn't much benefit that a public repo offers besides less sys admin type work of inviting someone to a team with the private repo

😊

[janpio]

I guess I'm going to ask a useless question first of... if its encrypted and nobody can do anything with it, why should it be public? 😉

Let me answer this with a hopefully useful answer before I read the rest of your reply:
Because connecting to a public repository can be easier than connecting to a private. Keys, passwords have to be managed and protected. This can be a challenge in some environments (e.g. password in a git URL could leak via the output of the lanes and actions, keys can be extracted via PRs to repositories that run CI etc.)

[joshdholtz]

@janpio I covered that in the TL;DR (last line) of my reply 😉

So TL;DR - private repo not required but there isn't much benefit that a public repo offers besides less sys admin type work of inviting someone to a team with the private repo

[janpio]

To your 3 other arguments: Ok, got it:

1. Information leakage from file names,
2. Brute force decryptability and
3. protection of the development team re 1 and 2 and unknown other possible factors.

Makes sense.

[Sajjon]

Bitrise does not support SSH key for public apps in Bitrise (its cool, they offer free build time for open source projects), but even though my app is open source on Github, the match git repo is private.

Right now I've solved it by generating a personal access token for my user in Github and setting the MATCH_GIT_URL as a secret (and protected) environment variable in Bitrise workflow to git clone https://username:personal_access_token@github.com/username/repository.git.

This works, not sure if there is any security implication I am missing.

Do you think it would be better if I were to just change the git repo for my match certificates to be public? At least that way I would not risk someone picking up my personal access token somehow...?

[janpio]

@Sajjon Make sure the MATCH_GIT_URL value is not output by match in a "match summary" table or similar, or that Bitrise catches this and removed the GitHub URL from the log.

Also think about the possible side effects of having a personal access token leak - does it offer write access? Does it offer access to only this repo or many of this user?

[Sajjon]

@janpio Bitrise obfuscates the sensitive variables from the logs if they are setup to be private, so in the log the match summary it looks like this:

+-----------------------+-------------------------------------------------------------------------------------------------------+
|                                                   �[32mSummary for match 2.108.0�[0m                                                   |
+-----------------------+-------------------------------------------------------------------------------------------------------+
| type                  | appstore                                                                                              |
| readonly              | true                                                                                                  |
| git_url               | [REDACTED] |
| git_branch            | master                                                                                                |
| storage_mode          | git                                                                                                   |

The personal access token is readonly.

But yeah it might still be better to make the match git repo public and using a long, unique, generate cryptographically secure password for the encryption of the certs.

[janpio]

Ok, great feature of Bitrise. I personally would keep the PAT if I can make sure it doesn't open any new doors (readonly to only that repo) even if it leaks somehow then.