| 24 Sep 2020 |
 _hc | I think the best approach would be to build the VM stack from scratch using buildbot | 13:43:42 |
| _hc | the VM management stack that is | 13:43:55 |
 wb9688 | Why would a build server need network access? | 13:48:04 |
| wb9688 | Also, I've personally never experienced network issues with libvirt, but I haven't used it in F-Droid | 13:48:39 |
 uniq | vagrant-libvirt networking is funky when you do nested setups | 13:49:58 |
 cdesai | I hadn't seen any issues with libvirt/kvm on the calyx server when I was routinely monitoring it. | 13:51:17 |
| uniq | @cdesai did you use libvirt.management_network_address | 13:58:44 |
| uniq | https://gitlab.com/fdroid/fdroid-cfarm-bootstrap/-/blob/master/roles/debian-vagrant-guest-libvirt-kvm/templates/Vagrantfile.j2#L55 | 13:58:51 |
| cdesai | I used https://gitlab.com/cde/fdroid-bootstrap-buildserver/-/tree/calyx | 13:59:46 |
| cdesai | so yes | 14:01:33 |
| cdesai | the server itself is also a VM, but not libvirt directly | 14:02:55 |
| uniq | that's just bootstrap buildserver, that cfarm-bootstrap starts a vagrant managed vm inside a vagrant managed vm | 14:03:08 |
| _hc | wb9688: lots of dependencies are downlaoded from the allowed maven repos, that's what the network is used for | 14:15:21 |
| wb9688 | uniq: Oh, didn't realize you were also using Vagrant for libvirt. Vagrant (or Hashicorp products in general) is just so damn buggy for me that I personally wouldn't even consider using them anymore | 14:25:49 |
| wb9688 | _hc: Ah. Couldn't I in theory make some Gradle plugin that fetches some malicious perhaps proprietary code from another server? Or do you prevent that in some other way? | 14:26:49 |
 Bubu | wb9688: there are definitely loopholes | 14:37:11 |
| Bubu | though I think the plugin would either need to be in the apps source repo or published to some whitelisted plugin repo | 14:37:43 |
| Bubu | though there's a 'apply from: <url>' thing, not sure if we currently catch that | 14:38:52 |
| Bubu | (we should) | 14:39:15 |
| wb9688 | Bubu: That doesn't matter if the plug-in is able to download random stuff | 14:40:14 |
| Bubu | wb9688: it matters because it's traceable this way | 14:40:32 |
| wb9688 | Bubu: Not really, certain repos allow replacing the jar within a certain amount of time | 14:41:52 |
| Bubu | yes, this is problematic and the aim is to not allow those. | 14:42:30 |
| Bubu | afaik mavencentral and jcenter don't allow this | 14:42:57 |
| _hc | we've sketched out a proxy solution for strict enforcement, just needs someone to implement it s#418 | 14:45:35 |
![@freenode_[gibot]:matrix.org](./avatar/%5Bgibot%5D) [gibot] | [server] #418: auditing, caching proxy on the host for `fdroid b… - https://gitlab.com/fdroid/fdroidserver/issues/418 | 14:45:38 |
| wb9688 | Bubu: Except you do have it: JitPack, which NewPipe uses, allows doing that within 7 days, see https://jitpack.io/docs/#immutable-artifacts | 14:49:12 |
| _hc | wb9688: Bubu uniq jochensp izzy grote cdesai mimi89999 wb9688 Mathijs (F-droid) and since today is meeting day, here's a quick update: I just finished putting together a large whitelabel+mirrors+repos+repomaker proposal which will be part of a large 3 year grant application that I was invited to join. More info to follow if it gets funded | 17:05:32 |
| cdesai | That sounds amazing | 17:06:01 |
| _hc | oh yeah, panickit too | 17:06:17 |
