Re: Discussion: Base-apt features

[Vijai Kumar K <vijaikumar.kanagarajan@gmail.com>]

On Wed, Sep 25, 2019 at 10:12:41AM +0200, Baurzhan Ismagulov wrote:
> Hello Vijai Kumar,
> 
> thanks for summarizing.
> 
> On Wed, Sep 25, 2019 at 01:11:22PM +0530, Vijai Kumar K wrote:
> > 1. Support for adding source packages.
> > 2. Support for using password protected keys.
> 
> Yes, I think those are necessary use cases.
> 
> 
> > 3. Support for specifying the signing key.
> > 
> > Right now, the signing mechanism uses the default gpg key of the system.
> > This is problematic in many ways. Especially for CI. In the current
> > implementation, eventhough we specify the key, we are not really using it.
> 
> This is what I'm currently wondering. What do we need to cover signed base-apt?
> Is the following enough?
> 
> 1. debootstrap succeeds.
> 2. apt-get update in the rootfs succeeds.
> 
> IIUC, (1) should be covered as of next 006a6ed "u-boot-custom: Add control for
> u-boot-tools package build". (2) seems to be covered in ibr/next fb61019
> "scripts: Enable gnupg in ci_build.sh" (subject to rebasing). This has to be
> verified, though (feedback welcome). If proven correct, would we be "really
> using it"?
> 

The problem lies here.
https://github.com/ilbers/isar/blob/006a6ed75286710957b309aa571613d1935e4663/meta/recipes-devtools/base-apt/base-apt.bb#L21
By using "SignWith: yes", we are asking reprepro to use the default key of the system.
BTW, there is a possibility that the key we specified using BASE_REPO_KEY might not be
the default key of the system. 

This was the case in my local jenkins build. I have multiple gpg keys, and have configured 
one of them to be the default key. If I exercise repo signing in my system, then the repo 
would always be signed with my default key and not with the key I gave in BASE_REPO_KEY.

Below is the link to the mailing list discussion.
https://groups.google.com/d/msg/isar-users/CAVHJCuFxRo/WzbRjKdYBwAJ

> 
> > 4. Support for adding packages only to base-apt.
> > 
> > Sometimes, we might need a package to be present in base-apt but not in
> > the target yet. Things like dev & dbg packages. It would be good if we
> > have something like BASE_APT_INSTALL which contains the list which would
> > be populated only in base-apt.
> 
> Sounds useful, also for stuff like strace, optional gcc libs, etc.
> Additionally, we may want to download all binary packages of the source
> packages we need (for the requested arches and distros only). That would cover
> dev and dbg.
> 
> 
> > 5. Refactoring code to consolidate reprepro calls.
> 
> I'd suggest to evaluate other tools and libs like python-apt and / or aptly.
> After looking at Acquire::By-Hash use cases in more detail, I've seen that we
> do need it. According to Jan, it isn't supported by reprepro. I think in the
> long term, we'll have to use python-apt and touch bitbake to get everything
> right.
> 

Thanks for the info. I have been wondering regarding the need to move out of
reprepo. This gives some fair amount of detail. Let me also have a look at
the other tools.

> 
> With kind regards,
> Baurzhan.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20190925081241.bmcblmlsax6xb4i4%40yssyq.m.ilbers.de.