What triggers a build of new app versions?

[sorenstoutner]

I think the following design would address reasonable security concerns while automating the process.

1. The build server maintains internet access as currently designed.
2. 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.
3. The signing server automatically signs all APKs that come into the signing queue and places the signed versions in an outbound queue.
4. 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.

[voidplayer]

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

[sorenstoutner]

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.

[frief]

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?