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

[David Brownlee <abs%absd.org@localhost>]

On Wed, 2 Aug 2023 at 14:03, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> David Brownlee <abs%absd.org@localhost> writes:
>
> >> 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.
>
> My point is that we have a mechanism to update the base system, and that
> is how things like bugs in code and other things in /etc get fixed.  It
> is not obvious that jumping to pkgsrc is the right answer, and thus this
> discussion belongs in tech-userlevel.

I'm very happy to (and am intending to) continue the policy issues on
tech-userlevel. I just wanted to identity any technical issues with
the "no-arch packages" approach first before presenting it as one of
the options on tech-userlevel

> >> 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?
>
> more or less, yes, but I am not comfortable with "people might not do
> what we want so let's try to lean on them", which is a fine line from
> "let's provide useful mechanisms".

I think there is also a useful distinction from
"people might not do what we want so let's try to lean on them"
and
"provide good defaults for those who do not read the question, or
would not understand it if they did"

> > 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.
>
> Have you tried writing a script to just do it?  It might be a lot of
> CPU/disk/etc but it would be very interesting in its own right.

I'm trying not to take on more interesting things I'm likely to fail
to deliver (or make my $dayjob backlog worse :), I'm just hoping to
nudge along the trust anchors issue after falling over it myself and
talking to others who have similarly (the general comment from whom
has been "wtaf? - why did NetBSD dump me in this broken state?")

> [...]
> > Happy with "share", (or some "no-arch" type tag if we go with an additional
> > tag instead)
>
> At this point I lean to no-arch because I think it will be understood by
> a greater number of people that haven't read this discussion.

wfm.

> > 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)
>
> Agreed, but to me it feels like no-arch is a minor detail in the overall
> difficulty.

Definitely, but if managing trust anchors via binary packages is
presented as an option then it helps to include details on what is
practical or not, including any issues which come up in this thread.

> > 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"
>
> Yes, that seems a step up from where we are now.
>
> The real issue remaining is the second elephant: the concept of 161
> trust anchors, the compromise of any one of which compromises the
> system, being sound is just too much to believe.

Almost every other Operating System manages to provide something which
is better than "No trust anchors & no validation".

I'd be delighted to have a separate bikes^thread refining which trust
anchors should be in the default set (on which I would suspect I would
be very much a spectator due to the lack of domain knowledge), but I
feel that unless someone can say state that "providing a choice on
install with a default of installing all trust anchors" is worse than
"no trust anchors & no validation by default", it's more likely to
derail this into nothing happening and netbsd-10 shipping with a patch
to just disable all trust anchors.

Thanks

David