[issue1926] NNTPS support in nntplib
StevenJ added the comment: I too was just looking at NNTPS support because I have a need for it. The latest patch looks like great work and I think the things it implements are needed for this library. But it seems to me that the latest patch combines 3 things which might otherwise be able to be separately considered. NNTPS, START_TLS (RFC 4642) extension and AUTHINFO extension (RFC 4643). It may be that START_TLS and AUTHINFO are indivisible, I need to read those more, but shouldn't that be a new topic of discussion as this feature request is for NNTPS support? I also don't understand the difficulty with plain NNTPS as it doesn't need a new interface a very simple patch (attached) achieves NNTPS?? (Most of the patch is test case and variant defaults. The actual NNTPS code is just: +# Make sure we can actually use ssl if its attempted. +if ssl_context: + self.sslcontext = ssl_context + self.sock = self.sslcontext.wrap_socket(self.sock) I also don't understand why START_TLS and AUTHINFO need to change how the module is interfaced to (separating log in/authentication, etc), my reading of START_TLS and AUTHINFO seem to me that it should all be under the covers. It even explains this in Section 7 of "Using TLS with IMAP, POP3 and ACAP" [TLS-IMAPPOP]. That the idea is "It just works". So surely if someone uses this module and they do not specify NNTPS and it supports START_TLS and AUTHINFO and so does the server then it just works. Otherwise it seems a bunch of NNTP Extension requirements and processing spills over to the users of this module when they can probably be contained locally?? Perhaps there needs to be a separate feature request "START_TLS and AUTHINFO extension support for nntplib" so the issues and any necessary interface changes can be considered in isolation from simple NNTP over SSL? I think it would be nice to have NNTPS in for 3.2. -- nosy: +StevenJ Added file: http://bugs.python.org/file19485/nntps_only_patch.diff ___ Python tracker <http://bugs.python.org/issue1926> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1926] NNTPS support in nntplib
StevenJ added the comment: Hi Julien, >> I also don't understand why START_TLS and AUTHINFO need to change >> how the module is interfaced to (separating log in/authentication, etc) > Because once you have used AUTHINFO, STARTTLS is no longer a valid > command in a session. I understand this, but doesn't this mean the init function needs to change to something like: init: if capability STARTTLS is advertised STARTLS stuff reget capabilities because STARTTLS changed them probably Now handle AUTHINFO Stuff Is there a case where a server advertises STARTTLS and one would not use it? If so then couldn't that just be handled with an option to the class inhibiting it? This is one of the reasons why I proposed dividing the job across two features. 1. Simple NNTPS which seems to be the most common secured NNTP in use at the moment and is easy to implement, and verify (either as an improvement to the NNTP class or as a new NNTP_SSL class). 2. SASL AUTHINFO/STARTTLS Extension handling implementation and improvements. There are also other bugs with properly handling capabilities at start related to this, are there not? http://bugs.python.org/issue10287 -- ___ Python tracker <http://bugs.python.org/issue1926> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1926] NNTPS support in nntplib
StevenJ added the comment: The only comment I have is, if the caller needs to organise when to auth and instigate tls then for completeness getcapabilities() should have an option to force a reget of the current capabilities, in line with rfc3977 5.2.2: > An NNTP client MAY cache the results of this command, but MUST NOT > rely on the correctness of any cached results, whether from earlier > in this session or from a previous session, MUST cope gracefully > with the cached status being out of date, and SHOULD (if caching > results) provide a way to force the cached information to be > refreshed. As it stands, the nntplib can cause the cached capabilities to be refreshed at certain points automatically (as it should), but I think it should be possible for the caller of the method to also specify that fresh capabilities are required and not cached ones. something like this perhaps? : mynntp.getcapabilites(refresh=True) -- ___ Python tracker <http://bugs.python.org/issue1926> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
