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,
What is this waiting for? bug 210783 has no more arches CCed (but is still opened :-/)
