Bugzilla Bug 274963

There are a few different netkit-rsh bugs, but I'd like to point out at least
that it partially doesn't work with our current pam setup.

Given the code is stale, and that it already had quite a few problems in the
past I'd like to get rid of it, the problem is that it's currently an rdep of a
few packages and we should probably get rid of it first. Since tonight I'm not
at home, I'd like just to point them out here until I get back and can take
care of them on a per-package basis.

app-shells/pdsh/pdsh-2.14.ebuild:       rsh? ( net-misc/netkit-rsh )
app-shells/pdsh/pdsh-2.16.ebuild:       rsh? ( net-misc/netkit-rsh )
app-shells/pdsh/pdsh-2.17.ebuild:       rsh? ( net-misc/netkit-rsh )
app-shells/pdsh/pdsh-2.18.ebuild:       rsh? ( net-misc/netkit-rsh )
net-analyzer/sara/sara-6.0.4.ebuild:    net-misc/netkit-rsh
net-analyzer/sara/sara-7.0.3b.ebuild:   net-misc/netkit-rsh
net-analyzer/sara/sara-7.5.6.ebuild:    net-misc/netkit-rsh
net-analyzer/sara/sara-7.8.1.ebuild:    net-misc/netkit-rsh
net-analyzer/sara/sara-7.8.4.ebuild:    net-misc/netkit-rsh
net-misc/netkit-rsh/netkit-rsh-0.17-r9.ebuild:# $Header:
/var/cvsroot/gentoo-x86/net-misc/netkit-rsh/netkit-rsh-0.17-r9.ebuild,v 1.18
2009/01/12 15:44:51 gmsoft Exp $
net-misc/sitecopy/sitecopy-0.16.3_p17.ebuild:DEPEND="rsh? ( net-misc/netkit-rsh
)
sys-cluster/lam-mpi/lam-mpi-7.0.4.ebuild:       !crypt? ( net-misc/netkit-rsh )
sys-cluster/lam-mpi/lam-mpi-7.1.2.ebuild:       !crypt? ( net-misc/netkit-rsh
)"
sys-cluster/lam-mpi/lam-mpi-7.1.4.ebuild:       !crypt? ( net-misc/netkit-rsh
)"
sys-cluster/lam-mpi/lam-mpi-7.1.4-r1.ebuild:    !crypt? ( net-misc/netkit-rsh
)"
sys-cluster/mpich2/mpich2-1.0.3.ebuild: !crypt? ( net-misc/netkit-rsh )
sys-cluster/mpich2/mpich2-1.0.3-r1.ebuild:      !crypt? ( net-misc/netkit-rsh )
sys-cluster/mpich2/mpich2-1.0.6.ebuild: !crypt? ( net-misc/netkit-rsh )
sys-cluster/torque/torque-2.3.6.ebuild: !crypt? ( net-misc/netkit-rsh )"
x11-apps/xsm/xsm-1.0.1-r1.ebuild:       net-misc/netkit-rsh"

you might not like rsh, but some of us rely on it.  if you dont like the pam
handling, then scrub it, but removing the package is absolutely not an option.

Then find somebody to maintain the pam-side of it, since I'm not going to
continue doing this and leaving the package broken for months is not exactly
the best choice.

my comment was pretty clear.  if you dont like the pam handling in rsh, then
simply remove it.  if that aspect matters to someone, then they can step up to
the plate.  ive never used the pam aspect of rsh and it hasnt been a problem --
i use this thing pretty much every day.

Wouldn't be too nice.. unless you just need the client side?

yes, i only use the client

Okay so may I switch this to a removal for the server and then I can see if any
of the depending packages need the server at all?

Gone the server, gone the PAM subsystem, and probably gone most of the possible
future security issues too...

correct me if i'm wrong, but how is removing the server completely less nice
than simply removing pam support ? ;)

i dont personally care about the server, but i imagine people who are in the
same situation as me do -- they're using it on embedded systems only.  the
referenced bugs here have to do with pam only that i can see.  i still think
dropping USE=pam is the way to go.

(In reply to comment #7)
> correct me if i'm wrong, but how is removing the server completely less nice
> than simply removing pam support ? ;)
> 
> i dont personally care about the server, but i imagine people who are in the
> same situation as me do -- they're using it on embedded systems only.  the
> referenced bugs here have to do with pam only that i can see.  i still think
> dropping USE=pam is the way to go.
> 
I agree. I understand that most people whould find this silly, but I'm still
using rsh/rlogin a lot both in my home LAN, where there are some vintage PCs
that encryption would stress, and in classes where I like teaching the history
and evolution of UNIX and INTERNET protocols ("once upon a time there were FTP,
TELNET, GOPHER and a weirdo named RSH on the ARPANET ...").

netkit-rsh is a package that no other package should depend on, so that only
people who really want it would install it. But it would be those peoples'
responsibility understanding the security issues that both the protocol and the
implementation pose. I think it's not wise deciding in favor or against the
presence of a particular, totally optional, package in portage depending on
what trouble some unenlightened people might cause themselves installing,
misconfiguring and running it or any server.
I did have to hack /etc/pam.d/rsh to be able to run rshd withous incurring in
the "Permission denied" error, but I will not blame it on Gentoo the day when
the Internet Security Police is going to knock on my door.

If security is the only concern, then I think removing the package altogether
is overkill. Eigther netkit-rsh drops USE=pam, or it installs a more permissive
/etc/pam.d/rsh and prints a nice and big message to the user that he's
installing and running it at his own risk.

The problem is that we _do_ have packages depending on netkit-rsh so a lot of
users who DON'T CARE about this get it installed.

(In reply to comment #9)
> The problem is that we _do_ have packages depending on netkit-rsh so a lot of
> users who DON'T CARE about this get it installed.
> 

Diego, I'm afraid I was too verbose and the point was not that easy to
understand.
Given the situation you point out, in my opinion the solution is to remove the
dependencies on netkit-rsh. It should /not/ be, in my opinion, the removal of
the package.
Regards,