r* Programs Being Removed from OpenBSD -current 139
moonboy writes: "This post over at OpenBSD Journal tells of the r* programs (rsh, rlogin, rcopy, etc) being removed from the -current tree. Can Telnet and FTP be far behind? I say good riddance."
BSD is not dying, it's busy cleaning (Score:5, Insightful)
Creating the symlinks just adds complexity to a system that doesn't need it.
Re:BSD is not dying, it's busy cleaning (Score:2)
Dave
Re:BSD is not dying, it's busy cleaning (Score:2)
Now removing Perl altogether? I don't think that's a great idea at all. But I haven't read the other article yet, so I can't comment.
Re:BSD is not dying, it's busy cleaning (Score:1)
you obviously didn't read anything.
They are removing Perl from the configure/system scripts, and taking perl out of the *base* system. They did this for realistic reasons, not because they are 'limiting a choice'. And on most machines it will be installed by default anyway (just not used when you do something like compile your kernel).
Choic is good. But I don't like to have bijilions of programs chosen for me I'd never use. Make a nice minimalistic choice for me, and I'll pkg_add -r "perl5.6.1" when it fits best.
Re:BSD is not dying, it's busy cleaning (Score:5, Informative)
The reasons they are getting rid of it in the base system are numerous. The top reason in my mind is that Perl is growing enormous. It's a damn useful tool, but it isn't necessary for the base system, especially with the size it's getting. If you need it, install it. Simple.
Re:BSD is not dying, it's busy cleaning (Score:1)
Re:BSD is not dying, it's busy cleaning (Score:1)
This makes total sense and fits better with Perl community than having any sort of miniperl or castrated perl that fits better size-wise as part of core OS. Having an element that is used by some 10-15 scripts to be larger than kernel and other OS tools taken together is, in a way, ridiculous.
Re:BSD is not dying, it's busy cleaning (Score:5, Interesting)
As for telnet, using it to run login shells is idiocy, but it's the only standardized way to run interactive services. It comes disabled by default, so including it is not a security risk. And when you someday need a little interactive network program *right now*, it's damn convenient. E.g., if you needed to stick a load monitor on your database server, just write a little program that talks on standard input and output, and tell telnet to use it instead of a shell. Instant results, little risk of breaking anything, and any client can access it.
Re:BSD is not dying, it's busy cleaning (Score:3, Informative)
Re:BSD is not dying, it's busy cleaning (Score:2)
Re:BSD is not dying, it's busy cleaning (Score:2, Informative)
Anyway, I think the point is to remove these services, not to remove the clients. It is a security risk when it's so tempting to use it, but it's so vulnerable to exploits.
Re:BSD is not dying, it's busy cleaning (Score:2)
Besides, the current state of affairs is not the Unix Way: telnetd should be an autonegotiating filter for interactive terminals, and nothing more. It should never have known anything about logins or shells in the first place.
Re:BSD is not dying, it's busy cleaning (Score:2)
Re:BSD is not dying, it's busy cleaning (Score:3, Flamebait)
No it isn't. FTP, with its separate control and data connections, made sense fifteen years ago; but now it causes terrible headaches for network and firewall administrators. In addition, FTP doesn't have any standardized mechanism for name-based hosting.
As far as I can see, there is no excuse for using FTP any longer, for any purpose.
Re:BSD is not dying, it's busy cleaning (Score:1)
Re:BSD is not dying, it's busy cleaning (Score:2)
I believe the exact words were (Score:2)
Re:I believe the exact words were (Score:2)
Front: "God is dead." - Neitzsche
Back : "Neitzsche is dead." - God
Re:BSD is not dying, it's busy cleaning (Score:1)
Re:BSD is not dying, it's busy cleaning (Score:1)
I think.
Re:Fucking summarize (Score:1, Informative)
One Step in the Right Direction (Score:1, Redundant)
Re:One Step in the Right Direction (Score:1)
FreeBSD Good, Beer Good, Pussy Better.
wow, so late (Score:1, Redundant)
But, better late than never, I s'pose.
Darwin? (Score:3, Interesting)
i just checked my 10.2.4 and it has rlogin, and perl. Perl is quite usefull, but i agree it shouldnt be part of a default install. the rtools are a big risk, and rightly should be gotten rid of. with ssh and secure versions of most of these r tools, there existance is moot.
Apple prides itself on the power of unix, simplicity of a mac, and i think it works great. (havent touched my pc in weeks) but i question if a desktop os really needs the rtools.
Re:Darwin? (Score:1)
10.2 hasn't been released yet.
Something has been lost here... (Score:4, Insightful)
For starters, BSD is not dying in my eyes. Linux is great, I love it, but it is seriously bloated. 'But seraphim,' you say, 'you are a fag man for thinking these thingz.' I have recently bought SuSE 8.0 Pro. It is terribly bloated. Its really good for a desktop machine, but for a down and dirty linux box, its just not there. I have also used Redhat 7.0-7.2. They are extremely bloated as well. Not quite to the M$ extreme, but still dangerous. Slackware is the only linux I have used that gets me feeling that I am involved in the console and that its working with me, rather than me forcing it to do things. BSD is a down and dirty OS. Its great for just digging your teeth in and tearing into. It is not your fancy pants linux distro or desktop GUI OS (i leave that up to my new iMac
And on the issue of Perl. Perl is not being taken out of FreeBSD. It has not been rebuked by the FreeBSD staff and shunned to the 9th circle of hell. It is, however, not included into the base install. Saving, around 40mb, i believe. Now you say 'You silly fagtrot, thats not that much.' Well, yes and no. Yes it isnt a lot when you are running BSD on a AMD 2100XP with a 80g hard drive. I , however, run my BSD on a 486 with a 800mb hard drive. Space is key to me. If i want to install perl, i simply say, 'Hey there BSD, install me some perl.' Otherwise i dont really need it.
Hopefully this will clear some things up.
Re:Something has been lost here... (Score:1)
[mailto:owner
Sent: Wednesday, May 15, 2002 9:44 AM
To: announce@freebsd.org
Subject: Perl5 is leaving the base system for 5.0 and after!
Hello folks!
It has been decided after some debate to remove Perl5 from the "Base FreeBSD" sources. This decision was not taken lightly, and was taken in consultation with (but not seeking the approval of) the perl5 developer community.
There are 2 main reasons for this:
1) Perl5 is getting larger very fast, and FreeBSD cannot afford the time and space to build and maintain it.
2) Upgrading the "base perl" is a nightmare that regularly breaks upgrades and cross-builds, to the intense annoyance of the FreeBSD developer community.
Speaking as the "Perl5 guy", keeping FreeBSD's "base perl" up to date was hellish, and folks who wish a return to that state should please consider doing this work in my place. BEWARE! This job is not trivial!
PERL IS NOT BEING OSTRACISED! FreeBSD is not taking this action because of any dispute between the FreeBSD community and the Perl community - such a dispute DOES NOT EXIST! In fact, the Perl community have been exemplary in their attempts to understand the problem, and in their proposals to deal with it. FreeBSD DOES NOT HATE PERL!
Some time in the future, perl may be split in half, such that the core language and the standard libraries may be separately installed. In such a case, FreeBSD might be in a position to better deal with the problem of the very large perl libraries. Such splitting will be done by the perl community, NOT by us, although we will be taking note.
In the meanwhile, the Perl5 Port will continue to be available, and continued discussion indicates that there is very substantial support for it to be installed by default (or near-default) by sysinstall.
This will result in a FreeBSD that has effectively the same Perl5 that is kept up-to-date in ports, rather than the one that is left to rot in STABLE.
This update will _NOT_ be MFCed. The first FreeBSD that has no perl in the default sources will be 5.0-RELEASE, when that is released at the end of this year. FreeBSD-4.n will continue with the perl that it currently has.
The ports system will continue to support Perl5.
M .sig is umop ap!sdn
--
o Mark Murray
\_
O.\_ Warning: this
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org [freebsd.org]
Re:Something has been lost here... (Score:1)
Re:Something has been lost here... (Score:1, Insightful)
For sake of argument, I'll assume this isn't a troll for now ... apparently enough moderators did.
You make this statement, and never back it up with evidence. You state cursory observations based on your experiences with two distributions of Linux. You do not even go into detail--or even offer a superficial explanation--as to why you feel these are bloated. You have seemingly just chosen a) the largest [7 CDs or a DVD] distribution, SuSE, and b) RedHat which seems to be the most common target for abuse (some of it deserved, I could grant) -- however, you do not offer any reason why you feel these are bloated.
I am running SuSE 7.1 on all of my Linux machines now -- some of them are still stock installs, some just updated using Yast, and two of them don't look anything like SuSE anymore excepting Yast and a couple other things I've kept around. One, my laptop, doesn't look anything like SuSE at all--not even Yast [SuSE's installer/configurer/auto-updater]. The reason I chose SuSE was because of the number of included programs in the distro, which, when you're on a dialup connection, saves a lot of headache and time. Things I use often, and need the latest version, I might still go out and get their package/source but for most things, I no longer need to. Just because they provide you with 7 CDs worth of data [four binary, three source I think] doesn't mean that you have to install everything. This is often the complaint with MSWin--forced install.
My laptop has SuSE's "minimal" install, with the addition of selections from the "developers" package (by default minimal doesn't install gcc or make). I've built it up from there. I've even built up a SuSE deb based system at one point ... which I don't really feel like doing again...
I have no clue what you mean by "dangerous" (aside from some security issues in the default RH installs, granted ...)
I still do not know what you consider "bloat" however. Many Linux distros are trying to make their system usable on the desktop, hence SuSE's "default with Office" option. As stated, SuSE has other options such as "minimal" "default" "full" and options to set it up as a server config by default, and very easy to use individual package selection during install [and after]. If you don't want the glitz--such as kde and gnome--don't install it, I haven't. The same is available for BSD systems as well [I have KDE installed on a P120 Free box which is set up for guest access in my house].
I also suggest Debian, unless you're adversed to popular package management methods. I've heard more than one person remark that debian is little more than FreeBSD with a Linux kernel. However, no Linux system prevents you from accessing the underlying configuration files (which is what I can only assume you mean) or just running from a terminal. I've heard bad things about Lycoris in this respect, but they make it clear that's not what they're trying for--i assume once it's installed though you've got access to everything just like everything else, including on the Zaurus.
Distros like SuSE and RH are just offering a centralized configuration tool which you can choose to use. I know SuSE's works in console mode just as well as in X, and isn't all that different from /sys/stand on Free.
You can also try Debian or Yellow Dog on your iMac. SuSE also runs well, I'm told. I have no experience with the PPC version of any of them however.
For the record, up until a couple years ago, I was running an old version of RH on a 386 without any problems. That's what the Linux kernel was designed for, and that's still what even the latest RH states as minimum system requirements.
I think it clears it up nicely. You sir, are a troll.
Re:Interesting discussion (Score:1)
Re:Interesting discussion (Score:1)
Of course, this doesn't apply if you believe in the whole moderation system deep down in your heart, and don't use mod points to punish or reward like most moderators do.
Re:Interesting discussion (Score:4, Informative)
Why post comments on Slashdot's BSD section? Slashdot is a terrible news distribution system, and even worse is the BSD section which is almost completely ignored by the admins.
The point? There are plenty of other BSD sites to discuss these things on.
http://Deadly.org for OpenBSD specific stuff.
http://BSDToday.com for more general BSD stuff.
http://www.daemonnews.org/
http://www.maximumbsd.com/
http://www.freebsdf
http://bsdvault.net/
http://bsdatwork
http://www.bsdfreaks.nl/
And even more, lesser known sites. So my question is, why worry about the slashdot / bsd site which only gets a new bit of info every couple of weeks? There are plenty of better options which have news, tutorials, tips, etc. for those interested in BSD.
Re:Interesting discussion (Score:2)
that Slashdot is the only where Slashcode
performs quite usable (i.e. several functions
are missing in the versions used by other sites),
and that only here a broad number of readers
gets in touch with BSD.
OTOH, wrt not _commenting_ BSD stories here (and
not even reading the comments) is usually said ok,
because nearly only trolls post.
You are a noble exception.
Heck, if I could still moderate... (this being
The Dark Side of slashdot)
Good bye (Score:1)
RSH: Haven't used it in years. Good bye.
Telnet: Client useful for accessing networking equipment in a secure environment. Haven't run the daemon on my boxes in years. Good bye.
This is a good day for security...
Re:Good bye (Score:2)
standard and will be in years.
RSH: Haven't ever used.
Telnet: Uhm... let me say a bit more:
you have to differentiate between the services
(daemons) and the clients. Running telnetd is
bad, and for the case spoken in some of the
first posts, you can write a daemon using
netcat in shell if you want, it takes ten lines or so.
But the client is good for, for example, participiating
in MUDs (I, however, use ssfe(1local) from the net/sirc
port in combination with netcat), or to quickly test
net services such as HTTP, SMTP, etc. or even chatting
in IRC (not that this couldn't be entirely taken over
by netcat, but no GNU OS I know of _has_ our (with IPv6)
netcat).
Hmmm, mixed feelings on this...... (Score:3, Insightful)
If you want FTP, download the latest version of ProFTPd or Wu-FTPd and load those, same with Apache.
Re:Hmmm, mixed feelings on this...... (Score:1)
Re:Hmmm, mixed feelings on this...... (Score:1)
Re:Hmmm, mixed feelings on this...... (Score:1)
I got a good laugh out of your reply...... (Score:2, Insightful)
A very dumb idea (Score:2, Troll)
r* tools or telnet to access a box across the
internet. However , for internal connections withing a large organisation they are *vital*.
Anyone who has worked in a large unix shop (I work in a multinational bank) knows that rlogin
and telnet are used all the time to access the various servers over the LAN and VPN , rsh is also
used to do a shell script type of RPC. Getting rid of these tools demonstrates what I've always
thought about OpenBSD , its just a toy to amuse
Theo thats not really aiming at the high end market but rather just as a web server or other
ISP type role. Fine , if thats what they want but
it'll hardly make much difference as their user base is so small it hardly registers anyway.
Bye bye OpenBSD.
Re:A very dumb idea (Score:1)
In a large unix shop I consulted for, the directors said "we want security", to which I replied "ok, but there are implications...". Long story short, they changed every script they had to comply with the new security policy: no unencrypted sensitive data. And that means, no telnet, no r* tools, no ftp, et al.
Re:A very dumb idea (Score:1, Funny)
Re:A very dumb idea (Score:1)
So now you hate OpenBSD because they're making you type pkgadd -v ftpd.tar.gz or whatever? Whaaa...
You have to install Emacs on it FCS! It aims to be an OS that is built from the ground up on each system, so that you have not the bloat. Also you are guaranteed to know about all the services by the time you get finished setting up a BSD box...
'Bye bye OpenBSD', what a tool.
Re:A very dumb idea (Score:1)
literally use terrabyte disks give a flying fuck about saving a few hundred K of disk space
on tools that they find pretty damn essential and will have to install anyway. Grow up.
Re:A very dumb idea (Score:1)
Re:A very dumb idea (Score:1)
to do their work, they could do far more damager by just trashing the databases. Guess you've
never worked in a big company have you?
Re:A very dumb idea (Score:1)
Re:A very dumb idea (Score:1)
in coders have had access to the production machines as well since the team that wrote the
code also did the support.
Next...
Re:A very dumb idea (Score:2)
Why? Why don't you think about it for a while.
Accountability. Disgruntled worker has God privs across a bunch of mission critical servers (critical to not only the business but to customers in a bank scenario). Servers are in a secure room with video surveilance and the syslog server and line printers are in another secure room which few people have access to or are even aware of all together.
Our poor disgruntled worker would be STUPID BEYOND BELIEF to fuck with any server or network gear in that environment with either his ugly head on video tape or his username plastered all over syslog printouts that he can't get to...
However, this lucky bastard has YOU as a boss and since you called the shots you said, "ah to hell with secure tools, we'll just keeping using the good old r* tools since we trust our staff and our network is behind a nice black firewall!".
So, our disgruntled worker is smarter than you, he sniffs some passwords of people he never liked and a few he now no longer likes...
Now those servers that have been dd if=/dev/zero of=/dev/sda have YOUR name printed on the syslog printouts instead of his.
Guess you've never worked in a big company have you?
So what position do you hold at this bank? Teller?
Re:A very dumb idea (Score:1)
network, yeah right, dream on. Where do you work, the CIA? If I need to access the trading systems
here I just telnet in from my sparcstation (assuming I had a login), there is no ssh here FYI.
Re:A very dumb idea (Score:2)
Huh!? Are you serious? I really want to know your position in this bank, because I am disgusted.
As I have stated elsewhere in this thread, the stock exchange I work for has at least 4 seperate physical networks.
Production: mission critical, it's why we exist and having it compromised would hurt a lot of people and a lot a heads would roll.
Development: This is Production V2.0beta. This needs to be seperated from Production for obvious reasons. Mistakes cost little here and much more people (as required) can have the access they need here to build the new Production system. This network is important in it's own right, it hosts what will some day be on the Production network. If a disgruntled worker put something nasty into this system, it might (slight chance) make it into the Production network when it gets cut over some day, so it needs to be secured as much as possible from people who don't need access to it.
Security (often called Surveilance): Any questions why this needs to be physically seperate, with access provided to only an elite few who associate as little as possible with the rest of the company, including Production sys admins?
Staff (sometimes called Office): A network for ordinary people who use systems on this network and Production systems with very low privs. Often they have seperate machines for work on the seperate Staff and Production networks. They are the interface between the mission critical Production systems and customers, who are also critical to the business.
Each network is extremely important and seperation of each to the maximum that allows the business to work is very much the norm in a company like a stock exchange or a bank.
CIA? How many networks do you rekon they have! They probably have entire departments, as far as staff and systems go, duplicated who watch each other!
Hell, fraud or vandalism of bank or stock exchange systems is something that would rank extremely highly as something the CIA would investigate. Their first contacts would be the guys from security, some of which probably once worked for the CIA!
If I need to access the trading systems here I just telnet in from my sparcstation (assuming I had a login), there is no ssh here FYI.
Sounds like to me you are big noting yourself. Sparcstation sounds cool eh?
You seem to have no clue about a banks network, either that or you work for the First Bank Of Afganistan.
Re:A very dumb idea (Score:2)
Vital, as if there is no better alternative?
With the trend of outsourcing IT HR, bringing IN lots of potentially untrustworthy staff and putting OUT very clued up staff who are now very disgruntled, I would guess that previously already endangered LANS are now becoming even more threatened.
Staff on the way out will be sniffing and key logging their peers, bosses and the new contractors and the new contractors don't have much to loose either, being just another contractor.
Anyone who has worked in a large unix shop (I work in a multinational bank)
I know a very large multinational bank which uses OpenBSD on it's firewalls.
knows that rlogin and telnet are used all the time to access the various servers over the LAN and VPN
So the fact that security is usually lacking somehow makes the use of plain text OK within a LAN environment?
Bye bye OpenBSD.
Bye bye DickHEAD.
Re:A very dumb idea (Score:1)
working in a place that has upwards of a thousand servers where the developers have to have access
to the boxes anyway to do their work.
PS: A firewall is connected to the internet , read what I wrote before you try to back up your
lame repost with the kiddies fallback of being insulting.
Re:A very dumb idea (Score:2)
The production servers are usually accessed via their serial console ports via console servers which are only connected to the security network. Few people have physical or logical access to that network and those servers. Baring that, ssh and scp is the norm where at all possible.
Thanks for letting me know the function of firewalls (my bread and butter).
However, I am merely pointing out, that plain text within a LAN is still very dangerous, especially within an org that has a lot to protect. It removes accountability from the staff because their usernames and passwords cannot be considered completely safe from other staff who may have similar privs.
OpenBSD , its just a toy to amuse Theo thats not really aiming at the high end market but rather just as a web server or other ISP type role.
How does removing insecure tools from an OS that focuses on security make that OS a toy? You can always put it back for Christs sake.
The fact is, that insecure tools are insecure on the internet and within corporate LANS.
Re:A very dumb idea (Score:2)
If you're going to use plaintext tools, you shouldn't even bother having seperate user accounts. Make one user account called "guest" with a null password. It's easier that way, ad it's effectively what you're doing when you use insecure protocols internaly.
Of course, if you're using 100% IPSec internally, then anythign that uses passwords for authentication should be fine. However, IIRC, rsh just checks the source port of the packet and then balieves that you are who you claimto be with absolutely no authentication. IPSec can't help you there.
Re:A very dumb idea (Score:2)
My wife works for a large insurance company that handles medical claims. When she was home sick, she simply rsh'd into the companies terminal server from our earthlink account!
She was not 'rooted' or hacked. In fact, her connection was much faster than the useless VPN that I am forced to use.
Multinational bank (Score:1)
I work for a large bank, it's probably the biggest one in the US, and not only are these things discouraged, but people lose their jobs if they don't remove them after they have been told to.
As for openbsd, or any os for that matter, being a toy to amuse....a tool is a tool, it does not decide how it is used.
Symbolic Importance (Score:3, Interesting)
I doubt anyone smart enough to install and run OpenBSD is going to be stupid enough to run the r suite of utilities.
But I have to pause in remembrance, because, after all, they are the Berkeley r-suite.
I used them for many years, alongside telnet and ftp, back in the 1980's when 4.2BSD was distributed with my computer. Anyone remember doing tilde escapes to pop back to the local machine?
Even though their security model is insufficient in this present day and age, they really helped to pave the way in showing how remote computers could be accessed in a convenient and powerful way.
It's fitting that a BSD will be the first to retire this venerable set of programs.
R.I.P., r-suite.
r-suite - the weapon of a Hacker (Score:1)
Elegant tools for a more civilized age.
Re:Symbolic Importance (Score:2, Interesting)
fox:~ % ~?
Supported escape sequences:
~. - terminate connection
~R - Request rekey (SSH protocol 2 only)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
Re:Symbolic Importance (Score:2)
You can still do tilde escapes in ssh or at least openssh.
Most of my usage has been on X displays running multiple virtual terminal sessions.
In the old days, on a single green screen CRT, I had a lot more need for quickly switching sessions in the same terminal window, using tilde escapes and sending jobs into background, etc. Not so much anymore, though.
Re:Symbolic Importance (Score:2)
Also works with ssh.com's ssh:
I suspend sessions all the time. Lots of fun when you bounce around hosts, eg, ssh from A to B, from B to C, from C to D, etc. You have to remember to hit ~ the correct number of times to suspend to the right machine.
Re:Symbolic Importance (Score:1)
regards
rmstar
Re:Symbolic Importance (Score:2)
there are some linux distros out there that don't have the r- suite
You're right.
If I'd thought a minute I probably would have figured out that such Linux distros exist; Tin Foil Hat [shmoo.com] comes to mind.
Re:Symbolic Importance (Score:1)
No big deal... (Score:2, Insightful)
There's a number of "what about me" folks out there -- who have some mitigating circumstance to need those tools (see here [sigmasoft.com]). It seems that these folks are just speaking out to hear themselves speak. Its not like these services are being excluded from the ports tree. Even if they were, you can still grab the source and build it yourself -- hell, there are still binary packages out there that you can just build.
Lastly, as stated in the thread here [sigmasoft.com], its just the servers that are getting the axe, the clients stay...so all of the valuable tools (telnet, rlogin, etc) aren't going away.
-Turkey
Re:No big deal... (Score:1)
thoroughly, because r-* clients are going away
too, the only one left as three days ago was rsh.
checkout the cvs interface [openbsd.org] if you want
more info
Re:No big deal... (Score:1)
However, I am 100% sure that (at the very least) there will be a binary tarball floating around with the clients.
-Ethan
Thank Fordness... (Score:3, Interesting)
I'm an OpenBSD user, and a Perl advocate. I love Perl, but not everyone does. Not everyone needs it, just like not everyone needs Python or tcl/tk.
OpenBSD is the closest thing I've seen to an operating system in a long time. When I install an OS, I want to chose what to turn on, not hope I turned off everything I didn't need. I want to know dozens of eyes have done their best to be sure the OS is secure.
The ports collection is far better than any package management tool I've used (Sun pkgadd, Linux RPM). Not only is it good, but OpenBSD's is the best of any BSD I've used (Free and Net) because it's clean. There is only a tiny chance a port you try and build won't work (::leering at FreeBSD::) and it's so easy that I don't mind doing a make;make install to get Perl.
All that said, Theo's recent rant about r* utils makes perfect sense. Get rid of it!
And while we're at it, toss telnet out with the bathwater. Anyone who isn't using ssh to connect to a remote machine is *begging* to get owned. The only way some people are going to use secure tools is if we force them to. I know at work until I turn telnet off people will use that over ssh because it's familiar, because they don't want to upgrade the 100 year old version of QVTTerm they have.
As for FTP - don't let the door hit you in the ass on the way out. I've been using scp for so long I get physically ill when I see this:
ftp>
Yeah it works, but it's a gaping hole. If people want it, fine, but build the daemon you want from the ports collection. The idea of inetd housing all these "critical" services is just an invite to get owned.
I'm not a huge security nut (my boss won't use a grocery store card because his "marketing data is worth more than what they give me"), but in the battle for securie systems, we are losing! Servers here at work are breeding like rabbits, and everyone is not as savy as you and I. We need to do whatever we can to nudge them in the right direction, not just for their own sake, but for everyones sake.
Re:Thank Fordness... (Score:1, Interesting)
Don't lose telnet. (Score:3, Insightful)
Ssh - I use for connecting to other machines.
Telnet - I use for testing webservers, mail servers, news servers, testing whether ssh servers are alive and what version they're running, etc etc.
Just because the telnet DAEMON is undesirable doesn't mean the client is so too.
Re:Don't lose telnet. (Score:2)
Re:Don't lose telnet. (Score:2)
Re:Don't lose telnet. (Score:2)
The name of the command is actually "nc" - like any proper unix tool it has a terse, easy-to-chord-type name ("n" and "c" are on different fingers :)
they need to make sure... (Score:4, Funny)
Re:they need to make sure... (Score:1)
Wait, OBSD isn't XCU (and don't you dare make this as troll because my name is on the PR that got it into FreeBSD).
Security, redundancy, minimalism (Score:1)
Let us try to separate the security matters.
A protocol can be insecure - say if it provides no reliable means of authentication, or if it transmits all information in clear text.
Implementations of a secure protocol can be insecure - that is, buggy -, and implementations of insecure protocols can do their best not to add any insecurity.
BSD is not dead, nor is it dying.
The r-tools are insecure protocols, since they transfer sensible information in clear text. I am not for enabling the daemons by default installs.
But I don't think they should be removed.
The clients should definately not be removed, in my opinion, I do not see any insecurity in having an rlogin client installed.
A system will not be much more secure than its admin is capable. Security has always been a compromise.
I believe in security, I appreciate OpenBSD's security code auditing teams, yet OpenBSD's claim "Four years without a remote root security hole in the default install!" does not impress me too much. If the default install is with everything disabled, or configured in some rather restricted way, it is not much of worth to most. People talk all the time about network security, disabling services and daemons, etc. Let us remember the more common type of security problems still, local. Most systems serve users. Local security is just as important, if not more. And not all holes immediately give superuser access to the exploiter, yet they are dangerous. Would it have been "4 years without an exploitable security problem in the OpenBSD code base", this would mean quite more already.
So I think telnet, rlogin, rsh, rexec and ftp should be left in. telnetd, rlogind, rshd, rexecd, and ftpd should also be left in, just disabled by default in inetd, administrators will enable those they need as they know what they are doing.
The code of all those should be audited just like the rest of the distribution. Data being transmitted as plain text is not a security hole in the system. It is known to the admin, just as it is known that passwords can be guessed brute-force.
In an internal academic/corporate network, usually some hosts are trusted, and some users are. Each organization has its security policy, describing how to decide what is trusted. If an host is trusted, the route from it is just as trusted. No encryption will help here. Sometimes rhosts based authentication bypassing is useful.
Encryption won't solve everything. It is a bad illusion for anyone that if the communication is encrypted, it can suddenly be all 100% trusted and safe. A well administered site ran by competent admins and with a good security policy, I would trust much more than a site where ssh and encryption is trusted for everything.
Also, as always, there is a point of interoperability, and compatibility. You cannot switch all your organization, definately not all the environment around it, to different protocols and utilities that easily, and with the Internet attached, it gets even more difficult.
If you think that all utilities/work methods can be secured just by replacing them like this, it isn't so easy.
I am pro advancement, and I think changing things, switching to more secure protocols/systems, is all a good idea, but at its time, as the site's administrators consider it... It cannot be done at once, and should not be done by the maintainers of the distribution.
As for Perl on FreeBSD, I'm very much for it. Most of the BSD systems I use are FreeBSD, then BSDi BSD/OS... Saving a few tenths of megabytes in the distribution, just as simplifying the build and installation process is a good step, Perl is nowhere as standard for a network as the r-tools are, and the system's core scripts/tools shouldn't depend on it. Where it is wanted, install it from the ports tree, or just build it from plain sources...
It might be good idea if the r-tools could be just a backward compatibility part of the ssh stuff... So say, ftp, unless given a specific flag, will by default do sftp, and resort to old style ftp only if that failes, and rsh will be ssh, which will also support the rsh/rlogin/etc. protocols...
All that, though, is just my 2^-2 cent...
How to transfer files securely and quickly? (Score:2)
Re:How to transfer files securely and quickly? (Score:1)
two comments (Score:2)
The R commands need to go away but I'm wondering if the best option is to fix them properly. The idea here is to put together a library (maybe a fork of getops) so that you can take most standard programs that use stdio and make r versions of them by linking to the proper library. This way things like rmt (remote mag tape) and its friends restore and dump would all still work in a modern enviroment. There is no current version of dump or restore that works the way old rmt versions do and most of us still like to do backups from time to time.
Why remove them? (Score:1)
So usually i end up using rcp to download files to a new machine from a distribution server, rcp dist@ip:/files/bleh . is much easier than ftping or using scp, and since the access is download-only and anonymous.. i`m not really bothered about someone else sniffing the connection. r* is also much faster an s*, since there is no encryption overhead... downloading large files over a 100mbit switched lan where the fileserver is a p200, is certainly a LOT quicker.
FTP/Telnet DEFINATELY should not be removed, the telnet command has far more uses than connecting to dedicated telnet servers, for instance you can use it to test other text-based protocols like smtp, http and pop3.
FTP also, like rcp.. is very usefull for file distribution.. If you have files you want people to access easily, such as opensource software.. it makes sense to use a low overhead protocol like ftp, rather than an encryption-heavy protocol. Afterall, who is going to bother sniffing your traffic if they can just download the files themselves anyway?
r* Programs Being Removed from OpenBSD -current (Score:1)
Re:One more sign . . . (Score:1)
. . . that *BSD is dying. BTW, f-ir-st!
I heard sporks and anonymous cowards were dying, something to do with bsd users who finally couldn't take the idiocy...
Re:One more sign . . . (Score:1)
Re:r, r and r: The Axis of Evil (Score:1)
So, with secure commands to meet the need, why keep old ones around?