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

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

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.

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

> no-arch packages may not be the only way, but it feels like it's worth
> exploring.

sure - I am not opposed to the concept, just that I think it's a leap
from the discussion we haven't had on tech-userlevel yet to this being
the answer.

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

You could, but if this is really about 2 packages, it is pretty easy to
just run the tool on those two, and keep the effort as small as possible
to achieve the real goals.

> 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 people that haven't read this discussion.

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

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