caniszczyk
commented
3 years ago This really doesn't have much to do with cloud native, -1
Closed eighthave closed 3 years ago
caniszczyk
commented
3 years ago This really doesn't have much to do with cloud native, -1
eighthave
commented
3 years ago I think I didn't explain it well enough then. Our central goal is to get secure release build infrastructure running on cloud infrastructure because it is so much more efficient. The blocker has always been the requirement for trusting the hardware, secure release build infrastructure is still often run in house on bare metal to keep the threat profile manageable.
We have a fully reproducible stack built with tools like ansible. This stack makes reproducible release builds. Anyone can verify a release by spinning up our stack in the cloud and running the build. This eliminates the need for in-house release build servers, pushing that to the cloud while providing improved security overall.
To put this in the context of recent events, the Dept of Defense could have spun up buildserver instances on the cloud of their choice to verify that the SolarWinds Orion release binaries match the source code.
Please fill out the details below to file a request for access to the CNCF Community Infrastructure Lab. Please note that access is targeted to people working on specific open source projects; this is not designed just to get your feet wet. The most important answer is the URL of the project you'll be working with. If you're looking to learn Kubernetes and related technologies, please try out Katacoda.
First and Last Name
Hans-Christoph Steiner
Email
hans@guardianproject.info or the team email: team@f-droid.org
Company/Organization
F-Droid
Job Title
Core contributor to F-Droid, hacker/researcher working on F-Droid, Guardian Project, Debian, Tor Project.
Project Title (i.e., summary of what do you want to do, not what is the name of the open source project you're working with)
Fully parallelized Android release/verification buildserver
Briefly describe the project (i.e., what is the detail of what you're planning to do with these servers?)
F-Droid runs automated build infrastructure for Android apps that uses disposable VMs to run each build. The server parts of the stack are managed with Ansible, the automation tools are written in Python. We will be replacing a lot of our custom code with Buildbot. Our goal is to run as much as possible in disposable, parallelized VMs for efficiency and security. This will serve as both a release build server as well as a "verification server" which reruns builds to ensure that the builds are 100% reproducible.
Is the code that you’re going to run 100% open source? If so, what is the URL or URLs where it is located? What is your association with that project?
F-Droid is a community-run, free software project in the spirit of Debian. We work to do as much as possible using only free open source code, even using free software donation services and contributing to ensuring the Android SDK remains 100% free software. We generally use the GPL and related licenses, and Apache-2.0 when a project needs to be widely integrated. We only use free software licenses.
These are the two key projects that we would like to run on these servers:
What kind of machines and how many do you expect to use (see: https://metal.equinix.com/product/servers/)?
Two c3.small instances would be quite useful. Having more cores and RAM would greatly speed up the work since it can be parallelized. We don't need more than 1TB of disk.
What operating system and networking are you planning to use?
Debian
Any other relevant details we should know about?