On Apr 19, 2012 10:37 AM, "Thomas Bächler" wrote:

Am 18.04.2012 21:20, schrieb Eric Bélanger:

...

Hi,

Currently, the inetutils packages provide the old unsecure r* family of tools. There is currently a bug report [1] asking for the removal of rexec as it it particularly unsecure. As these things are old and I suppose everyone has moved to more secure apps like ssh/sftp, I'm thinking about removing all these r* tools.

Just because they're insecure doesn't mean we shouldn't provide them. There are probably enough people that use this, and it is their choice.

There's always the AUR...

...

Also, there is another bug report [2] about removing /bin/domainname. This wrapper script is currently broken and users using NIS probably already have yp-tools installed, which provides its own /usr/bin/domainname. This will also fix a future conflict whenever we'll get rid of /bin.

+1

...

/usr/bin/telnet /usr/sbin/telnetd

Any objections, comments?

By the above argument, we should also remove telnetd.

On Thu, 19 Apr 2012 14:04:25 +0200, Florian Pritz wrote:

On 19.04.2012 10:56, Tom Gundersen wrote:

...

On Apr 19, 2012 10:37 AM, "Thomas Bächler" wrote:

...

Am 18.04.2012 21:20, schrieb Eric Bélanger:

...

Hi,

Currently, the inetutils packages provide the old unsecure r* family of tools. There is currently a bug report [1] asking for the removal of rexec as it it particularly unsecure. As these things are old and I suppose everyone has moved to more secure apps like ssh/sftp, I'm thinking about removing all these r* tools.

Just because they're insecure doesn't mean we shouldn't provide them. There are probably enough people that use this, and it is their choice.

There's always the AUR...

So we should put shadow and sshd into the AUR because the user could enable sshd with simple password authentication (our default), create an account called "test", set it's password to "test" and forget about it?

Most systems are behind a NAT router or hopefully at least a simple stateful firewall so even if someone enables rexec you can't connect to it from the outside. If you don't trust your LAN you are likely already screwed anyway.

The problem with rexec is that it contains a remote root exploit because you can just login with any password. This has been known for a long while and nobody upstream cares about it. If nobody cares about a serious security bug like this, then this software should not be in core. As for telnet/telnetd: if you don't care about encryption you should be able to set that up. AFAIK telnetd doesn't allow you to login with any password, so there's no reason to remove telnetd from inetutils.

On Thu, Apr 19, 2012 at 1:47 PM, Eric Bélanger wrote:

On Thu, Apr 19, 2012 at 8:10 AM, Jan de Groot wrote:

...

On Thu, 19 Apr 2012 14:04:25 +0200, Florian Pritz wrote:

...

On 19.04.2012 10:56, Tom Gundersen wrote:

...

On Apr 19, 2012 10:37 AM, "Thomas Bächler" wrote:

...

Am 18.04.2012 21:20, schrieb Eric Bélanger:

...

Hi,

Currently, the inetutils packages provide the old unsecure r* family of tools. There is currently a bug report [1] asking for the removal of rexec as it it particularly unsecure. As these things are old and I suppose everyone has moved to more secure apps like ssh/sftp, I'm thinking about removing all these r* tools.

Just because they're insecure doesn't mean we shouldn't provide them. There are probably enough people that use this, and it is their choice.

There's always the AUR...

So we should put shadow and sshd into the AUR because the user could enable sshd with simple password authentication (our default), create an account called "test", set it's password to "test" and forget about it?

Most systems are behind a NAT router or hopefully at least a simple stateful firewall so even if someone enables rexec you can't connect to it from the outside. If you don't trust your LAN you are likely already screwed anyway.

The problem with rexec is that it contains a remote root exploit because you can just login with any password. This has been known for a long while and nobody upstream cares about it. If nobody cares about a serious security bug like this, then this software should not be in core.

Exactly. That's the main motive behing the bug report. If removing all the r* tools is too drastic, I could instead only remove rexec/rexecd and keep the others in the package. Would that be a better solution?

I'll wait a couple of days and if there's no more input, I'll remove rexec/rexecd and domainname and keep the rest of the binaries in the package as it seem to be a good compromise.

...

As for telnet/telnetd: if you don't care about encryption you should be able to set that up. AFAIK telnetd doesn't allow you to login with any password, so there's no reason to remove telnetd from inetutils.

Yes, I didn't want to got too far in the cleanup.  That's why I kept things like telnet, ftp and talk even though most people probably use ssh/sftp and IRC/Jabber.

Eric