[linux-snap,bionic] trusted.gpg.d directly supports .asc keys without gnupg/agent/etc.
diff mbox series

Message ID 20190801030122.17271-1-xnox@ubuntu.com
State New
Headers show
Series
  • [linux-snap,bionic] trusted.gpg.d directly supports .asc keys without gnupg/agent/etc.
Related show

Commit Message

Dimitri John Ledkov Aug. 1, 2019, 3:01 a.m. UTC
As per apt-key manpage one can ship armored keys with .asc extension
since apt 1.4 (bionic and up). For prior releases, gpg1 exported
binary .gpg keys are supported. No need to install gnupg, run
gnupg-agent, or execute apt-key.

Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
---
 Sample build with this change in place is shown at:
 https://launchpad.net/~xnox/+snap/pc-kernel-bionic/+build/633218

 Makefile | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

Comments

Stefan Bader Aug. 12, 2019, 1:05 p.m. UTC | #1
On 01.08.19 05:01, Dimitri John Ledkov wrote:
> As per apt-key manpage one can ship armored keys with .asc extension
> since apt 1.4 (bionic and up). For prior releases, gpg1 exported
> binary .gpg keys are supported. No need to install gnupg, run
> gnupg-agent, or execute apt-key.
> 
> Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
> ---

Though maybe more complicated than it needs to but why change a running system?
If we remember till then, this is something for doing better in core20

-Stefan

>  Sample build with this change in place is shown at:
>  https://launchpad.net/~xnox/+snap/pc-kernel-bionic/+build/633218
> 
>  Makefile | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index b2c5ea5..00d3b25 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -93,14 +93,7 @@ all:
>  
>  	# Enable ppa:snappy-dev/image inside of the chroot and add the PPA's
>  	# public signing key to apt:
> -	# - gnugpg is required by apt-key
> -	# - gnugpg 2.x requires gpg-agent to be running
> -	# - procfs must be bind-mounted for gpg-agent
> -	# - running apt-key as a child process of gpg-agent --daemon stops the
> -	#   agent shortly after apt-key executes
> -	$(ENV) chroot chroot apt-get -y install gnupg
> -	mkdir --mode=0600 chroot/tmp/gnupg-home
> -	cat snappy-dev-image.asc | $(ENV) chroot chroot gpg-agent --homedir /tmp/gnupg-home --daemon apt-key add -
> +	cp snappy-dev-image.asc chroot/etc/apt/trusted.gpg.d/
>  	# Copy in the sources.list just before modifying it (on build envs this already
>  	# seems to be present, otherwise those would not fail).
>  	cp /etc/apt/sources.list chroot/etc/apt/sources.list
>
Dimitri John Ledkov Aug. 13, 2019, 12:54 p.m. UTC | #2
On Mon, 12 Aug 2019 at 14:05, Stefan Bader <stefan.bader@canonical.com> wrote:
>
> On 01.08.19 05:01, Dimitri John Ledkov wrote:
> > As per apt-key manpage one can ship armored keys with .asc extension
> > since apt 1.4 (bionic and up). For prior releases, gpg1 exported
> > binary .gpg keys are supported. No need to install gnupg, run
> > gnupg-agent, or execute apt-key.
> >
> > Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
> > ---
>
> Though maybe more complicated than it needs to but why change a running system?
> If we remember till then, this is something for doing better in core20
>

because installing and removing packages clobbers things.

It also shows lack of knowledge of apt snippets support which has been
around since xenial, and it means this will be copied over again
elsewhere.

This should not have been done like this in the first place, and is
poor engineering.


> -Stefan
>
> >  Sample build with this change in place is shown at:
> >  https://launchpad.net/~xnox/+snap/pc-kernel-bionic/+build/633218
> >
> >  Makefile | 9 +--------
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index b2c5ea5..00d3b25 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -93,14 +93,7 @@ all:
> >
> >       # Enable ppa:snappy-dev/image inside of the chroot and add the PPA's
> >       # public signing key to apt:
> > -     # - gnugpg is required by apt-key
> > -     # - gnugpg 2.x requires gpg-agent to be running
> > -     # - procfs must be bind-mounted for gpg-agent
> > -     # - running apt-key as a child process of gpg-agent --daemon stops the
> > -     #   agent shortly after apt-key executes
> > -     $(ENV) chroot chroot apt-get -y install gnupg
> > -     mkdir --mode=0600 chroot/tmp/gnupg-home
> > -     cat snappy-dev-image.asc | $(ENV) chroot chroot gpg-agent --homedir /tmp/gnupg-home --daemon apt-key add -
> > +     cp snappy-dev-image.asc chroot/etc/apt/trusted.gpg.d/
> >       # Copy in the sources.list just before modifying it (on build envs this already
> >       # seems to be present, otherwise those would not fail).
> >       cp /etc/apt/sources.list chroot/etc/apt/sources.list
> >
>
>
Dimitri John Ledkov Aug. 13, 2019, 12:56 p.m. UTC | #3
On Mon, 12 Aug 2019 at 14:05, Stefan Bader <stefan.bader@canonical.com> wrote:
>
> If we remember till then, this is something for doing better in core20
>

Speaking of core20, where are the unstable repos for all kernel snaps
building out of $devel series?

I do not see any repositories but bionic, hence targetted the only
place that appears to accept commits for linux-snap....

> >  Sample build with this change in place is shown at:
> >  https://launchpad.net/~xnox/+snap/pc-kernel-bionic/+build/633218
> >
> >  Makefile | 9 +--------
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index b2c5ea5..00d3b25 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -93,14 +93,7 @@ all:
> >
> >       # Enable ppa:snappy-dev/image inside of the chroot and add the PPA's
> >       # public signing key to apt:
> > -     # - gnugpg is required by apt-key
> > -     # - gnugpg 2.x requires gpg-agent to be running
> > -     # - procfs must be bind-mounted for gpg-agent
> > -     # - running apt-key as a child process of gpg-agent --daemon stops the
> > -     #   agent shortly after apt-key executes
> > -     $(ENV) chroot chroot apt-get -y install gnupg
> > -     mkdir --mode=0600 chroot/tmp/gnupg-home
> > -     cat snappy-dev-image.asc | $(ENV) chroot chroot gpg-agent --homedir /tmp/gnupg-home --daemon apt-key add -
> > +     cp snappy-dev-image.asc chroot/etc/apt/trusted.gpg.d/
> >       # Copy in the sources.list just before modifying it (on build envs this already
> >       # seems to be present, otherwise those would not fail).
> >       cp /etc/apt/sources.list chroot/etc/apt/sources.list
> >
>
>
Andy Whitcroft Aug. 13, 2019, 1:27 p.m. UTC | #4
On Tue, Aug 13, 2019 at 01:56:33PM +0100, Dimitri John Ledkov wrote:
> On Mon, 12 Aug 2019 at 14:05, Stefan Bader <stefan.bader@canonical.com> wrote:
> >
> > If we remember till then, this is something for doing better in core20
> >
> 
> Speaking of core20, where are the unstable repos for all kernel snaps
> building out of $devel series?
> 
> I do not see any repositories but bionic, hence targetted the only
> place that appears to accept commits for linux-snap....

So far we do not.  Until very recently we have had nowhere to publish them
even if we wanted to.  In principle since the uc18 case was made to not
have separate store 'sections' and to use tracks instead it might well
be possible to grovel for more tracks to publish something like this to.
But we currently do not do so.

-apw

Patch
diff mbox series

diff --git a/Makefile b/Makefile
index b2c5ea5..00d3b25 100644
--- a/Makefile
+++ b/Makefile
@@ -93,14 +93,7 @@  all:
 
 	# Enable ppa:snappy-dev/image inside of the chroot and add the PPA's
 	# public signing key to apt:
-	# - gnugpg is required by apt-key
-	# - gnugpg 2.x requires gpg-agent to be running
-	# - procfs must be bind-mounted for gpg-agent
-	# - running apt-key as a child process of gpg-agent --daemon stops the
-	#   agent shortly after apt-key executes
-	$(ENV) chroot chroot apt-get -y install gnupg
-	mkdir --mode=0600 chroot/tmp/gnupg-home
-	cat snappy-dev-image.asc | $(ENV) chroot chroot gpg-agent --homedir /tmp/gnupg-home --daemon apt-key add -
+	cp snappy-dev-image.asc chroot/etc/apt/trusted.gpg.d/
 	# Copy in the sources.list just before modifying it (on build envs this already
 	# seems to be present, otherwise those would not fail).
 	cp /etc/apt/sources.list chroot/etc/apt/sources.list