Build time `.tal`/`.constraints` output locations about rpki-client-portable HOT 5 OPEN

from rpki-client-portable.

from rpki-client-portable.

A little more context, now that I am less pressed for time...!

To be a little less terse: the semantics of these three things aren't really independent of each other in rpki-client's logic, so it makes not all that much sense to split them up.

Yup, I get that the options I'm asking for allow one to construct an installation layout that won't work out of the box!

Your example sounds more like a --no-default-tal-files option but maybe you have more use cases than that?

I'm currently packaging rpki-client for Nix/NixOS.
I'll provide the TALs in a separate package, so that they can be shared as dependencies of other RP packages (similar to how Debian does this).
Nix builds happen in a sandbox, in which /etc isn't writable, so unlike Debian I can't just write them out in the build root and then prune them afterwards.
--no-default-tal-files would work for this part.

The .constraints files, on the other hand, are an rpki-client specific thing, so providing them as a separate package doesn't make sense. Instead, I'd like to ship these in $PREFIX/share/rpki-client/constraints so that they're available to symlink/copy into place post-installation.

Ideally, I'd like to be able to express:

• runtime TAL search path to be /etc/rpki/tals/
• inhibit writing the TALs, and
• write the constraints to $PREFIX/share/rpki-client/constraints

from rpki-client-portable.

I think you are trying to make us add complexity at the wrong level.

The constraints files are an integral part of rpki-client, they should work out of the box in any installation, and they should be installed into the same directory as the TALs. So, no, they should not be installed elsewhere for symlinking/copy post-installation and we don't want to add a config knob for that. If you don't want to use them yourself, that is your decision and your problem to handle. I believe as a packager you should not break that for all nix users.

As I said, I'm willing to entertain a --no-default-tal-files option, but I'm not entirely sold on having multiple RP programs share the massive amount of disk space the TAL files take up. Again, this sounds like a downstream decision that should be solved downstream.

Nix builds happen in a sandbox, in which /etc isn't writable, so unlike Debian I can't just write them out in the build root and then prune them afterwards.

I don't really understand what this means, but it sure sounds like a self-inflicted problem by an opinionated packaging tool at should be solved by its developers or users.

from rpki-client-portable.

My hope is that one day more RP implementations gain support for the constraints syntax specified in draft-snijders-constraining-rpki-trust-anchors. An argument could be made that - while at present moment - rpki-client is the only implementation that can make use of the *.constraints files, they are not intended to be rpki-client-specific. Wouldn't this nix package be simplified if both *.tal and *.constraints end up in /etc/rpki/tals/ ?

from rpki-client-portable.