github-actions - Security threat?

yellow-leaves

Usage of Github-actions seem to become more and more prevalent amongst developers and I'm wondering how this affects the development process.

Some developers seems to delegate the building and apk signing process to github-actions.
If github-actions signs ones apk does this not mean it must have been entrusted with ones signing key and are therefore in full control of them?
If my assumption is correct, that github is holding developers signing keys, then what's to stop them from inserting whatever they may want into ones builds, like tracking or ads?

Furthermore, if GitHub is holding developers signing keys then this also increases the attack surface as ones signing keys are kept by an additional party that might for example be hacked.
What do you guys think, does integrating github-actions into the development process pose a security threat, or am i just off my trolley?

P.S. I'm no developer so if anyone has any actual insight into github-actions then I'd appreciate to hear what you have to say.

xzutils

yellow-leaves if github ever injected malicious code that way, the hash would different from a compiled version and if it happened once github would lose all trust, so it's an attack vector but not a good one and wouldnt be easily reusable

yellow-leaves

xzutils
Your right, but how many people actually build there own android apps, even if they did I don't think they would be able to verify the checksum the way you describe as i believe that requires that the developer supports reproducible builds.

The only apps i was able to find that offer reproducible build are Telegram and Signal.
https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md
https://core.telegram.org/reproducible-builds

In addition it appears f-droid provides some apps with instructions for reproducible builds
https://f-droid.org/en/docs/Reproducible_Builds/#reproducible-signatures

xzutils

yellow-leaves
If the only way to use an app is to download it and install it, then it's already compiled and there's no way to know if the code is tampered with.

If a developer isn't offering code that can be compiled, then github could make available a similar version of the app with malicious code or be compelled under threat of fines or jail by bad actors to replace the real app with an evil replika of that app with malicious code.

If you cant't compile an app and compare the compiled hash to the downloaded hash, then you are just trusting the code is safe. But in that situation a developer could be compromised as easily as github, although github has more avenues to get the compromise done since they already have relationships with state actors.

Are there a lot of fdroid apps that cant be compiled?

yellow-leaves

I do agree,
in order to properly verify that an app does what It's intended to do the source code must of course be available for scrutiny, however it's not feasible (not for anyone) to scrutinize the code of each app on there phone before every update.

In lay of this, we simply have to chose whether we trust a specific dev, or not.
Of course if one has the skill set i would assume one can take a peek at the code and decide weather it seems reasonable.
If a proper audit has been done you may of course study it and make your decision based on it.
But in the end we simply have to chose whether to trust a developer or not, don't we?

On android, the developer is represented by a signing key, (public private key pair) the developer uses there private key to sign every release before publishing and thereby verifying there identity as the developer and also that the app has not been tampered with.

As we have decided to trust the developer we now need try and verify there public key.
One way this could be done is by comparing the public key hash that is found in the apk against copies posted on varies platform where the developer has a presence.

If I've been in any way successful in explaining my understanding of the app signing process you'll now understand why i very much dislike the idea of github holding developers private keys.
That is that private keys are suppose to be a developers unique mark that both assures you of the developers identity and the apps integrity.

It's not suppose to managed by github where it risks being misused by either the staff (if they have such access) or by some hacker exploiting some weakness in githubs systems.

Sure, the developer oneself could be compelled to introduce malicious code into their app by a bad actor, but that doesn't nullify my argument as github represents an additional party which is needlessly granted privileged access to developers private keys.

Ultimately, I'm saying that surrendering ones signing keys to github leads to an increased attack surface that could be exploited either by github or someone else.