Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

voidanix
Hello,
I wanted to discuss about bug 231768 a bit: it is about keeping
COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.

The patch attached for the bug is for disabling these options by
default, following a few reasons which I'm going to list here:
     - Keeping support for deprecated libraries isn't exactly the best we
could do to avoid security issues (if there are any) as I'm sure nobody
wants to spend that much time maintaining such stuff (it's enough to
think about misc/compat4x in the ports tree: that version of FreeBSD was
released on March 2000 and keeping 19 years old libraries around isn't
ideal)
     - Devs should get track of time and realize that developing software
using unsupported libraries is NOT something that you should do
     - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
if the software won't compile without the legacy components (and has a
replacement of some kind), considering removal wouldn't be a bad idea
     - This is on by default: most users don't care or don't use binaries
that old

I don't see any practical reason to keep these options on by default,
but I do appreciate any sort of input regarding this issue.

- voidanix
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Rainer Duffner
Am 2019-05-27 15:55, schrieb [hidden email]:

> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
>
> The patch attached for the bug is for disabling these options by
> default, following a few reasons which I'm going to list here:
>     - Keeping support for deprecated libraries isn't exactly the best
> we could do to avoid security issues (if there are any) as I'm sure
> nobody wants to spend that much time maintaining such stuff (it's
> enough to think about misc/compat4x in the ports tree: that version of
> FreeBSD was released on March 2000 and keeping 19 years old libraries
> around isn't ideal)
>     - Devs should get track of time and realize that developing
> software using unsupported libraries is NOT something that you should
> do
>     - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
> if the software won't compile without the legacy components (and has a
> replacement of some kind), considering removal wouldn't be a bad idea
>     - This is on by default: most users don't care or don't use
> binaries that old
>
> I don't see any practical reason to keep these options on by default,
> but I do appreciate any sort of input regarding this issue.


I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
department who is technically responsible for the service gets around
redoing that service.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Conrad Meyer-2
Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM <[hidden email]> wrote:
> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> department who is technically responsible for the service gets around
> redoing that service.

Even if this proposal is approved, it would only affect 13+.  You
could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
Bhyve.  But do consider lighting a fire under whatever department
thinks it's ok to deploy like that :-).

Take care,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Konstantin Belousov
In reply to this post by voidanix
On Mon, May 27, 2019 at 03:55:21PM +0200, [hidden email] wrote:
> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
What problem are you trying to solve ?

>
> The patch attached for the bug is for disabling these options by
> default, following a few reasons which I'm going to list here:
>      - Keeping support for deprecated libraries isn't exactly the best we
> could do to avoid security issues (if there are any) as I'm sure nobody
> wants to spend that much time maintaining such stuff (it's enough to
> think about misc/compat4x in the ports tree: that version of FreeBSD was
> released on March 2000 and keeping 19 years old libraries around isn't
> ideal)
>      - Devs should get track of time and realize that developing software
> using unsupported libraries is NOT something that you should do
This is nonsense.  These options are not for developing new software.

>      - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
> if the software won't compile without the legacy components (and has a
> replacement of some kind), considering removal wouldn't be a bad idea
And that options are usually not about ports.

>      - This is on by default: most users don't care or don't use binaries
> that old
This is I am really interesting about.  How do you know ?  The method
you came to this conclusion should allow us to solve many other old
issues, I hope.

>
> I don't see any practical reason to keep these options on by default,
> but I do appreciate any sort of input regarding this issue.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Rainer Duffner
In reply to this post by Conrad Meyer-2
Am 2019-05-27 17:05, schrieb Conrad Meyer:

> Hi Rainier,
>
> On Mon, May 27, 2019 at 7:47 AM <[hidden email]> wrote:
>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
>> department who is technically responsible for the service gets around
>> redoing that service.
>
> Even if this proposal is approved, it would only affect 13+.  You
> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
> Bhyve.  But do consider lighting a fire under whatever department
> thinks it's ok to deploy like that :-).
>
> Take care,
> Conrad


I thought so, too.

I don't really want to run the abandonware of a RADIUS-server any longer
than necessary (as absurd as that sounds).

It's also running a recursive nameserver (previously also authoritative)
that is still hard-coded in CPE and computers behind firewalls.

I first wanted to virtualize it (it's not a big problem) - but this way
the problem is just dragged out: "But it still works, does it and we
have no time".

Everybody now knows that the clock is ticking, literally.

Oh, I also remember George Neville-Neil talking about a - what - FreeBSD
4 binary that a certain search-engine had lost the sources for and was
running on FreeBSD 7 with compat4.
(We also have a client who literally begged us to leave a decade-old
Solaris box running through 2019 and half of 2020 so they could continue
to do their bookkeeping on a home-grown java-app that I suspect they,
too have lost the sources to...). It's running jdk15 and getting that
thing to run under anything semi-decent doesn't seem to have worked-out
too well.
So, people pray for the best and don't prepare for the worst.


Other stuff I can think of:
  - very old Netbackup-Clients (like 5-series), though I doubt they still
work on recent releases, because 7.71 (last official version and
intended for FreeBSD 11) stopped working on FreeBSD12, sadly)
  - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I
can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools
or something different)


What ever people do with COMPAT4-9 - it's bordering the pathological.




_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Enji Cooper

> On May 27, 2019, at 08:27, [hidden email] wrote:
>
> Am 2019-05-27 17:05, schrieb Conrad Meyer:
>> Hi Rainier,
>> On Mon, May 27, 2019 at 7:47 AM <[hidden email]> wrote:
>>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
>>> department who is technically responsible for the service gets around
>>> redoing that service.
>> Even if this proposal is approved, it would only affect 13+.  You
>> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
>> Bhyve.  But do consider lighting a fire under whatever department
>> thinks it's ok to deploy like that :-).
>> Take care,
>> Conrad
>
>
> I thought so, too.
>
> I don't really want to run the abandonware of a RADIUS-server any longer than necessary (as absurd as that sounds).
>
> It's also running a recursive nameserver (previously also authoritative) that is still hard-coded in CPE and computers behind firewalls.
>
> I first wanted to virtualize it (it's not a big problem) - but this way the problem is just dragged out: "But it still works, does it and we have no time".
>
> Everybody now knows that the clock is ticking, literally.
>
> Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 4 binary that a certain search-engine had lost the sources for and was running on FreeBSD 7 with compat4.
> (We also have a client who literally begged us to leave a decade-old Solaris box running through 2019 and half of 2020 so they could continue to do their bookkeeping on a home-grown java-app that I suspect they, too have lost the sources to...). It's running jdk15 and getting that thing to run under anything semi-decent doesn't seem to have worked-out too well.
> So, people pray for the best and don't prepare for the worst.
>
>
> Other stuff I can think of:
> - very old Netbackup-Clients (like 5-series), though I doubt they still work on recent releases, because 7.71 (last official version and intended for FreeBSD 11) stopped working on FreeBSD12, sadly)
> - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or something different)
>
>
> What ever people do with COMPAT4-9 - it's bordering the pathological.

I’ll counter the OP’s suggestion a bit:

It would be nice if the compat options were modularized and printed out an EOS warning when loaded, so the user was aware that the modules are not supported by FreeBSD, in terms of security and whatnot.

Thanks!
-Enji
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Warner Losh
On Mon, May 27, 2019, 6:49 PM Enji Cooper <[hidden email]> wrote:

>
> > On May 27, 2019, at 08:27, [hidden email] wrote:
> >
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM <[hidden email]> wrote:
> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> >>> department who is technically responsible for the service gets around
> >>> redoing that service.
> >> Even if this proposal is approved, it would only affect 13+.  You
> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
> >> Bhyve.  But do consider lighting a fire under whatever department
> >> thinks it's ok to deploy like that :-).
> >> Take care,
> >> Conrad
> >
> >
> > I thought so, too.
> >
> > I don't really want to run the abandonware of a RADIUS-server any longer
> than necessary (as absurd as that sounds).
> >
> > It's also running a recursive nameserver (previously also authoritative)
> that is still hard-coded in CPE and computers behind firewalls.
> >
> > I first wanted to virtualize it (it's not a big problem) - but this way
> the problem is just dragged out: "But it still works, does it and we have
> no time".
> >
> > Everybody now knows that the clock is ticking, literally.
> >
> > Oh, I also remember George Neville-Neil talking about a - what - FreeBSD
> 4 binary that a certain search-engine had lost the sources for and was
> running on FreeBSD 7 with compat4.
> > (We also have a client who literally begged us to leave a decade-old
> Solaris box running through 2019 and half of 2020 so they could continue to
> do their bookkeeping on a home-grown java-app that I suspect they, too have
> lost the sources to...). It's running jdk15 and getting that thing to run
> under anything semi-decent doesn't seem to have worked-out too well.
> > So, people pray for the best and don't prepare for the worst.
> >
> >
> > Other stuff I can think of:
> > - very old Netbackup-Clients (like 5-series), though I doubt they still
> work on recent releases, because 7.71 (last official version and intended
> for FreeBSD 11) stopped working on FreeBSD12, sadly)
> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I
> can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or
> something different)
> >
> >
> > What ever people do with COMPAT4-9 - it's bordering the pathological.
>
> I’ll counter the OP’s suggestion a bit:
>
> It would be nice if the compat options were modularized and printed out an
> EOS warning when loaded, so the user was aware that the modules are not
> supported by FreeBSD, in terms of security and whatnot.
>

How is that relevant? They just control system calls, not any userland
libraries that might or might not have a security exposure. Plus, if not
done right you either startle the horses for no reason, or you run the risk
of a console DoS if you print something on each system call...

Warner

Thanks!
> -Enji
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Enji Cooper

> On May 27, 2019, at 7:20 PM, Warner Losh <[hidden email]> wrote:
>
> On Mon, May 27, 2019, 6:49 PM Enji Cooper <[hidden email] <mailto:[hidden email]>> wrote:
>
> > On May 27, 2019, at 08:27, [hidden email] <mailto:[hidden email]> wrote:
> >
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM <[hidden email] <mailto:[hidden email]>> wrote:
> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> >>> department who is technically responsible for the service gets around
> >>> redoing that service.
> >> Even if this proposal is approved, it would only affect 13+.  You
> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
> >> Bhyve.  But do consider lighting a fire under whatever department
> >> thinks it's ok to deploy like that :-).
> >> Take care,
> >> Conrad
> >
> >
> > I thought so, too.
> >
> > I don't really want to run the abandonware of a RADIUS-server any longer than necessary (as absurd as that sounds).
> >
> > It's also running a recursive nameserver (previously also authoritative) that is still hard-coded in CPE and computers behind firewalls.
> >
> > I first wanted to virtualize it (it's not a big problem) - but this way the problem is just dragged out: "But it still works, does it and we have no time".
> >
> > Everybody now knows that the clock is ticking, literally.
> >
> > Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 4 binary that a certain search-engine had lost the sources for and was running on FreeBSD 7 with compat4.
> > (We also have a client who literally begged us to leave a decade-old Solaris box running through 2019 and half of 2020 so they could continue to do their bookkeeping on a home-grown java-app that I suspect they, too have lost the sources to...). It's running jdk15 and getting that thing to run under anything semi-decent doesn't seem to have worked-out too well.
> > So, people pray for the best and don't prepare for the worst.
> >
> >
> > Other stuff I can think of:
> > - very old Netbackup-Clients (like 5-series), though I doubt they still work on recent releases, because 7.71 (last official version and intended for FreeBSD 11) stopped working on FreeBSD12, sadly)
> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or something different)
> >
> >
> > What ever people do with COMPAT4-9 - it's bordering the pathological.
>
> I’ll counter the OP’s suggestion a bit:
>
> It would be nice if the compat options were modularized and printed out an EOS warning when loaded, so the user was aware that the modules are not supported by FreeBSD, in terms of security and whatnot.
>
> How is that relevant? They just control system calls, not any userland libraries that might or might not have a security exposure. Plus, if not done right you either startle the horses for no reason, or you run the risk of a console DoS if you print something on each system call…

My point was to suggest basically controlling the syscall table (like linux does for instance). If a compat module was loaded, it would print out the warning. Not on each syscall entry. That would be insanity as far as performance degradation would be concerned :/.
-Enji

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Warner Losh
On Mon, May 27, 2019, 8:23 PM Enji Cooper <[hidden email]> wrote:

>
> On May 27, 2019, at 7:20 PM, Warner Losh <[hidden email]> wrote:
>
> On Mon, May 27, 2019, 6:49 PM Enji Cooper <[hidden email]> wrote:
>
>>
>> > On May 27, 2019, at 08:27, [hidden email] wrote:
>> >
>> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
>> >> Hi Rainier,
>> >> On Mon, May 27, 2019 at 7:47 AM <[hidden email]> wrote:
>> >>> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
>> >>> department who is technically responsible for the service gets around
>> >>> redoing that service.
>> >> Even if this proposal is approved, it would only affect 13+.  You
>> >> could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
>> >> Bhyve.  But do consider lighting a fire under whatever department
>> >> thinks it's ok to deploy like that :-).
>> >> Take care,
>> >> Conrad
>> >
>> >
>> > I thought so, too.
>> >
>> > I don't really want to run the abandonware of a RADIUS-server any
>> longer than necessary (as absurd as that sounds).
>> >
>> > It's also running a recursive nameserver (previously also
>> authoritative) that is still hard-coded in CPE and computers behind
>> firewalls.
>> >
>> > I first wanted to virtualize it (it's not a big problem) - but this way
>> the problem is just dragged out: "But it still works, does it and we have
>> no time".
>> >
>> > Everybody now knows that the clock is ticking, literally.
>> >
>> > Oh, I also remember George Neville-Neil talking about a - what -
>> FreeBSD 4 binary that a certain search-engine had lost the sources for and
>> was running on FreeBSD 7 with compat4.
>> > (We also have a client who literally begged us to leave a decade-old
>> Solaris box running through 2019 and half of 2020 so they could continue to
>> do their bookkeeping on a home-grown java-app that I suspect they, too have
>> lost the sources to...). It's running jdk15 and getting that thing to run
>> under anything semi-decent doesn't seem to have worked-out too well.
>> > So, people pray for the best and don't prepare for the worst.
>> >
>> >
>> > Other stuff I can think of:
>> > - very old Netbackup-Clients (like 5-series), though I doubt they still
>> work on recent releases, because 7.71 (last official version and intended
>> for FreeBSD 11) stopped working on FreeBSD12, sadly)
>> > - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I
>> can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools or
>> something different)
>> >
>> >
>> > What ever people do with COMPAT4-9 - it's bordering the pathological.
>>
>> I’ll counter the OP’s suggestion a bit:
>>
>> It would be nice if the compat options were modularized and printed out
>> an EOS warning when loaded, so the user was aware that the modules are not
>> supported by FreeBSD, in terms of security and whatnot.
>>
>
> How is that relevant? They just control system calls, not any userland
> libraries that might or might not have a security exposure. Plus, if not
> done right you either startle the horses for no reason, or you run the risk
> of a console DoS if you print something on each system call…
>
>
> My point was to suggest basically controlling the syscall table (like
> linux does for instance). If a compat module was loaded, it would print out
> the warning. Not on each syscall entry. That would be insanity as far as
> performance degradation would be concerned :/.
>

Except it would take a lot of work to make the compat options a module.
Also, we need them for the upgrade path... I'm still not convinced a
warning would be more beneficial than the concern it would generates...

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Xin LI-5
In reply to this post by voidanix
On Mon, May 27, 2019 at 7:08 AM <[hidden email]> wrote:

> Hello,
> I wanted to discuss about bug 231768 a bit: it is about keeping
> COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.
>
> The patch attached for the bug is for disabling these options by
> default, following a few reasons which I'm going to list here:
>      - Keeping support for deprecated libraries isn't exactly the best we
> could do to avoid security issues (if there are any) as I'm sure nobody
> wants to spend that much time maintaining such stuff (it's enough to
> think about misc/compat4x in the ports tree: that version of FreeBSD was
> released on March 2000 and keeping 19 years old libraries around isn't
> ideal)
>

To accomplish this goal, a prerequisite would be to remove libc.a (possibly
also libthr.a as well as anything that makes a direct system call).  I'd
rather see that happen first.


>      - Devs should get track of time and realize that developing software
> using unsupported libraries is NOT something that you should do
>      - Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
> if the software won't compile without the legacy components (and has a
> replacement of some kind), considering removal wouldn't be a bad idea
>      - This is on by default: most users don't care or don't use binaries
> that old
>

> I don't see any practical reason to keep these options on by default,
> but I do appreciate any sort of input regarding this issue.
>

Because users would find a way (e.g. by not upgrading) which further
undermines their security?  I know quite some Windows users would disable
Windows Update for the exact same reason, if you break backward
compatibility, your credibility is broken and it is much harder to regain
the trust.

Cheers,
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Jamie Landeg-Jones-2
In reply to this post by Rainer Duffner
[hidden email] wrote:

> I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> department who is technically responsible for the service gets around
> redoing that service.

From my understanding from reading the bug (though it's not entirely clear
in this thread), this relates to removing the options from the generic (et al.)
kernels, not deleting the code itself.

You'd therefore be able to just keep the options enabled in your own
config..  , or is this just the first stage of full deprecation?

Cheers, Jamie
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

Rodney W. Grimes-6
> [hidden email] wrote:
>
> > I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
> > department who is technically responsible for the service gets around
> > redoing that service.
>
> >From my understanding from reading the bug (though it's not entirely clear
> in this thread), this relates to removing the options from the generic (et al.)
> kernels, not deleting the code itself.

That would make GENERIC less than GENERIC as you can not load
these changes as modules, nor would it be easy to make them modules.

> You'd therefore be able to just keep the options enabled in your own
> config..  , or is this just the first stage of full deprecation?

And that too, if you take stuff out of GENERIC it gets built less
often and that often leads to bit rot and that often leads to
deprecation because it "must not be used it has rotted and look
no one has complained."  (Which, imho, is a rotton support model.)

> Cheers, Jamie
--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"