Security builds

Issue #2 new
Doug Freed created an issue

Provide a way for package maintainers (or security team) to submit builds that are completely hidden to everybody except them and security team, so they can tinderbox pre-release security fixes. This needs a way to get a list of security team members safely. Whether this will actually be usable is up to security team.

Comments (6)

  1. m

    As a user, I'd like to be able to offer a VM on my workstation as a tinderbox cluster node. If that were to be possible, you would need to consider whether or not jobs for security builds could be dispatched to a given cluster node. A node might be run by a non-developer. Or it might be run by a developer, but not one on the security team. Or perhaps it gets on an infra-maintained node.

    (I suspect a node controlled by a member of the security team is probably best, in that case; you still get the tinderbox semantics, interface and workflow, just with a bit more control over where the work is done, and perhaps a bit slower.)

  2. Whissi

    If there's any chance of leaking non-publicly available code when using the tinderbox, security nor any maintainer preparing a pre-release won't be allowed to use that setup.

  3. Doug Freed reporter

    The initial setup will be completely accessible to only me, and the use of full VMs means that authorized users will only have access to their own stuff, and nobody else's. Thus, in order to use the initial setup, security team would need to trust that I'm not going to leak anything. If/when the setup is expanded to include capacity that somebody other than me has control over (see issue #11), a flag can be implemented to indicate what capacity is trusted to run security builds.

    As an alternative, as one of the goals of this project is to be something anybody can deploy to their own environment (assuming their environment meets certain requirements), security team could require that security builds run on Gentoo Infra managed hardware.

  4. Log in to comment