[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: On 9 Nov 2010 at 18:59, Antoine Pitrou wrote: > I have committed the patch in r86365, and I've made usenetrc > False by default in r86366. Thanks for contributing! Woot. I thank you. Regarding usenetrc, the NNTP.login and NNTP.starttls documentation assumed it

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: I have committed the patch in r86365, and I've made usenetrc False by default in r86366. Thanks for contributing! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: On 6 Nov 2010 at 17:23, StevenJ wrote: > 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 cap

[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

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: On 6 Nov 2010 at 11:48, Antoine Pitrou wrote: > I would rename setreadermode to _setreadermode (there's no reason to > make it public IMO). Also, I would not explicitly check "STARTTLS" in > the capabilities. It the server doesn't support it, it will issue an > er

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: > More significant than my own potentially newbie-ish > opinion is that the RFC suggests as a valid use case > the idea of a client starting up TLS or authentication > in reaction to a 483 command response, rather than right > off the bat. Yes. (Currently, it wou

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: Thanks for the patch, Andrew. It looks mostly good. I would rename setreadermode to _setreadermode (there's no reason to make it public IMO). Also, I would not explicitly check "STARTTLS" in the capabilities. It the server doesn't support it, it will issue an e

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: Here's a second version of the previous patch taking into account the errors Antoine noticed and some odds and ends from the other comments. Specifically: Comments fixed and tabs (I think...I hope...) all removed. Added explicit skip to test_nntplib when attemp

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: (Note that smtplib can give ideas for an implementation of AUTHINFO SASL with PLAIN, LOGIN and CRAM-MD5 mechanisms.) -- ___ Python tracker ___ ___

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: Hi Steven, I agree with what you suggest for the implementation. > Is there a case where a server advertises STARTTLS > and one would not use it? Yes, the overhead added by the encryption. It is what people usually mention for the reason not to use it. Howeve

[issue1926] NNTPS support in nntplib

Changes by Brian Curtin : -- nosy: -brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[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,

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: Hi Steven, > 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. The authentication p

[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 t

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: >> * starttls() should probably test the `tls_on` attribute first and >> raise a ValueError if True (as you point out, a client mustn't attempt >> to start a new TLS session if one is already active). > > ...I actually meant to do exactly that, but forgot to put th

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: On 2 Nov 2010 at 23:22, Antoine Pitrou wrote: > I'm talking about the code under "if __name__ == '__main__'". > Specifically the "-c" option for specifying an SSL context. Now I feel silly. Partly because of the mistake, partly because I did test_nntplib.py last

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: > > * the command-line option for the SSLContext won't work, since a > > context is a custom object, not a string; I would rework this part > > anyway, since I don't think separate options for the "SSL host" are > > useful (I'd rather add a SSL-enabling flag; al

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: On 2 Nov 2010 at 17:05, Antoine Pitrou wrote: > * the command-line option for the SSLContext won't work, since a > context is a custom object, not a string; I would rework this part > anyway, since I don't think separate options for the "SSL host" are > useful (I'

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: Thanks a lot for having implemented STARTTLS, Andrew! That's great news! +Since the order in which certain operations need to be done varies +between normal, SSL, and STARTTLS connections varies, some +initialization must be done in the s

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: Andrew, thank you for posting a patch. I have a couple of comments: * the command-line option for the SSLContext won't work, since a context is a custom object, not a string; I would rework this part anyway, since I don't think separate options for the "SSL h

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: Also, Julien: Thanks for mentioning the 563-discouraged thing. I added a note about it to the new documentation before submitting. -- ___ Python tracker _

[issue1926] NNTPS support in nntplib

Andrew Vant added the comment: At Antoine's suggestion I've written a new patch for this for 3.2, adding support for both SSL on 563 and STARTTLS on a normal connection. A NNTP_SSL class supports the former and a NNTP.starttls() method supports the latter. As a side effect of getting starttls

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: Regarding these two possibilities, please note that the first one is discouraged (per RFC 4642). STARTTLS is the preferrable way to start a TLS session. In some existing implementations, TCP port 563 has been dedicated to NNTP over TLS. These implementati

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: It should be noted that there are two possibilities for encrypted NNTP: - NNTPS, that is NNTP-over-SSL on port 563, as proposed here - plain NNTP with the STARTTLS capability as described in RFC 4642 For the record, gmane provides the former (on snews.gmane.org

[issue1926] NNTPS support in nntplib

Changes by Antoine Pitrou : -- dependencies: +nntplib cleanup ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue1926] NNTPS support in nntplib

Giampaolo Rodola' added the comment: Unfortunately nntplib lacks a test suite. I created #9791 to address this issue. -- ___ Python tracker ___ __

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: The patch might need a little reworking to make it work under 3.x, although probably not much. It should also, IMHO, take an instance of the new SSLContext class (*) as a parameter, rather than the keyfile and certfile args. (*) http://docs.python.org/dev/lib

[issue1926] NNTPS support in nntplib

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9309/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue1926] NNTPS support in nntplib

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9298/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue1926] NNTPS support in nntplib

Changes by Brian Curtin : -- nosy: +brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue1926] NNTPS support in nntplib

Antoine Pitrou added the comment: Yes, a test could use Google or gmane (according to the FAQ, nntps is supported: http://gmane.org/faq.php ). The test should skip gracefully (using the skipTest() API) if the connection fails, so that network errors or service unavailability don't make buildbo

[issue1926] NNTPS support in nntplib

Changes by Brian Curtin : -- stage: -> test needed versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker ___ ___ Python-bug

[issue1926] NNTPS support in nntplib

Bill Janssen added the comment: Yeah, it took me a couple of months to do a reasonable test case for the SSL code. Perhaps we could test against an existing NNTP server? Like Google's? Bill On Jan 27, 2008 6:59 PM, Ray Chason <[EMAIL PROTECTED]> wrote: > > Ray Chason added the comment: > > I

[issue1926] NNTPS support in nntplib

Ray Chason added the comment: It seems that I, or whoever writes any future test_nntplib.py, would have to understand how existing tests such as test_smtplib.py work. It looks like that one is setting up some kind of miniature mail server and accepting a connection on localhost -- neat trick, bi

[issue1926] NNTPS support in nntplib

Bill Janssen added the comment: Great, Ray. I don't see any test cases for the nntp library in the Lib/test/ directory. How can we make sure it works on the buildbots? Bill On Jan 25, 2008 12:49 PM, Ray Chason <[EMAIL PROTECTED]> wrote: > > Ray Chason added the comment: > > Here's take 2. > >

[issue1926] NNTPS support in nntplib

Ray Chason added the comment: Here's take 2. The pre-patch NNTP class has a long and complicated constructor. Rather than duplicate this constructor in NNTP_SSL, the patch converts most of the NNTP class to a new class, NNTPBase, which takes an already-connected socket as a parameter. NNTP and

[issue1926] NNTPS support in nntplib

Bill Janssen added the comment: Sounds good. If you want to develop this with 2.5.1, you can get an API-compliant version of the SSL module for 2.5.1 from http://pypi.python.org/pypi/ssl/. __ Tracker <[EMAIL PROTECTED]>

[issue1926] NNTPS support in nntplib

Ray Chason added the comment: OK, I got a copy of the Subversion sources and the new SSL library looks like just what is needed here. Examining the other protocol modules that already support SSL, I find these things: httplib has: HTTPConnection(host[, port[, strict[, timeout]]]) HTTPSConnectio

[issue1926] NNTPS support in nntplib

Bill Janssen added the comment: Unfortunately, it uses the deprecated socket.ssl calls. Re-worked to use the new SSL module, it would be OK. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1926] NNTPS support in nntplib

Christian Heimes added the comment: I assign it to janssens. He is our SSL expert. I also set the version to 2.6. New features get into the next major release. -- assignee: -> janssen keywords: +patch nosy: +janssen, tiran priority: -> normal versions: +Python 2.6 -Python 2.5

[issue1926] NNTPS support in nntplib

New submission from Ray Chason: This patch adds SSL support to nntplib. It is a followup to issue #1535659 and addresses the objections raised in the comments to that issue; it also changes the default port to 563 (nntps) rather than 119 if SSL is requested. -- components: Library (Lib)