https://gitlab.com/fdroid/fdroiddata/-/commits/master/metadata/com.ichi2.anki.yml
Theres a new versions for a 5 days and still not a build has been triggered
Does new versions delay the build of the first one?
Last cycle was started on Sep 15 so any newer versions are…newer.
Bookmark, refresh (timezone is UTC): F-Droid Monitor
/LE: updated link
I see. And what triggers the cycles? Is it scheduled or manually launched?
Manually, a human is involved, this is not a CI
I see
And what triggers the human? Is it predictable?
Missing a cycle is waiting a week for an update
Btw, i saw it is building now 
Although i see the last build took 2/3 of a day, so i probably wont finisht till night hours
Thanks for launching it!
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