Re: Compute Engine images & GPG key

Hm. Since it seems HTTPS support for APT is split into a non-default apt-transport-https package, I'm not planning to make the Google repository's sources.list.d line use https; the shell version has a short enough remaining lifetime that it doesn't seem useful to add another build-time package dependency to it, or to act differently at build time based on the presence of that package. (Hopefully the lifetime of the need to pull in Google's repository is also reasonably short.) I can reconsider if desired, of course.

I'm still going to use HTTPS to pull in the GPG key unless/until we decide to put it in Github.

- Jimmy

On Thu, Oct 3, 2013 at 11:13 AM, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:

Hi Vincent,

On Tue, Oct 1, 2013 at 4:04 PM, Vincent Bernat <bernat@debian.org> wrote:

❦ 1 octobre 2013 20:30 CEST, Jimmy Kaplowitz <jkaplowitz@google.com> :

> Quick advice-seeking email from me:
>
> Google recently started signing the apt repository from which we serve
> certain packages used in the Google Compute Engine image build process
> (google-startup-scripts, google-compute-daemon, image-bundle, and recently
> also gcutil).
>
> We do want to get these packages into Debian where appropriate so that the
> bulid can pull solely from the Debian archive, but adding an unknown GPG
> signature broke our current build. Doh! Thank you, Murphy's Law. :)
>
> I think the best short-term way to allow properly authenticated builds is
> to put the Google apt repository's public key somewhere in the github tree,
> apt-key add it before we pull in our repository, but be sure to apt-key
> remove it when we remove our repository.
>
> Does this sound sensible?

Yes. I would put the key under a Google HTTPS controlled domain (for
example, on the same server hosting the APT repository if it is also
able to serve it with HTTPS). This would match what is done by most
third-party repositories.

It turns out we're already serving it via HTTPS as well as HTTP. I'll switch the code to use HTTPS to gain the benefit of certificate checking and encryption, but is it really preferred to fetch the key from the repository server right before adding it in an automated process? I was hoping to make compromising the process more difficult by including the public key in the github repository, at least until we are able to drop this repository from the standard Debian build.

Regardless, using the method you suggest will allow me to fix the build which broke when we signed our repository, so thanks!

- Jimmy