Hi Bastian, On Wed, Jul 28, 2021 at 07:56:56PM +0200, Bastian Blank wrote: > On Wed, Jul 28, 2021 at 10:04:39AM -0700, Ross Vandegrift wrote: > > You think we shouldn't trust the code in debian-cloud-images so readily, > > since a wider group of folks could commit malicious code. Updating the > > submodule automatically would expose us to the following risk: > > > > - someone commits malicious code to debian-cloud-images > > > > - the next nightly pipeline pulls that code without review and runs it > > > > - that provides access to run code on core machines, and could enable > > publishing daily builds with malicious contents. > > - that provides access to secrets used to upload and manage images at > vendors. > > Secrets defined in a project (debian-cloud-images-daily in this case) > are provided to all jobs it runs. So right now even a package installed > into the image could exfiltrate them, damn.
Yep - and the manual submodule updates aren't an effective defense against this risk unless every update is preceeded by an audit. Of every change in debian-cloud-images, and every package that it would install. In these circumstances, a buggy or malicious change has already been made in debian-cloud-images or a package it installs. So we're considering cases where our security model has already failed. Still, it does seem like it'd make the exfiltration easier. I don't think the risk clearly outweighs the benefits of having real daily builds. But I also don't think it's clearly worth it. > For AWS those secrets would only provides access to the daily stuff and > we at least have an audit log. On Azure we can neither differentiate > permissions between daily and release, nor is there a proper audit log. Wow - I don't know much about Azure, but is that true even if we had different subscriptions and principals for daily vs release? The lack of auditing is still disturbing though. Ross
