Re: Moving daily builds out of main debian-cloud-images project

[Ross Vandegrift <rvandegrift@debian.org>]

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