Date: Mon, 20 Feb 2023 13:12:33 -0700 From: Warner Losh <imp@bsdimp.com> To: Colin Percival <cperciva@tarsnap.com> Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Removing WITHOUT_CAPSICUM and WITHOUT_CASPER from 14.x Message-ID: <CANCZdfrywpnPOo7Cjp7DEkdFwVa4KCYSOu6Dh12b2Lq0m8OuAQ@mail.gmail.com> In-Reply-To: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com> References: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000003a4edf05f527495d
Content-Type: text/plain; charset="UTF-8"
My only feedback is that bsd-user doesn't fully implement capsicum, which
may cause
issues with that...
Warner
On Wed, Feb 15, 2023 at 9:53 PM Colin Percival <cperciva@tarsnap.com> wrote:
> Hi FreeBSD architects,
>
> I'd like to remove WITHOUT_CAPSICUM and WITHOUT_CASPER for FreeBSD 14.x.
>
> The rationale for this is threefold:
>
> 1. They doesn't serve any useful purpose and merely weakens security;
>
> 2. They're an anomaly among WITH/WITHOUT options -- most WITHOUT_* options
> take the form "don't build/install <components>" rather than having
> effects across the entire tree.
>
> 3. They're a pain for release engineering, because approximately nobody
> ever
> tests FreeBSD with WITHOUT_CAPSICUM or WITHOUT_CASPER set, but they're the
> sort of option which can easily break the build due to having affects all
> over the tree.
>
> If nobody objects, my plan is to get rid of the WITHOUT_ build options
> first
> and leave MK_{CAPSICUM,CASPER} set unconditionally to "yes"; then sweep the
> tree (mostly a matter of running unifdef) after 14.x is branched.
>
> --
> Colin Percival
> FreeBSD Deputy Release Engineer & EC2 platform maintainer
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
>
>
--0000000000003a4edf05f527495d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My only feedback is that bsd-user doesn't fully implem=
ent capsicum, which may cause<div>issues with that...</div><div><br></div><=
div>Warner</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Feb 15, 2023 at 9:53 PM Colin Percival <<a href=
=3D"mailto:cperciva@tarsnap.com">cperciva@tarsnap.com</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Hi FreeBSD architects,=
<br>
<br>
I'd like to remove WITHOUT_CAPSICUM and WITHOUT_CASPER for FreeBSD 14.x=
.<br>
<br>
The rationale for this is threefold:<br>
<br>
1. They doesn't serve any useful purpose and merely weakens security;<b=
r>
<br>
2. They're an anomaly among WITH/WITHOUT options -- most WITHOUT_* opti=
ons<br>
take the form "don't build/install <components>" rather=
than having<br>
effects across the entire tree.<br>
<br>
3. They're a pain for release engineering, because approximately nobody=
ever<br>
tests FreeBSD with WITHOUT_CAPSICUM or WITHOUT_CASPER set, but they're =
the<br>
sort of option which can easily break the build due to having affects all<b=
r>
over the tree.<br>
<br>
If nobody objects, my plan is to get rid of the WITHOUT_ build options firs=
t<br>
and leave MK_{CAPSICUM,CASPER} set unconditionally to "yes"; then=
sweep the<br>
tree (mostly a matter of running unifdef) after 14.x is branched.<br>
<br>
-- <br>
Colin Percival<br>
FreeBSD Deputy Release Engineer & EC2 platform maintainer<br>
Founder, Tarsnap | <a href=3D"http://www.tarsnap.com" rel=3D"noreferrer" ta=
rget=3D"_blank">www.tarsnap.com</a> | Online backups for the truly paranoid=
<br>
<br>
</blockquote></div>
--0000000000003a4edf05f527495d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrywpnPOo7Cjp7DEkdFwVa4KCYSOu6Dh12b2Lq0m8OuAQ>