Hi Vincent,On Tue, Oct 1, 2013 at 4:04 PM, Vincent Bernat <firstname.lastname@example.org> wrote:
❦ 1 octobre 2013 20:30 CEST, Jimmy Kaplowitz <email@example.com> :
Yes. I would put the key under a Google HTTPS controlled domain (for
> 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?
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