In telnet, everything is sent unencrypted. Even passwords. Especially passwords. Telnet does not encrypt passwords. Passwords are sent in the clear. Anyone snooping your traffic could read all of your passwords if you send them over a telnet session.
I hope that was just enough verbiage to make certain at least one person gets the message.
Yep. Plenty of verbiage. All of it invalid, however.
This code doesn't run login or link PAM. It doesn't authenticate.
No username or password will ever be prompted for, or sniffed.
The primary use of this library is for development and field debugging and for that it can be very valuable: you can connect to your app (while it's running of course) from pretty much any computer. There are also some use cases in production that expose no security risks (apps are sandboxed after all and far from every app deals with password or sensitive data).
All types of shenanigans could potentially be had with this though. I personally would not like installing an app with this lib.
Of course, it could be used poorly, like a number of other libraries (not validating HTTPS certs anyone?), and introduce a security issue which would only have an effect in apps that deal with sensitive data and transmit said data using this Telnet library.
IMO it's no different from running, say, an HTTP web server from an iOS app which a number do.
I think some people like to be all high and mighty about security issues and derive pleasure from pointing out (often adamantly) what they see as flaws while often these are expected and well understood side-effects, and in no way "real" security issues.