On Fri, Jun 28, 2019 at 10:14:48AM +0200, Henning Schild wrote:
Hi Henning,
Thanks for info. Sorry for the late reply. Was a little busy testing
some kas changes. I have some observations wrt ISAR and since all
of these is in the package feed creation part I will use this thread
to sum it up.
Hi All,
I have been using ISAR for quite some time and have observed the following
limitations/issues with it, mostly in the package feed creation part.
1. ISAR is not ready for handling password protected keys. Reprepro still
uses password prompt(default pinentry by the system). i.e we cannot automate
the password input to reprepro.
Description:
If we were to generate base-apt with a password protected gpg key then ISAR
build would fail unless the password is saved or entered in the pinentry
prompt.
Possible Solution:
We could possibly have a variable called BASE_REPO_PASSPHRASE which would
store the password for reprepro to use when signing. One issue here is that
reprepro uses the pinentry used by gpg agent. We would need to configure gpg
to loopback pinentry and pass in the password.
BASE_REPO_PASSPHRASE is mostly inspired by the RPM_GPG_PASSPHRASE in oe.
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/sign_rpm.bbclass
2. Reprepro implementation in ISAR doesnot take into consideration the
GNUPGHOME env.
Description:
Lets say the user has the .gnupg directory in a custom location
(ex: /opt/.gnupg) in his server and has set GNUPGHOME to /opt/.gnupg.
If you trigger a base-apt generation with ISAR in that server, then reprepro
command would fail(if there is no ~/.gnupg). reprepro in bitbake environment
would not know about the GNUPGHOME varible.
Possible solution:
One could add GNUPGHOME to BB_ENV_EXTRAWHITE and if is not empty can export it
to the environment where reprepro is called.
+ if [ ! -z ${GNUPGHOME} ]; then
+ export GNUPGHOME=${GNUPGHOME}
+ fi
3. ISAR repo signing would always use the default GPG-key of the system. One
cannot specify the key to use.
Description:
This is particularly tedious in case of CI. The user might have a server which
has n GPG keys in it and may wanted to sign the repo using the nth key. So one
would probably export the public key and set BASE_REPO_KEY=<path to the key>.
But reprepro would just use the default key in the system which might be a
completely different key.
Possible solution:
We could use the key ids instead of the key file itself. Something like
BASE_REPO_KEYID="6FA1B2F0416E3C24".
And the reprepro distributions file can be as below.
Codename: stretch
Architectures: i386 armhf arm64 amd64 source
Components: main
SignWith: "6FA1B2F0416E3C24"
Please let me know your thoughts on this. Meanwhile I will test some of my
changes for the above issues and post the patchset for review.
Thanks,
Vijai Kumar K