Re: Architecture neutral packages (mozilla-rootcerts-openssl)

[Greg Troxel <gdt%lexort.com@localhost>]

David Brownlee <abs%absd.org@localhost> writes:

> How much work would it be to allow for architecture neutral packages?
>
> I ask because of PR-57456 -
> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57456
>
> By default NetBSD-10 (like earlier NetBSD releases) does not populate
> /etc/openssl/certs

Indeed, the base system continues to choose not to install trust
anchors.   That is the main point.

> 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:
>
> % hg clone https://anonhg.netbsd.org/src
> (an attempt was made to load CA certificates but none were loaded; see
> https://mercurial-scm.org/wiki/SecureConnections for how to configure
> Mercurial to avoid this error) abort: error: [SSL:
> CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get
> local issuer certificate (_ssl.c:997)

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.

> Adding certificates to the system is not that difficult, the key point
> is to provide a mechanism to ensure they can be updated.

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.

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.

> 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.

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.

The most difficult part is making the policy decision to install trust
anchors.  The next is actually managing provisioning the packages.

> Note that certificates available to sysinst is a different issue and
> we currently have a workaround.
>
> (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.

> 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.

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.