Additional debian repo with different pgp key

Additional debian repo with different pgp key

[Andreas Reichel]

Hi,

I have a problem with using a separate docker repository together with
its key.

As far as I understood it, I have to do the following:

1st, create a list file which mentions the docker repository:

So I created a docker-stretch.list, where I have the line

----
deb	http://download.docker.com/linux/debian	stretch	stable
----

This file is added via

----
DISTRO_APT_SOURCES_append = " conf/distro/docker-stretch.list"
----

which is working.

Then I add the `docker-ce` package to `IMAGE_PREINSTALL` which does not
work because the package is untrusted. Therefore I have to import the
pgp key, which I should be able to do with

2nd: add the key to apt keys:

----
DISTRO_APT_KEYS_append = " https://download.docker.com/linux/debian/gpg;sha256sum=1500c1f56fa9e26b9b8f42452a553675796ade0807cdce11975eb98170b3a570"
----

However, then I get the following error:

----
| DEBUG: Executing shell function do_generate_keyring
| gpg: WARNING: unsafe permissions on homedir '/build/build/downloads'
| gpg: keybox '/build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg' created
| gpg: can't open '/build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/linux/debian/gpg': No such file or directory
| gpg: Total number processed: 0
| WARNING: exit code 2 from a shell command.

----

It seems, that the last part of the URL is appended to the working
directory. But the resulting directory does not exist.  What is the
intended course of action for this standard scenario to use another
debian repo for image building?

Last patch I saw on next was about local keys. But standard should be
remote keys with URI I think, because every repo that needs one should
provide one this way... am I wrong?

vG
Andreas

-- 
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas.Reichel@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

Re: Additional debian repo with different pgp key

[Henning Schild]

On Fri, 15 Feb 2019 16:16:10 +0100
"[ext] Andreas Reichel" <andreas.reichel.ext@siemens.com> wrote:

> Hi,
> 
> I have a problem with using a separate docker repository together with
> its key.
> 
> As far as I understood it, I have to do the following:
> 
> 1st, create a list file which mentions the docker repository:
> 
> So I created a docker-stretch.list, where I have the line
> 
> ----
> deb	http://download.docker.com/linux/debian
> stretch	stable ----
> 
> This file is added via
> 
> ----
> DISTRO_APT_SOURCES_append = " conf/distro/docker-stretch.list"
> ----
> 
> which is working.
> 
> Then I add the `docker-ce` package to `IMAGE_PREINSTALL` which does
> not work because the package is untrusted. Therefore I have to import
> the pgp key, which I should be able to do with
> 
> 2nd: add the key to apt keys:
> 
> ----
> DISTRO_APT_KEYS_append = "
> https://download.docker.com/linux/debian/gpg;sha256sum=1500c1f56fa9e26b9b8f42452a553675796ade0807cdce11975eb98170b3a570"
> ----
> 
> However, then I get the following error:
> 
> ----
> | DEBUG: Executing shell function do_generate_keyring
> | gpg: WARNING: unsafe permissions on homedir '/build/build/downloads'
> | gpg: keybox
> '/build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg'
> created | gpg: can't open
> '/build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/linux/debian/gpg':
> No such file or directory | gpg: Total number processed: 0 | WARNING:
> exit code 2 from a shell command.
> 
> ----
> 
> It seems, that the last part of the URL is appended to the working
> directory. But the resulting directory does not exist.  What is the
> intended course of action for this standard scenario to use another
> debian repo for image building?
> 
> Last patch I saw on next was about local keys. But standard should be
> remote keys with URI I think, because every repo that needs one should
> provide one this way... am I wrong?

Yes every repo we get from the internet most likely also has its key
there. With the recent introduction of a file:// based signed repo
there was a patch. What happens if you revert af983a13b, i guess that
may have caused your issue.

I think that is one of our hidden features that never had a test-case,
and silently broke ... We need a testcase for adding an extra repo and
installing stuff from it.

Henning

> vG
> Andreas
> 

[PATCH 0/1] Fix remote key fetching apt keyring

[Andreas J. Reichel]

From: Andreas Reichel <andreas.reichel.ext@siemens.com>

Since my last mail was not answered, but this is an important topic,
here is a patch that shows what the problem is.

If we fetch the user apt key from remote, we need the basename,
if we fetch it locally we need the absolute path...

While this might not be the best way to fix this, it works as good
as the rest of this code...

At least it fixes Isar again up to adding the key to the keyring.

But this still does not fix the next problem with the docker-ce key:

| I: Running command: debootstrap --arch arm64 --foreign --verbose --variant=minbase --include=locales --components=main,contrib,non-free --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg stretch /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs http://ftp.debian.org/debian
| I: Retrieving InRelease
| I: Retrieving Release
| I: Retrieving Release.gpg
| I: Checking Release signature
| E: Release signed by unknown key (key id EF0F382A1A7B6500)

So something additionally must be done. Since I am not an expert on
debian keyring/debootstrap and dpkg signing I will try to find a
solution but maybe somebody has a good idea already?

Andreas Reichel (1):
  Fix path to user gpg-keys

 meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.20.1

[PATCH 1/1] Fix path to user gpg-keys

[Andreas J. Reichel]

From: Andreas Reichel <andreas.reichel.ext@siemens.com>

If the key is fetched from remote (currently http, https),
use the basename, otherwise, use the absolute path.

Signed-off-by: Andreas Reichel <andreas.reichel.ext@siemens.com>
---
 meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
index 234d339..25133be 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
@@ -40,7 +40,10 @@ python () {
         d.setVar("DEBOOTSTRAP_KEYRING", "--keyring ${APTKEYRING}")
         for key in distro_apt_keys.split():
             url = urlparse(key)
-            filename = ''.join([wd, url.path])
+            if "https://" in key or "http://" in key:
+                filename = os.path.basename(url.path)
+            else:
+                filename = ''.join([wd, url.path])
             d.appendVar("SRC_URI", " %s" % key)
             d.appendVar("APTKEYFILES", " %s" % filename)
     if bb.utils.to_boolean(d.getVar('ISAR_USE_CACHED_BASE_REPO')):
-- 
2.20.1

Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Jan Kiszka]

On 20.02.19 12:21, [ext] Andreas J. Reichel wrote:
> From: Andreas Reichel <andreas.reichel.ext@siemens.com>
> 
> Since my last mail was not answered, but this is an important topic,
> here is a patch that shows what the problem is.
> 
> If we fetch the user apt key from remote, we need the basename,
> if we fetch it locally we need the absolute path...
> 
> While this might not be the best way to fix this, it works as good
> as the rest of this code...
> 
> At least it fixes Isar again up to adding the key to the keyring.
> 
> But this still does not fix the next problem with the docker-ce key:
> 
> | I: Running command: debootstrap --arch arm64 --foreign --verbose --variant=minbase --include=locales --components=main,contrib,non-free --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg stretch /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs http://ftp.debian.org/debian
> | I: Retrieving InRelease
> | I: Retrieving Release
> | I: Retrieving Release.gpg
> | I: Checking Release signature
> | E: Release signed by unknown key (key id EF0F382A1A7B6500)
> 
> So something additionally must be done. Since I am not an expert on
> debian keyring/debootstrap and dpkg signing I will try to find a
> solution but maybe somebody has a good idea already?
> 

Baurzhan, Maxim, any idea?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Andreas Reichel]

On Wed, Feb 20, 2019 at 12:27:15PM +0100, Jan Kiszka wrote:
> On 20.02.19 12:21, [ext] Andreas J. Reichel wrote:
> > From: Andreas Reichel <andreas.reichel.ext@siemens.com>
> > 
> > Since my last mail was not answered, but this is an important topic,
> > here is a patch that shows what the problem is.
> > 
> > If we fetch the user apt key from remote, we need the basename,
> > if we fetch it locally we need the absolute path...
> > 
> > While this might not be the best way to fix this, it works as good
> > as the rest of this code...
> > 
> > At least it fixes Isar again up to adding the key to the keyring.
> > 
> > But this still does not fix the next problem with the docker-ce key:
> > 
> > | I: Running command: debootstrap --arch arm64 --foreign --verbose --variant=minbase --include=locales --components=main,contrib,non-free --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg stretch /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs http://ftp.debian.org/debian
> > | I: Retrieving InRelease
> > | I: Retrieving Release
> > | I: Retrieving Release.gpg
> > | I: Checking Release signature
> > | E: Release signed by unknown key (key id EF0F382A1A7B6500)
> > 
> > So something additionally must be done. Since I am not an expert on
> > debian keyring/debootstrap and dpkg signing I will try to find a
> > solution but maybe somebody has a good idea already?
> > 
> 
> Baurzhan, Maxim, any idea?
> 
I foudn a solution, one has to trust the key manually:

The following snippet can do this:

gpg --keyring build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg --list-keys --with-colons | \
    sed -E -n -e 's/^fpr:::::::::([0-9A-F]+):$/\1:6:/p' | \
    gpg --import-ownertrust --keyring build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg

I will try and write a patch for this.

Andreas
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

-- 
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas.Reichel@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Andreas Reichel]

On Wed, Feb 20, 2019 at 12:36:44PM +0100, Andreas Reichel wrote:
> > > 
> > > | I: Running command: debootstrap --arch arm64 --foreign --verbose --variant=minbase --include=locales --components=main,contrib,non-free --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg stretch /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs http://ftp.debian.org/debian
> > > | I: Retrieving InRelease
> > > | I: Retrieving Release
> > > | I: Retrieving Release.gpg
> > > | I: Checking Release signature
> > > | E: Release signed by unknown key (key id EF0F382A1A7B6500)
> > > 
> > > So something additionally must be done. Since I am not an expert on
> > > debian keyring/debootstrap and dpkg signing I will try to find a
> > > solution but maybe somebody has a good idea already?
> > > 
> > 
> > Baurzhan, Maxim, any idea?
> > 
> I foudn a solution, one has to trust the key manually:
> 
> The following snippet can do this:
> 
> gpg --keyring build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg --list-keys --with-colons | \
>     sed -E -n -e 's/^fpr:::::::::([0-9A-F]+):$/\1:6:/p' | \
>     gpg --import-ownertrust --keyring build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg
> 
> I will try and write a patch for this.
> 
Well the idea was good, but there is another problem... obviously the
key debootstrap complains about is NOT the docker key... it is even not
inside the keyring. It seems debootstrap only uses a keyring with only
one key now which cannot work if we want to ADD a repo with a
corresponding key.

----
builder@bdf0e3b84f79:/build$ gpg --keyring build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg --list-keys
build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg
-------------------------------------------------------------------------
pub   rsa4096 2017-02-22 [SCEA]
      9DC858229FC7DD38854AE2D88D81803C0EBFCD88
uid           [ultimate] Docker Release (CE deb) <docker@docker.com>
sub   rsa4096 2017-02-22 [S]
----

But at least we can see the change to ultimate trust worked ;)

Andreas

> Andreas

> > Jan
> > 
> > -- 
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> 
> -- 
> Andreas Reichel
> Dipl.-Phys. (Univ.)
> Software Consultant
> 
> Andreas.Reichel@tngtech.com, +49-174-3180074
> TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
> Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
> Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082
> 

-- 
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas.Reichel@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Maxim Yu. Osipov]

On 2/20/19 12:27 PM, Jan Kiszka wrote:
> On 20.02.19 12:21, [ext] Andreas J. Reichel wrote:
>> From: Andreas Reichel <andreas.reichel.ext@siemens.com>
>>
>> Since my last mail was not answered, but this is an important topic,
>> here is a patch that shows what the problem is.
>>
>> If we fetch the user apt key from remote, we need the basename,
>> if we fetch it locally we need the absolute path...
>>
>> While this might not be the best way to fix this, it works as good
>> as the rest of this code...
>>
>> At least it fixes Isar again up to adding the key to the keyring.
>>
>> But this still does not fix the next problem with the docker-ce key:
>>
>> | I: Running command: debootstrap --arch arm64 --foreign --verbose 
>> --variant=minbase --include=locales --components=main,contrib,non-free 
>> --keyring 
>> /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg 
>> stretch 
>> /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs http://ftp.debian.org/debian 
>>
>> | I: Retrieving InRelease
>> | I: Retrieving Release
>> | I: Retrieving Release.gpg
>> | I: Checking Release signature
>> | E: Release signed by unknown key (key id EF0F382A1A7B6500)
>>
>> So something additionally must be done. Since I am not an expert on
>> debian keyring/debootstrap and dpkg signing I will try to find a
>> solution but maybe somebody has a good idea already?
>>
> 
> Baurzhan, Maxim, any idea?

Strange...I thought that commit af983a13 fixes the reported problem
When testing my patch signing base-apt I've tried both - remote keys 
(used by Raspberry Pi target) and local key.

@Andreas
I was really busy these days - I'll look on your problem ASAP.

Thanks,
Maxim.

> Jan
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Andreas Reichel]

On Wed, Feb 20, 2019 at 12:58:09PM +0100, Maxim Yu. Osipov wrote:
> On 2/20/19 12:27 PM, Jan Kiszka wrote:
> > On 20.02.19 12:21, [ext] Andreas J. Reichel wrote:
> > > From: Andreas Reichel <andreas.reichel.ext@siemens.com>
> > > 
> > > Since my last mail was not answered, but this is an important topic,
> > > here is a patch that shows what the problem is.
> > > 
> > > If we fetch the user apt key from remote, we need the basename,
> > > if we fetch it locally we need the absolute path...
> > > 
> > > While this might not be the best way to fix this, it works as good
> > > as the rest of this code...
> > > 
> > > At least it fixes Isar again up to adding the key to the keyring.
> > > 
> > > But this still does not fix the next problem with the docker-ce key:
> > > 
> > > | I: Running command: debootstrap --arch arm64 --foreign --verbose
> > > --variant=minbase --include=locales
> > > --components=main,contrib,non-free --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg
> > > stretch
> > > /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs
> > > http://ftp.debian.org/debian
> > > 
> > > | I: Retrieving InRelease
> > > | I: Retrieving Release
> > > | I: Retrieving Release.gpg
> > > | I: Checking Release signature
> > > | E: Release signed by unknown key (key id EF0F382A1A7B6500)
> > > 
> > > So something additionally must be done. Since I am not an expert on
> > > debian keyring/debootstrap and dpkg signing I will try to find a
> > > solution but maybe somebody has a good idea already?
> > > 
> > 
> > Baurzhan, Maxim, any idea?
> 
> Strange...I thought that commit af983a13 fixes the reported problem
> When testing my patch signing base-apt I've tried both - remote keys (used
> by Raspberry Pi target) and local key.
> 
> @Andreas
> I was really busy these days - I'll look on your problem ASAP.
> 
Meanwhile I found, that there are several implementation problems and one design
problem:

* When I tried to add keys to the corresponding gpg key rings I found
  that the trust DB is always inside the home directory given to gpg,
  i.e. inside the DL_DIR. This way new keys are always unknown if apt
  has a look at it since apt does not know anything about what we tell
  gpg.

  Also adding My keyrings to etc/apt/trusted.gpg.d/ did not work.
  My first example in thep revious email was incorrect since I did not
  specify --no-default-keyring and thus, inside my build environment,
  gpg created a ~/.gnupg/trustdb

  This way, we have host pollution and hard to control host-target mixtures.

* I managed to get the first bootstrap working, but afterwards, when
  apt tries to install docker dependencies, it does not work again since
  keys are not there and/or untrusted.

Most problematic is the way things are implemented. I already had a
discussion with Hening:

What is done in ISAR: The key management is done with gpg outside of the
rootfs and everything is being tried to put together manually which
eventually fails in my case and is difficult to fix.

Repos are added manually, lists are parsed manually, etc...

What should be done: There are several tools that are already provided
by Debian:

1. apt-key

Isar should just download the keys provided without manually adjusting
any keyring.

Also, apt-key should be called in the corresponding root file systems.
The idea is that all keys are fetched to a common location like

TMPDIR/aptkeys

Afterwards in every root file system, apt-key can be used to import
these keys.

2. Debian's `add-apt-repository`

This command is available since Jessie in the
'software-properties-common' package and should be used to automatically
add source list entries.

The steps should work as follows:

	a) debootstrap with a base repo, use key if needed
	   maybe destinguish between upstream and local
	b) chroot into the new rootfs,
	   use apt-key and add-apt-epository
	   use apt-get update
           install the rest.
	c) also for cross chroot-target

Thus the whole thing should be refactored. Since I am already on it I
would like to do so and propose a patch for this within the next days.

Thanks,
Andreas

> Thanks,
> Maxim.
> 
> > Jan
> > 
> 
> 
> -- 
> Maxim Osipov
> ilbers GmbH
> Maria-Merian-Str. 8
> 85521 Ottobrunn
> Germany
> +49 (151) 6517 6917
> mosipov@ilbers.de
> http://ilbers.de/
> Commercial register Munich, HRB 214197
> General Manager: Baurzhan Ismagulov

-- 
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas.Reichel@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

Re: [PATCH 0/1] Fix remote key fetching apt keyring

[Henning Schild]

On Wed, 20 Feb 2019 12:21:32 +0100
"[ext] Andreas J. Reichel" <andreas.reichel.ext@siemens.com> wrote:

> From: Andreas Reichel <andreas.reichel.ext@siemens.com>
> 
> Since my last mail was not answered, but this is an important topic,
> here is a patch that shows what the problem is.
> 
> If we fetch the user apt key from remote, we need the basename,
> if we fetch it locally we need the absolute path...
> 
> While this might not be the best way to fix this, it works as good
> as the rest of this code...
> 
> At least it fixes Isar again up to adding the key to the keyring.
> 
> But this still does not fix the next problem with the docker-ce key:
> 
> | I: Running command: debootstrap --arch arm64 --foreign --verbose
> --variant=minbase --include=locales
> --components=main,contrib,non-free
> --keyring /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg
> stretch /build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/rootfs
> http://ftp.debian.org/debian | I: Retrieving InRelease | I:
> Retrieving Release | I: Retrieving Release.gpg | I: Checking Release
> signature | E: Release signed by unknown key (key id EF0F382A1A7B6500)
> 
> So something additionally must be done. Since I am not an expert on
> debian keyring/debootstrap and dpkg signing I will try to find a
> solution but maybe somebody has a good idea already?

A hack that will probably work is a recipe that fetches all the debs
with unpack=false and overrides do_build with true. You will have
many .debs in your WORKDIR and they will get into our repo as if you
built them ;). Now you can sign them with your own key, or forget about
signatures alltogether.

Henning

> Andreas Reichel (1):
>   Fix path to user gpg-keys
> 
>  meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

Re: Additional debian repo with different pgp key

[Maxim Yu. Osipov]

Hi Andreas.

This is known problem - I've faced it when tried to add signed repo
https://obs.linaro.org/project/show/linaro-overlay-stretch (this is not 
full debian repo - it just contains some linaro packages).

DISTRO_APT_KEYS doesn't fit this requirement as is used only as primary 
repo and passed directly to debootstrap overriding default keyring.

--keyring=KEYRING
         Override the default keyring for the distribution being 
bootstrapped, and use KEYRING to check signatures of retrieved Release 
files.

Patches are welcomed.

Maxim.

On 2/15/19 4:16 PM, Andreas Reichel wrote:
> Hi,
> 
> I have a problem with using a separate docker repository together with
> its key.
> 
> As far as I understood it, I have to do the following:
> 
> 1st, create a list file which mentions the docker repository:
> 
> So I created a docker-stretch.list, where I have the line
> 
> ----
> deb	http://download.docker.com/linux/debian	stretch	stable
> ----
> 
> This file is added via
> 
> ----
> DISTRO_APT_SOURCES_append = " conf/distro/docker-stretch.list"
> ----
> 
> which is working.
> 
> Then I add the `docker-ce` package to `IMAGE_PREINSTALL` which does not
> work because the package is untrusted. Therefore I have to import the
> pgp key, which I should be able to do with
> 
> 2nd: add the key to apt keys:
> 
> ----
> DISTRO_APT_KEYS_append = " https://download.docker.com/linux/debian/gpg;sha256sum=1500c1f56fa9e26b9b8f42452a553675796ade0807cdce11975eb98170b3a570"
> ----
> 
> However, then I get the following error:
> 
> ----
> | DEBUG: Executing shell function do_generate_keyring
> | gpg: WARNING: unsafe permissions on homedir '/build/build/downloads'
> | gpg: keybox '/build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/apt-keyring.gpg' created
> | gpg: can't open '/build/build/tmp/work/debian-stretch-arm64/isar-bootstrap-target/linux/debian/gpg': No such file or directory
> | gpg: Total number processed: 0
> | WARNING: exit code 2 from a shell command.
> 
> ----
> 
> It seems, that the last part of the URL is appended to the working
> directory. But the resulting directory does not exist.  What is the
> intended course of action for this standard scenario to use another
> debian repo for image building?
> 
> Last patch I saw on next was about local keys. But standard should be
> remote keys with URI I think, because every repo that needs one should
> provide one this way... am I wrong?
> 
> vG
> Andreas
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov

Re: Additional debian repo with different pgp key

[Andreas Reichel]

On Fri, Feb 15, 2019 at 04:16:10PM +0100, Andreas Reichel wrote:
> Hi,
> 

I have solved it :D It's working finally. I am preparing 1st working
patches now...

> I have a problem with using a separate docker repository together with
> its key.
> 
> 
> vG
> Andreas
> 
> -- 
> Andreas Reichel
> Dipl.-Phys. (Univ.)
> Software Consultant
> 
> Andreas.Reichel@tngtech.com, +49-174-3180074
> TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
> Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
> Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082
> 

-- 
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas.Reichel@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082