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

[Rodney W. Grimes]

> rai...@ultra-secure.de 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 rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Jamie Landeg-Jones]

rai...@ultra-secure.de 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Xin LI]

On Mon, May 27, 2019 at 7:08 AM  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,
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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  wrote:

>
> On May 27, 2019, at 7:20 PM, Warner Losh  wrote:
>
> On Mon, May 27, 2019, 6:49 PM Enji Cooper  wrote:
>
>>
>> > On May 27, 2019, at 08:27, rai...@ultra-secure.de wrote:
>> >
>> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
>> >> Hi Rainier,
>> >> On Mon, May 27, 2019 at 7:47 AM  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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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  wrote:
> 
> On Mon, May 27, 2019, 6:49 PM Enji Cooper  > wrote:
> 
> > On May 27, 2019, at 08:27, rai...@ultra-secure.de 
> >  wrote:
> > 
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM  >> > 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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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  wrote:

>
> > On May 27, 2019, at 08:27, rai...@ultra-secure.de wrote:
> >
> > Am 2019-05-27 17:05, schrieb Conrad Meyer:
> >> Hi Rainier,
> >> On Mon, May 27, 2019 at 7:47 AM  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
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Enji Cooper]

> On May 27, 2019, at 08:27, rai...@ultra-secure.de wrote:
> 
> Am 2019-05-27 17:05, schrieb Conrad Meyer:
>> Hi Rainier,
>> On Mon, May 27, 2019 at 7:47 AM  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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[rainer]

Am 2019-05-27 17:05, schrieb Conrad Meyer:

Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM  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.




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Konstantin Belousov]

On Mon, May 27, 2019 at 03:55:21PM +0200, voida...@420blaze.it 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.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Conrad Meyer]

Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM  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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[rainer]

Am 2019-05-27 15:55, schrieb voida...@420blaze.it:

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.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"