> > This can only be fixed by a.) compile nnrpd with SSL or b.) replace nnrpd > > with a wrapper or alternatives. > c) run nnrpd from inetd.
This is not possible without the use of a secondary ip address. As i already said, innd listens on port 119 and will hand over readers to nnrpd. For most users this won't be a possible solution as they usually don't have a secondary ip address. > b is not an interesting solution. As long as you reject a (having ssl in the default binary) it is the _only_ solution which will enable STARTTLS for most users. > To implement a and ditch nnrpd-ssl I would like to see data showing > that SSL support does not use more memory as long as it's not used I'm afraid it does. USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 8876 0.0 0.4 30648 2276 pts/4 S+ 21:48 0:00 - nnrpd-ssl root 8877 0.0 0.2 22420 1516 pts/3 S+ 21:48 0:00 - nnrpd So what now? Do you really think it is an acceptable solution to ship a package which does not support a security feature like STARTTLS without having the user hack it or use a secondary ip address? Why not just use /etc/alternatives/nnrpd and have it point to either nnrpd-nossl or nnrpd-ssl? I don't think debian should make it harder than needed to enable encryption. NNTPS is a way to do it, but putting protocols inside SSL on another port is nowadays deprecated in favor of TLS upgrade through STARTTLS. We really should support that. Regards Michael -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
