Don’t hold your breath. 
Yeah, i noticed that much
I will stop refreshing
I was just wondering if there is a way to predict this manual process
Also, i wonder why is not automated? Is it a money thing?
You can automate a part of it, checkupdates is now a CI job on Gitlab, build is build, but signing is done on an air-gapped machine…so you need a human. Then those files come back to be published.
Also, updating the buildserver, again manual.
Maintenance
Etc
2 Likes
This do seems like a reason to not be able to automate it
Although i dont know if it really helps something signing packages on an air-gapped machine while the build is done in a different machine. You dont really know what you are signing, do you?
Is the cycle supposed to happen once a day as @f_droid-anyone suggested?
It’s all open source, you build the code.
The extra step is about signing, not about the apps.
I see
What does this signature mean tho?
What i mean is that you either trust the build machine or you dont. Either you can sign on that machine and automate the whole thing, or if you dont and you sign on a different machine, you dont really know what you are signing
Im not a security expert, so i might be missing something obvious here
The build server needs access to the internet to download dependencies. To protect the signing keys from theft (using them, an attacker could craft malicious app updates that look legit), the machine that knows the signing keys is not exposed to the internet.
1 Like
If you could steal the subkeys used to signed an app, you could modify the app and getting it signed the same
1 Like
The more i think about this the more i dont understand why somebody would put himself through having to sign the apps everytime
Just have a subkey generated in this air gapped machined and renew it once a week/month, and have the signing automated
Also, why is the trigger of the building (that takes longer than a day) done manually once a week? Why not building everytime a new release is done? or, in case theres is a cost associated with starting the building process, every time 10 new versions are queued?
From my point of view there is nothing gained security-wise and lots of troubles and delays for everybody involved
So you can guarantee that the update or build process can’t escape the VM and mess with the keys or the build machine or both?
What do you think you gain right now by signing random binaries on a machine without internet? You could be signing a virus as far as you can tell. As you said, any build could escape a VM and mess something and you would sign it the same
You can have a master key in an air gaped machine. That master key can sign a sub key that you have on the host and use to sign apps and have that signature validated
If something escape, they could get the subkeys that would be valid for a week (or whatever period you deem proper)
Even then, what? That signature only means that that binary was build on your build machine. Even if somebody get the subkeys and sign something random on the internet, how would they get installed on the phones?
I mean, if they have access to the keys, you have already been compromised. They could modify the binaries as well
Please read Public-key cryptography - Wikipedia. I think you’re confusing private and public keys.
Is not possible to derivate the private key from the public key. So any “attack” that modifies a package will be easily detected, as signatures don’t match.
Air gapping is used as a method to prevent private key leaking. Just that.
@pazos please learn about subkeys
If a hacker have access to the private subkeys (which are valid for a week), they can also access and modify the binaries that @Licaon_Kter takes to different machine to sign
Thus gaining nothing but troubles with the current security approach
Just have a subkey generated in this air gapped machined and renew it once a week/month, and have the signing automated
Unfortunately, Android doesn’t currently work this way. If a new version of an app is signed by a different key than the current version the OS will refuse to install the update.
At some point I expect Android to be updated to allow cross-signing, where the old key can sign the new key, which can then be used for updates. For security, this also requires a key revocation repository.
1 Like
I think the following design would address reasonable security concerns while automating the process.
- The build server maintains internet access as currently designed.
- The build server uploads built file to the signing server over rsync (or a similar protocol) to an incoming queue. The signing server sits behind a firewall that only allows rsync connections from the build server.
- The signing server automatically signs all APKs that come into the signing queue and places the signed versions in an outbound queue.
- The build server retrieves the signed APKs from the signing server via rsync and publishes to the repository.
If the build server is compromised, this could result in the signing and publishing of compromised APKs. However, that is exactly what would happen with the current design as the output APKs of the build server are not currently manually analyzed to detect compromises.
If someone were to compromise the build server it would be extremely unlikely they could exfiltrate the signing key from the signing server as the only access they have is write permissions to the incoming APK queue and read/write permissions to the outgoing APK queue. This is very close to the level of access the build server already has as it can write to whatever media is used to transfer files to the air-gapped machine and read files from the media that is used to bring them back. Barring a bug in rsync that would grant full remote root access, this ends up providing the same level of protection and can be fully automated.
3 Likes
Unfortunately, Android doesn’t currently work this way. If a new version of an app is signed by a different key than the current version the OS will refuse to install the update.
I knew this but forgot completely about it. Ouch!
Of course your solution seems very nice!
I would only change that instead of having files uploaded, have the key server inniciate, to avoid having a server exposed in the key machine
Im sure @Licaon_Kter time is better used somewhere else
Also, I think f-droid is part of reproducible builds effort as well, which will of course be a great help detecting compromises over time
2 Likes
I would only change that instead of having files uploaded, have the key server inniciate, to avoid having a server exposed in the key machine
That is a good suggestion.
1 Like
Regarding the Air Gap:
would it be an option to use two (dual ported) SAS drives?
Each of these connected to both computers but each only written by one machine and read by the other one.
Just for the transfer of two tar files, eventually even with no filesystem involved?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.