On Wed, 2 Aug 2023 at 11:25, Greg Troxel <
gdt%lexort.com@localhost> wrote:
>
> David Brownlee <
abs%absd.org@localhost> writes:
>
> > How much work would it be to allow for architecture neutral packages?
> [...]
> > This impacts the base system ftp - which cannot make requests to
> > https:// URLs by default, and pretty much any openssl using package -
> > for example installing mercurial from pkgsrc:
>
> [...]
>
> Strictly, it doesn't follow that it can't; it could be configured to
> continue without verification instead, which is what many things used to
> do.
OK, so to recast this slightly. I believe that on installation the system should offer the user a choice of:
1) Enforce trust anchors, and install certificates automatically (new handwavy mechanism discussed in this thread)
2) Enforce trust anchors, but leave it to the user to install and manage certificates
3) No not enforce trust anchors, and do not install certificates for trust (as in netbsd-9)
That critically provides choice, but guides the user down the best route by default (assuming we can make the first option the best route)
> It's not difficult but it is very difficult :-)
>
> > Two alternative options could be to:
> > a) provide the mozilla-certs.tgz pseudo-set as mentioned in the PR,
> > plus update the versions on the server regularly, then find some way
> > to get users to update
>
> I wonder how often known-compromised trust anchor certs are withdrawn,
> and what the frequency/urgency of this is relative to updating along the
> branch for other problems. It seems far from obvious that removing
> known-compromised trust anchors is frequent and urgent compared to all
> other security issues, and thus far from obvious that it needs a new
> mechanism.
Granted - hence by preference to rely on (by default) an existing mechanism for updating packages.
> Users choosing not to update is a user choice, and while I don't think
> it's wise, I don't see this as special in justifying controlling their
> behavior.
Valid point - hopefully addressed by my "recast" comment above?
> > b) implement architecture neutral packages (primarily for
> > mozilla-rootcerts & mozilla-rootcerts-openssl in this case), and
> > default the install process to installing them - this also allows
> > users to update them with other packages (and to use pkgin as the
> > recommended method to keep the certificates up to date)
>
> As I understand it, we have cross building of packages working, and we
> don't have that many architectures.
I think we have enough to make managing them non trivial - a quick glance at build.sh gives:
aarch64 aarch64eb alpha coldfire earm earmv4 earmv4eb earmv5 earmv5eb
earmv5hf earmv5hfeb earmv6 earmv6eb earmv6hf earmv6hfeb earmv7
earmv7eb earmv7hf earmv7hfeb hppa i386 ia64 m68000 m68k mips64eb
mips64el mipseb mipsel mipsn64eb mipsn64el or1k powerpc powerpc64
riscv32 riscv64 sh3eb sh3el sparc sparc64 vax x86_64
We could exclude some *arm* (but which?) and we can exclude some others, but there are definitely... more than I would like to manage without a generic mechanism.
no-arch packages may not be the only way, but it feels like it's worth exploring.
> You say "implement architecture-neutral packages", but it strikes me
> that one could pretty easily write a script/program to take a binary
> package for one arch and just relabel it for another.
Oh, absolutely.
Though.... if we're doing that it would make sense to tag Makefiles for packages which are known to be architecture-neutral and push that through as a tag in binary packages to assist that tool as to when it should warn or not.
At which point you just need to teach the package tools about that tag, and you have one way to provide architecture neutral packages - they still indicate the arch on which they were built, but have the 'no-arch' tag
> The most difficult part is making the policy decision to install trust
> anchors. The next is actually managing provisioning the packages.
See above "recast" comment :)
> > (I'm using "all-arch" as a placeholder magic token below, I'm assuming
> > it would be named differently)
>
> <bikeshed>share</>. This is basically the same thing as share in hier(7).
>
> Also, it's really no-arch instead of all-arch. These are not fat
> binaries.
Happy with "share", (or some "no-arch" type tag if we go with an additional tag instead)
> > On the build side is it more than:
> > - Updating the tools to understand a magic token to mean "all-arch"
> > - Adding a new option to set in Makefiles (and matching mk logic) to
> > note a package as "all-arch" and pass the relevant flags to pkg_create
>
> I suspect that's all it is. Basically, change the check from "is arch
> mine" to "is it mine or all-arch/share".
>
> > As for managing them, one of:
> > a) Put an extra copy at build time into ./all-arch, and symlink games
> > on upload to
ftp.netbsd.org?
> > b) Add a post upload tool on
ftp.netbsd.org which finds the all-arch
> > packages and copies them to ../../all-arch/$(uname -r)ish/
> > plus teaching pkgin (and pkg_install?) to use the extra URL as fallback
>
> I think it's messier than that; it may be necessary to remove them from
> the normal path.
I had a feeling that end of the pipe would have the most kinks to work out.
> Also, to talk about the elephant -- which I think is healthier than not
> -- we generally do not get packages built and made available in a timely
> manner compared to what I think you are positing as a security-critical
> timeframe.
>
> What the timeframe is, and whether base *wants* to install trust
> anchors, are the key questions, and once that is decided then mechanisms
> can be designed. Those first two questions are not about pkgsrc and
> belong on tech-userlevel.
>
> The third question is whether to install all of mozilla-rootcerts, or
> only a small subset that is widely regarded as safe -- and that will
> presumably have a much lower occurance of revocation.
>
> A fourth question is how to respect user configuration to add or remove
> trust anchors from the system-provided list. IMHO this is just like
> anything else in /etc. E.g. if inetd defaulted discard to on, a user
> might disable it, or the other way around.
>
> Users might reasonably want to adjust the trust anchor set:
>
> add the US government CA, if they deal with DoD (we have a weird
> situation where the DoD PKI is not mozilla-approved, because
> apparently DoD doens't care what mozilla thinks, and civil agencies
> use commercial certs)
>
> remove particular for various personal distrust or national policy
> reasons, or just because the concept that 161 trust anchors are all
> sound is implausible (this is the second elephant in this message).
>
> Finally, it is far from clear to me that assuming a policy decision to
> install trust anchors, that the best course of action is to involve
> pkgsrc. The hard part is respecting admin choice, and that to me leads
> to a config file that has lines like "include standard", "exclude foo",
> "include bar-from-standard", and "include my-boutique" that results in
> processing a local dir and the system list and writing to the trust
> anchor dir. Once that's done, it's easy to grab the list from cron and
> run the script.
My goal in starting this thread was to confirm if no-arch packages would be a viable mechanism for delivering certificates to NetBSD machines. I think we've established that it could be, modulus:
- resolving how a "no-arch" package is tagged ("share" arch vs "no-arch" tag)
- a bunch of kinks on managing no-arch package locations for pkgin and similar
- whether the update frequency would be sufficient (I would suggest that if updating trust anchors is managed at least as well as updating a package with a remote CVE then its covered)
I agree I did not cover policy (which is better suited to tech-userlevel) - thank you for the detailed response: with which I think I can now put together something appropriate for that list :)
On that note, revisiting my initial "recast" comment
On installation the system should offer the user a choice of:
1) Enforce recommended trust anchors, and install certificates automatically
2) Enforce trust anchors, but leave it to the user to install and manage certificates
3) No not enforce trust anchors, and do not install certificates for trust (as in netbsd-9)
You could argue that someone who needs more granularity should pick 2) and work it out themselves. We could also provide some form of config file which mozilla-rootcert-openssl uses when it build/rebuilds /etc/openssl/certs to help them towards that, but I'm trying to work towards something better for users who do not understand trust anchors than "most https tools just fail until you google something and work out to install mozilla-rootcert-openssl or just give up and pick another system"
David