rtools were deemed almost unused 15 years ago...

[Jeremie Le Hen]

Hey folks,

I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.

Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.

Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.

The proposed roadmap is:
- disable from the build on head and let it soak for one month
- remove rtools from the base.

What do you guys think? Any preferred color for the bikeshed? :)



[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

[Ollivier Robert]

Post by Jeremie Le Hen
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)

Go for it.

[Ngie Cooper (yaneurabeya)]

Post by Ollivier Robert

Post by Jeremie Le Hen
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)

Go for it.

rsh, etc doesn’t live in ports, and there are viable uses for it still, even though this day in age they’re greatly reduced.
- I’ll submit a new port for those that still need it.
- I’ll disable it in base; add a nice comment noting that it’s available in ports.
-> Best case scenario, we can remove rsh from base before 12.0.
Thanks!
-Ngie

[Emmanuel Vadot]

On Tue, 20 Jun 2017 11:28:16 -0700

Post by Ollivier Robert

Post by Jeremie Le Hen
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)

Go for it.

rsh, etc doesn?t live in ports, and there are viable uses for it still, even though this day in age they?re greatly reduced.
- I?ll submit a new port for those that still need it.
- I?ll disable it in base; add a nice comment noting that it?s available in ports.
-> Best case scenario, we can remove rsh from base before 12.0.
Thanks!
-Ngie

There is maybe "viable uses" for vendors that haven't updated stuff in
their product, but not for regular users.

[Ngie Cooper (yaneurabeya)]

Post by Emmanuel Vadot
On Tue, 20 Jun 2017 11:28:16 -0700

Post by Ollivier Robert

Post by Jeremie Le Hen
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)

Go for it.

rsh, etc doesn?t live in ports, and there are viable uses for it still, even though this day in age they?re greatly reduced.
- I?ll submit a new port for those that still need it.
- I?ll disable it in base; add a nice comment noting that it?s available in ports.
-> Best case scenario, we can remove rsh from base before 12.0.
Thanks!
-Ngie

There is maybe "viable uses" for vendors that haven't updated stuff in
their product, but not for regular users.

Unfortunately this is not necessarily true, given past experience :/. You never know who needs something until it goes away.

[Baptiste Daroussin]

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!

Is telnetd part of your list?

Best regards,
Bapt

[Michael Gmelin]

On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

-m

[Ian Lepore]

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy
production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base
system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think?  Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
  

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.
-m

As long as ports are available for all these things, the impact of
removing them should be negligible for the few still using them.

-- Ian

[Brooks Davis]

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

Given the state of maintenance of our telnet code
(FreeBSD-SA-16:36.telnetd fixed a bug fixed in heimdal telnet well over
a decade ago), all the telnet code should be purged. For most uses nc
will suffice. For others, we should make sure there's something in
ports: either the crufty base system one or something like
https://github.com/seanmiddleditch/libtelnet/

-- Brooks

[Joel Dahl]

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

+1. Please keep the telnet client. It's something I expect be part of the base
system utilities. I use it all the time.

[Bob Bishop]

Post by Joel Dahl

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

+1. Please keep the telnet client. It's something I expect be part of the base
system utilities. I use it all the time.

+1 What he said.

Post by Joel Dahl
--
Joel

--
Bob Bishop
***@gid.co.uk

[Emmanuel Vadot]

On Tue, 20 Jun 2017 19:17:44 +0200

Post by Joel Dahl

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

+1. Please keep the telnet client. It's something I expect be part of the base
system utilities. I use it all the time.
--
Joel

Time to learn nc(1), I'm still fighting to use nc(1) insteal of telnet
(1) because of musle memory but removing it will help me make the
switch.

I honestly don't see any valid reason to keep telnet in the tree.

[Michael Gmelin]

Post by Emmanuel Vadot
On Tue, 20 Jun 2017 19:17:44 +0200

Post by Joel Dahl

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

+1. Please keep the telnet client. It's something I expect be part of the base
system utilities. I use it all the time.
--
Joel

Time to learn nc(1), I'm still fighting to use nc(1) insteal of telnet
(1) because of musle memory but removing it will help me make the
switch.
I honestly don't see any valid reason to keep telnet in the tree.

Don't talk what we need to learn, please.
PS: nc don't emulate telnet protocol.

I use nc every day (more frequently than telnet for sure), but it serves a different purpose than telnet. I need both.

-m

[Warner Losh]

Post by Jeremie Le Hen

Post by Emmanuel Vadot
On Tue, 20 Jun 2017 19:17:44 +0200

Post by Joel Dahl

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

+1. Please keep the telnet client. It's something I expect be part of

the base

Post by Emmanuel Vadot

Post by Joel Dahl
system utilities. I use it all the time.
--
Joel

Time to learn nc(1), I'm still fighting to use nc(1) insteal of telnet
(1) because of musle memory but removing it will help me make the
switch.
I honestly don't see any valid reason to keep telnet in the tree.

Don't talk what we need to learn, please.
PS: nc don't emulate telnet protocol.

I use nc every day (more frequently than telnet for sure), but it serves a
different purpose than telnet. I need both.

Same here. I use cat and more every day as well. They both display files,
but have different uses...

Warner

[Baptiste Daroussin]

Post by Joel Dahl

Post by Michael Gmelin
On Tue, 20 Jun 2017 13:11:37 +0200

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people
were mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1]
sorely reminds us that suid binaries are an attack surface. I don't
even need to mention that it's a healthy engineering practice to
remove unused code, both from a maintenance and security
perspective.
Therefore, I hereby propose to remove rtools from the base system.
I acknowledge this will likely cause troubles for a handful of
people who are still relying on it for good or bad reasons. But the
flipside is that the attack surface of millions of FreeBSD
installed out there will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

As long as the telnet(1) client stays in I'm all for it.

+1. Please keep the telnet client. It's something I expect be part of the base
system utilities. I use it all the time.

Hence why I only said I telnet*d* not telnet :)

Bapt

[Julian Elischer]

Post by Baptiste Daroussin

Post by Jeremie Le Hen
[...]
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?
Best regards,
Bapt

We use telnetd within out device, (not accessible outside the machine)
on 127.0.0.1 for various special purposes.

I guess we could live with it but there'd have to be a port/pkg

[Ngie Cooper (yaneurabeya)]

Post by Baptiste Daroussin

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Yeah!
Is telnetd part of your list?

PS telnet is a different ball of wax. I can create fine-grained knobs (_SERVER vs _CLIENT). Unfortunately removing both will require a bit more of an act of congress, but if the patches are available (somewhere
 in a ports equivalent version
 I know sjg@ maintains one), then we can just refer people to that.

[Warner Losh]

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Keep the telnet client. It's still heavily used for more things than
connecting to telnetd... The rest can go as they are nitch usage that can
be served by ports.

Warner

[Ngie Cooper (yaneurabeya)]

Post by Warner Losh

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Keep the telnet client. It's still heavily used for more things than
connecting to telnetd... The rest can go as they are nitch usage that can
be served by ports.

I’m going to look at our options for telnetd in ports. They both use a common source, so not building telnetd doesn’t give you much RoI.
-Ngie

[Mark Linimon]

Post by Warner Losh
Keep the telnet client. It's still heavily used for more things than
connecting to telnetd.

e.g. dumb remote power controllers.

nc blah 23 doesn't get me very far, am I missing a magic flag?

mcl

[Poul-Henning Kamp]

--------

Post by Mark Linimon

Post by Warner Losh
Keep the telnet client. It's still heavily used for more things than
connecting to telnetd.

e.g. dumb remote power controllers.
nc blah 23 doesn't get me very far, am I missing a magic flag?

No, you're missing TELNET option negotiations.

[Bob Bishop]

Post by Mark Linimon

Post by Warner Losh
Keep the telnet client. It's still heavily used for more things than
connecting to telnetd.

e.g. dumb remote power controllers.
nc blah 23 doesn't get me very far, am I missing a magic flag?

-t may help, depends how dumb is dumb.

Post by Mark Linimon
mcl

--
Bob Bishop
***@gid.co.uk

[Eitan Adler]

Post by Jeremie Le Hen
What do you guys think? Any preferred color for the bikeshed? :)

pokedots

Also - about damn time

[Rodney W. Grimes]

Post by Poul-Henning Kamp
--------

Post by Mark Linimon

Post by Warner Losh
Keep the telnet client. It's still heavily used for more things than
connecting to telnetd.

e.g. dumb remote power controllers.
nc blah 23 doesn't get me very far, am I missing a magic flag?

No, you're missing TELNET option negotiations.

nc -t well do that for you. (I only know this because I just went
and read the man page for nc as someone mentioned it in this
thread and I wanted to know if infact it supports telnet option
negatiation.)

But this does NOT mean I agree with removal of telnet/telnetd.

Isnt this whole discussion kinda pointless if you consider
this well be handle by packaged base? Those who want these
in there systems can have them, and those that think telnet/
telnetd are a bigger security risk than nc can also remove
them.

Post by Poul-Henning Kamp
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Mike Karels]

Post by Rodney W. Grimes

Post by Poul-Henning Kamp
--------

Post by Mark Linimon

Post by Warner Losh
Keep the telnet client. It's still heavily used for more things than
connecting to telnetd.

e.g. dumb remote power controllers.
nc blah 23 doesn't get me very far, am I missing a magic flag?

No, you're missing TELNET option negotiations.

nc -t well do that for you. (I only know this because I just went
and read the man page for nc as someone mentioned it in this
thread and I wanted to know if infact it supports telnet option
negatiation.)
But this does NOT mean I agree with removal of telnet/telnetd.
Isnt this whole discussion kinda pointless if you consider
this well be handle by packaged base? Those who want these
in there systems can have them, and those that think telnet/
telnetd are a bigger security risk than nc can also remove
them.

A belated +1 for removing most of the rtools, which were basically
a proof of concept many, many years ago. I agree with keeping
telnet, which I use constantly to connect to ports other than 23;
I have mixed feelings about telnetd, but I haven’t enabled it
in many years.

Mike

[Jeremie Le Hen]

So the first step was to create a port with FreeBSD rcmds, here we
are! But I need some eyes to vet it:
https://reviews.freebsd.org/D11345

Thanks.
-- Jeremie

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
--
Jeremie Le Hen

[Slawa Olhovchenkov]

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

[Piotr P. Stefaniak]

Post by Slawa Olhovchenkov

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

I prefer them to rot in ports than in base.

[Jeremie Le Hen]

Post by Slawa Olhovchenkov

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

Feel free to step in to help with the maintenance :-).

[John]

----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen

Post by Slawa Olhovchenkov

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

Feel free to step in to help with the maintenance :-).

Let's commit this little snippet which is a major win for HA heads
with 10 of thousands of file descriptors open...

Index: libexec/rshd/rshd.c
===================================================================
--- libexec/rshd/rshd.c (revision 316672)
+++ libexec/rshd/rshd.c (working copy)
@@ -191,7 +191,7 @@
struct passwd *pwd;
u_short port;
fd_set ready, readfrom;
- int cc, fd, nfd, pv[2], pid, s;
+ int cc, nfd, pv[2], pid, s;
int one = 1;
const char *cp, *errorstr;
char sig, buf[BUFSIZ];
@@ -496,8 +496,7 @@
#ifdef USE_BLACKLIST
blacklist(0, STDIN_FILENO, "success");
#endif
- for (fd = getdtablesize(); fd > 2; fd--)
- (void) close(fd);
+ closefrom(3);
if (setsid() == -1)
syslog(LOG_ERR, "setsid() failed: %m");
if (setlogin(pwd->pw_name) < 0)

Cheers,
John

Post by Jeremie Le Hen
--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Jeremie Le Hen]

Post by John
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen

Post by Slawa Olhovchenkov

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

Feel free to step in to help with the maintenance :-).

Let's commit this little snippet which is a major win for HA heads
with 10 of thousands of file descriptors open...

I don't have any context here. If you think it's the right thing to
do, then go ahead and I will update the port tarball.

Post by John
Index: libexec/rshd/rshd.c
===================================================================
--- libexec/rshd/rshd.c (revision 316672)
+++ libexec/rshd/rshd.c (working copy)
@@ -191,7 +191,7 @@
struct passwd *pwd;
u_short port;
fd_set ready, readfrom;
- int cc, fd, nfd, pv[2], pid, s;
+ int cc, nfd, pv[2], pid, s;
int one = 1;
const char *cp, *errorstr;
char sig, buf[BUFSIZ];
@@ -496,8 +496,7 @@
#ifdef USE_BLACKLIST
blacklist(0, STDIN_FILENO, "success");
#endif
- for (fd = getdtablesize(); fd > 2; fd--)
- (void) close(fd);
+ closefrom(3);
if (setsid() == -1)
syslog(LOG_ERR, "setsid() failed: %m");
if (setlogin(pwd->pw_name) < 0)
Cheers,
John

Post by Jeremie Le Hen
--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Adrian Chadd]

Oh holy crap yes please. Do you have commit privs to src? If not,
Reviewed by: adrian


-adrian

Post by John
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen

Post by Slawa Olhovchenkov

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

Feel free to step in to help with the maintenance :-).

Let's commit this little snippet which is a major win for HA heads
with 10 of thousands of file descriptors open...
Index: libexec/rshd/rshd.c
===================================================================
--- libexec/rshd/rshd.c (revision 316672)
+++ libexec/rshd/rshd.c (working copy)
@@ -191,7 +191,7 @@
struct passwd *pwd;
u_short port;
fd_set ready, readfrom;
- int cc, fd, nfd, pv[2], pid, s;
+ int cc, nfd, pv[2], pid, s;
int one = 1;
const char *cp, *errorstr;
char sig, buf[BUFSIZ];
@@ -496,8 +496,7 @@
#ifdef USE_BLACKLIST
blacklist(0, STDIN_FILENO, "success");
#endif
- for (fd = getdtablesize(); fd > 2; fd--)
- (void) close(fd);
+ closefrom(3);
if (setsid() == -1)
syslog(LOG_ERR, "setsid() failed: %m");
if (setlogin(pwd->pw_name) < 0)
Cheers,
John

Post by Jeremie Le Hen
--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[John]

----- Adrian Chadd's Original Message -----

Post by Adrian Chadd
Oh holy crap yes please. Do you have commit privs to src? If not,
Reviewed by: adrian

Done - r320406

Prefer to maintain them right where they are...

-John

Post by Adrian Chadd
-adrian

Post by John
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen

Post by Slawa Olhovchenkov

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

1. Create port
2. Port unmantained
3. Port broken
4. Port removed.
5. Lack of functionality.

Feel free to step in to help with the maintenance :-).

Let's commit this little snippet which is a major win for HA heads
with 10 of thousands of file descriptors open...
Index: libexec/rshd/rshd.c
===================================================================
--- libexec/rshd/rshd.c (revision 316672)
+++ libexec/rshd/rshd.c (working copy)
@@ -191,7 +191,7 @@
struct passwd *pwd;
u_short port;
fd_set ready, readfrom;
- int cc, fd, nfd, pv[2], pid, s;
+ int cc, nfd, pv[2], pid, s;
int one = 1;
const char *cp, *errorstr;
char sig, buf[BUFSIZ];
@@ -496,8 +496,7 @@
#ifdef USE_BLACKLIST
blacklist(0, STDIN_FILENO, "success");
#endif
- for (fd = getdtablesize(); fd > 2; fd--)
- (void) close(fd);
+ closefrom(3);
if (setsid() == -1)
syslog(LOG_ERR, "setsid() failed: %m");
if (setlogin(pwd->pw_name) < 0)
Cheers,
John

Post by Jeremie Le Hen
--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Jeremie Le Hen]

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.

See you in a month for the removal!

-- Jeremie

Post by Jeremie Le Hen
Thanks.
-- Jeremie

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
--
Jeremie Le Hen

--
Jeremie Le Hen

[Jeremie Le Hen]

I've slacked a bit but here we are:
https://reviews.freebsd.org/D12573

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!
-- Jeremie

Post by Jeremie Le Hen
Thanks.
-- Jeremie

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
--
Jeremie Le Hen

--
Jeremie Le Hen

--
Jeremie Le Hen

[John]

Have you picked up the recent changes to the code in your port?

----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!
-- Jeremie

Post by Jeremie Le Hen
Thanks.
-- Jeremie

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
--
Jeremie Le Hen

--
Jeremie Le Hen

--
Jeremie Le Hen

--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Jeremie Le Hen]

Post by John
Have you picked up the recent changes to the code in your port?

Yes I did: https://github.com/jlehen/bsdrcmds/commit/3bc90c337176af0953b4194c14825ea14300de90

-- Jeremie

Post by John
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!
-- Jeremie

Post by Jeremie Le Hen
Thanks.
-- Jeremie

Post by Jeremie Le Hen
Hey folks,
I remember when I was still barely out of my teenagehood, people were
mostly using ssh/scp while rtools (rsh, rlogin, ... for the
youngsters) were left in place as a courtesy for legacy production
systems still relying it on them.
Fast forward to 2017 (so yes, 15 years later), stack-clash [1] sorely
reminds us that suid binaries are an attack surface. I don't even need
to mention that it's a healthy engineering practice to remove unused
code, both from a maintenance and security perspective.
Therefore, I hereby propose to remove rtools from the base system. I
acknowledge this will likely cause troubles for a handful of people
who are still relying on it for good or bad reasons. But the flipside
is that the attack surface of millions of FreeBSD installed out there
will be reduced.
- disable from the build on head and let it soak for one month
- remove rtools from the base.
What do you guys think? Any preferred color for the bikeshed? :)
[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
--
Jeremie Le Hen

--
Jeremie Le Hen

--
Jeremie Le Hen

--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Julian H. Stacey]

Post by John
Have you picked up the recent changes to the code in your port?
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573
=20

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!

NO ! It's maddening, code vandals periodicaly wanting to delete working code
& pontificating what others globaly should be denied, & forced to do & not do.

One example why FreeBSD should not delete rlogin & telnet etc
3 days ago, a host with broken sshd (bad shared libs version
number), was rescued by ssh to trusted parent host, then rlogin
from that parent host to underlying jail.

3rd party code vandals are Not fit to decide what code should be
denied globaly in other peoples' environments. By all means leave off by
default in /etc/inetd.conf as now, but do Not Vandal Delete !

BSD is not Microsoft replete with masses of clueless users. BSD
includes skilled users who may wish to make their own risk assessments,
without interference.


Cheers,
Julian

[Jeremie Le Hen]

Post by Julian H. Stacey

Post by John
Have you picked up the recent changes to the code in your port?
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573
=20

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!

NO ! It's maddening, code vandals periodicaly wanting to delete working code
& pontificating what others globaly should be denied, & forced to do & not do.
One example why FreeBSD should not delete rlogin & telnet etc
3 days ago, a host with broken sshd (bad shared libs version
number), was rescued by ssh to trusted parent host, then rlogin
from that parent host to underlying jail.
3rd party code vandals are Not fit to decide what code should be
denied globaly in other peoples' environments. By all means leave off by
default in /etc/inetd.conf as now, but do Not Vandal Delete !
BSD is not Microsoft replete with masses of clueless users. BSD
includes skilled users who may wish to make their own risk assessments,
without interference.

I know I shouldn't be replying to this message but I will do it
nonetheless, once and for all.

You can install net/bsdrcmds and be happy again. I've even modified
inetd.conf(5) to use the path of the port's binary.

This was announced and approved. Disabling it from inetd.conf(5)
wouldn't have solved the setuid issue. I suggest you re-read the
original email explaining the proposal:
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html

It surely displeases a small percentage of users but this reduces the
attack surface for 100% of them. Additionally, it reduces the FreeBSD
project maintenance cost

-- Jeremie

Post by Julian H. Stacey
Cheers,
Julian
--
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich
Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Rodney W. Grimes]

Post by Jeremie Le Hen

Post by Julian H. Stacey

Post by John
Have you picked up the recent changes to the code in your port?
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573
=20

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!

NO ! It's maddening, code vandals periodicaly wanting to delete working code
& pontificating what others globaly should be denied, & forced to do & not do.
One example why FreeBSD should not delete rlogin & telnet etc
3 days ago, a host with broken sshd (bad shared libs version
number), was rescued by ssh to trusted parent host, then rlogin
from that parent host to underlying jail.
3rd party code vandals are Not fit to decide what code should be
denied globaly in other peoples' environments. By all means leave off by
default in /etc/inetd.conf as now, but do Not Vandal Delete !
BSD is not Microsoft replete with masses of clueless users. BSD
includes skilled users who may wish to make their own risk assessments,
without interference.

I know I shouldn't be replying to this message but I will do it
nonetheless, once and for all.
You can install net/bsdrcmds and be happy again. I've even modified
inetd.conf(5) to use the path of the port's binary.

You added yet another wrong assumption that ports must live in
/usr/local to the base system, something that was irradicated
20 years ago and has slowly crept back in over the decades.

Post by Jeremie Le Hen
This was announced and approved. Disabling it from inetd.conf(5)
wouldn't have solved the setuid issue. I suggest you re-read the
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html
It surely displeases a small percentage of users but this reduces the
attack surface for 100% of them. Additionally, it reduces the FreeBSD
project maintenance cost
-- Jeremie

Post by Julian H. Stacey
Cheers,
Julian
--
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich
Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Jeremie Le Hen]

Post by Jeremie Le Hen

Post by Julian H. Stacey

Post by John
Have you picked up the recent changes to the code in your port?
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573
=20

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!

NO ! It's maddening, code vandals periodicaly wanting to delete working code
& pontificating what others globaly should be denied, & forced to do & not do.
One example why FreeBSD should not delete rlogin & telnet etc
3 days ago, a host with broken sshd (bad shared libs version
number), was rescued by ssh to trusted parent host, then rlogin
from that parent host to underlying jail.
3rd party code vandals are Not fit to decide what code should be
denied globaly in other peoples' environments. By all means leave off by
default in /etc/inetd.conf as now, but do Not Vandal Delete !
BSD is not Microsoft replete with masses of clueless users. BSD
includes skilled users who may wish to make their own risk assessments,
without interference.

I know I shouldn't be replying to this message but I will do it
nonetheless, once and for all.
You can install net/bsdrcmds and be happy again. I've even modified
inetd.conf(5) to use the path of the port's binary.

You added yet another wrong assumption that ports must live in
/usr/local to the base system, something that was irradicated
20 years ago and has slowly crept back in over the decades.


Leaving it to /usr/libexec would have forced all users to change it.
Presetting it to /usr/local where I suppose 95% of users install their
ports is just an optimization for the most common case. If you have a
better default in mind, please go ahead, I don't have strong feelings about
it.

Post by Jeremie Le Hen
This was announced and approved. Disabling it from inetd.conf(5)
wouldn't have solved the setuid issue. I suggest you re-read the
https://lists.freebsd.org/pipermail/freebsd-arch/2017-June/018239.html
It surely displeases a small percentage of users but this reduces the
attack surface for 100% of them. Additionally, it reduces the FreeBSD
project maintenance cost
-- Jeremie

Post by Julian H. Stacey
Cheers,
Julian
--
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich
Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

--
Jeremie Le Hen
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

--
Rod Grimes
***@freebsd.org
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-***@freebsd.org"

[Cy Schubert]

In message <***@fire.js.berklix.net>, "Julian H.
Stacey

Post by Julian H. Stacey

Post by John
Have you picked up the recent changes to the code in your port?
----- Jeremie Le Hen's Original Message -----

Post by Jeremie Le Hen
https://reviews.freebsd.org/D12573
=20

=

Post by John

Post by Jeremie Le Hen

Post by Jeremie Le Hen

Post by Jeremie Le Hen
So the first step was to create a port with FreeBSD rcmds, here we
https://reviews.freebsd.org/D11345

The port has been submitted and RCMDS are disabled by default from the
base system.
See you in a month for the removal!

NO ! It's maddening, code vandals periodicaly wanting to delete working code
& pontificating what others globaly should be denied, & forced to do & not do
.
One example why FreeBSD should not delete rlogin & telnet etc
3 days ago, a host with broken sshd (bad shared libs version
number), was rescued by ssh to trusted parent host, then rlogin
from that parent host to underlying jail.
3rd party code vandals are Not fit to decide what code should be
denied globaly in other peoples' environments. By all means leave off by
default in /etc/inetd.conf as now, but do Not Vandal Delete !
BSD is not Microsoft replete with masses of clueless users. BSD
includes skilled users who may wish to make their own risk assessments,
without interference.

Ahh but there are masses clueless UNIX, Linux, and BSD users. I deal with
these people on a daily basis at $JOB (to them it's %JOB). They're
developers, mostly java developers but others too, who only understand
Microsoft, and that just barely if even that. Worse is the approval they
have for sudo privileges. It's scary. Protecting users from themselves is
the right thing to do.

Part of the issue with rcmds is they don't support encryption, which is why
MIT created kerberized versions of the same utilities. Removing rcmds
solves half the problem. The other is rhosts, implemented by pam_rhosts.
Why in the world do we still allow IP address based authentication? (I
suppose it's OK on a local home network with one or two family members as
users.) Seriously, rhosts is the major reason why rcmds is insecure.

It was pointed out that pam_rhosts is still used by sshd. I think that's
asking for trouble. It's time to discard the rhosts baggage. It's insecure
and why ssh keys were developed in the first place. rhosts should be
deprecated and removed prior to 13.

P.S. This is one issue. There are two others I'd raise here but let's focus
on this one first.

[Cy Schubert]

In message <***@fire.js.berklix.net>, "Julian H.
Stacey

Mcl's long held animosity to me distracts. Better to consider ideas
not by author, but on merit or otherwise, & maybe improve them.

I think you might be reading too much into it.

To bring this on topic. Fortune needs to go. The process to remove it has
commenced and will after review be implemented.

Why? Games should be, if anywhere, in ports. Take for example what Red Hat
has done. There are no games in Red Hat 6. Sure you might find some in EPL.
And as of RHEL 7, absolutely nothing. I suspect that they've made the
choice to avoid problems like this. We should do likewise. I would fully
support removal of games from ports as well but I might tolerate them there
-- why if I install gnome or kde do I want to give up MB or GB of precious
disk to games?

This is 2017. I really don't understand why there is so much angst about
this.

Lastly. I'm not totally against games. My 4 and 5 year old grandkids play
games on game tablets. However I would never let my grandkids even see what
fortune spits out. Much of it was offensive. I would have been ashamed had
they seen some of the outputs.

Fortune in base is totally indefensible and for that matter even in ports
it is. It absolutely has to go. I fully support Benno's effort.

To repeat: To say that mcl has animosity toward you is really unfair.
--
Cheers,
Cy Schubert <***@cschubert.com>
FreeBSD UNIX: <***@FreeBSD.org> Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.

Commit bits are a privilege. Contentious commits forced through
before discussion, should by policy be automaticaly reverted,
& committers bit suspended, pending committer peer review - Not with
reference to the desirability or otherwise of a commit, but for
imposing on FreeBSD without prior discussion.
Commiter conduct reviews should be seperate from
discussion of desirability of a contentious commit.

Cheers,
Julian
--
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munic
h
Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printabl
e.
http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU
.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Eugene Grosbein]

Post by Cy Schubert
Fortune in base is totally indefensible and for that matter even in ports
it is. It absolutely has to go. I fully support Benno's effort.

Please don't mix fortune(6) C code with contents of src/usr.bin/fortune/datfiles.

The code src/usr.bin/fortune/{fortune|strfile} is valuable and independend of exact datfiles
and there is no reason to remove it from the base as we have no alternatives for the task whey solve.

[Cy Schubert]

Post by Eugene Grosbein

Post by Cy Schubert
Fortune in base is totally indefensible and for that matter even in ports
it is. It absolutely has to go. I fully support Benno's effort.

Please don't mix fortune(6) C code with contents of src/usr.bin/fortune/datfi
les.
The code src/usr.bin/fortune/{fortune|strfile} is valuable and independend of
exact datfiles
and there is no reason to remove it from the base as we have no alternatives
for the task whey solve.

Putting my Canadian hat on instead of being my frustrated self today:

I think the way forward is to replace fortune in base with a shell script
to conditionally execute ${LOCALBASE}/bin/fortune and if not found advises
the user to ask their sysadmin to install a fortune port/package.

I have a revision in to do the removal and plan on creating a series of
ports based on bsdgames. However I'm totally willing to let someone else
take the lead on this.

I think this is acceptable.

[Rodney W. Grimes]

Post by Cy Schubert

Post by Eugene Grosbein

Post by Cy Schubert
Fortune in base is totally indefensible and for that matter even in ports
it is. It absolutely has to go. I fully support Benno's effort.

Please don't mix fortune(6) C code with contents of src/usr.bin/fortune/datfi
les.
The code src/usr.bin/fortune/{fortune|strfile} is valuable and independend of
exact datfiles
and there is no reason to remove it from the base as we have no alternatives
for the task whey solve.

I think the way forward is to replace fortune in base with a shell script
to conditionally execute ${LOCALBASE}/bin/fortune and if not found advises

YEA!!!!! Someone that actually knows it is suppose to be called LOCALBASE
and not a hardcoded /usr/local!! I believe a few dozen of these have
slipped in to base over the years.

Now where is a virtual phk beer I can send to Cy?

Post by Cy Schubert
the user to ask their sysadmin to install a fortune port/package.
I have a revision in to do the removal and plan on creating a series of
ports based on bsdgames. However I'm totally willing to let someone else
take the lead on this.
I think this is acceptable.
--
Cheers,