rootdir support: inconsistent path handling for repos and their fingerprints

[neirbowj]

Summary

When running pkg with the --rootdir option, it loads repo configuration from outside the root and then attempts to load fingerprints from inside the root.

Details

How to reproduce

1. Create /usr/local/etc/pkg/repos/example.conf

   FreeBSD: { enabled: no }
   example: {
       url : "https://pkg.example.com/${ABI}",
       enabled : yes,
       signature_type : "FINGERPRINTS",
       fingerprints : "/usr/local/etc/pkg/keys"
   }
   

2. Create /usr/local/etc/pkg/keys/trusted/example

   function: "sha256"
   fingerprint: "digest goes here"
   

3. Populate a fresh root from a base tarball

   zfs create zroot/usr/jail/example
   tar xJf base.txz -C /usr/jail/example
   

4. Install a package

   pkg -r /usr/jail/example install zsh
   

Expected behavior

The package is installed under the root from the custom repo defined outside the root.

Observed behavior

Updating example repository catalogue...
Fetching meta.conf: 100%    178 B   0.2kB/s    00:01
Fetching data.pkg: 100%   31 MiB   1.3MB/s    00:25
pkg: Error opening the trusted directory /usr/local/etc/pkg/keys/trusted
pkg: Error loading trusted certificates
example repository is up to date.
All repositories are up to date.
pkg: Repository example cannot be opened. 'pkg update' required
pkg: No packages available to install matching 'zsh' have been found in the repositories

[kevemueller]

Hi John,

the handling of fingerprints in pkg with rootdir is the same as with other package managers, e.g. apk. The general idea is that once you are in the rootdir, pkg running outside should behave the same as pkg would do running inside.

So in fact, the inconsistency is the other way round. When given a rootdir, the configuration files from outside should not in fact be consulted at all. You will observe that once you set a configuration file inside the rootdir, that becomes effective and any repository defined only outside becomes unavailable. Very counterintuitive.

It is even more confusing once you install pkg on a completely different prefix, e.g. /opt/pkg/. Then the compile time prefix is used as the default also inside the rootdir, where it most likely does not make sense at all. So if the outside pkg was compiled with /opt/pkg prefix, it will try to look for rootdir/opt/pkg/etc/pkg for its configuration, whereas most likely the rootdir uses a stock pkg prefix of /usr/local and expects configuration in rootdir/usr/local/etc/pkg.

I guess the current choices are made both on evolutionary as well as convenience basis. Only compiling the list of expected behaviour is a task on its own.

@bapt are you open to open this Pandora's box?

Cheers,

Keve

[bapt]

yes I am but only after pkg 2.0 is out (exp-run ongoing)

[Defenso-QTH]

the handling of fingerprints in pkg with rootdir is the same as with other package managers, e.g. apk. The general idea is that once you are in the rootdir, pkg running outside should behave the same as pkg would do running inside.

So in fact, the inconsistency is the other way round. When given a rootdir, the configuration files from outside should not in fact be consulted at all. You will observe that once you set a configuration file inside the rootdir, that becomes effective and any repository defined only outside becomes unavailable. Very counterintuitive.

Isn't that supposed to be the behaviour with -c (chroot)?

I would expect -r to let me work with my current configuration and keys, while -c could require everything to be within the new root (but not necessarily: it could chroot after reading configuration).