Re: [Twisted-Python] ssl APIs

[Glyph Lefkowitz]

> On Dec 3, 2015, at 9:14 PM, meejah  wrote:
> 
> 
> I've been fooling around with the Twisted SSL APIs.
> 
> I'd like to add a "loadPEM" and documentation to ssl.KeyPair; shall I
> open a ticket and start this, or is there a reason it doesn't have a
> loadPEM() like some of the other classes (or any docstrings)? It is
> exported as a public class in "ssl".

Please go ahead and do it.

> Also I'm wondering why CertificateOptions takes actual OpenSSL objects
> for args, instead of the Twisted equivalents; this leads to code
> accessing ".original" all the time if you use Twisted APIs to load
> Certificate (and friends) which seems .. odd. Perhaps either a
> Certificate *or* the correct underlying OpenSSL object could be
> accepted?

Wow!  I am so glad someone else finally noticed this! :-)

Basically: yes, this is odd.  It is a result of a miscommunication (or rather, 
lack of communication) between the designers and the maintainers of that system.

A long time ago, I designed a "just enough" API for TLS (for Vertex, even, not 
really for Twisted), which is what got adopted into Twisted and eventually 
became _sslverify.py.  However, this was very much incomplete; it wasn't really 
designed for the 99% use-case (running an HTTPS server).

OpenSSLCertificateOptions was just a private implementation detail; it was the 
object returned by PrivateCertificate.options().  (Hence its somewhat odd name: 
'options', which has now become the convention; see optionsForClientTLS).  
However, the signature of .options() was tough to extend, since it just takes 
"*authorities".  Given Vertex's use-case that sort of made sense but it really 
doesn't belong in the general-purpose library of twisted.internet.ssl.

Anyway, I digress: the point is that these classes were lying around, basically 
undocumented, when Hynek Schlawack showed up and began his otherwise excellent 
feature additions to Twisted's TLS stack, among .  When asked "what is the 
'good' ContextFactory class", the answer he got was unanimously 
'OpenSSLCertificateOptions'.  So he did what seemed reasonable: start adding 
features to that class, and then make it public.  I took my eye off the ball 
for a release or two and by the time I checked back, "CertificateOptions" was 
the recommended public interface, warts and all :).

I want to be clear that despite the fact that there are problems with the 
factoring here, if you're writing TLS server code with Twisted today you should 
absolutely be using CertificateOptions; its interface is crummy but its 
implementation is very solid; again, Hynek did some really excellent work.  As 
the interface changes, the implementation should stay largely the same.

If you want to fix this, rather than continue to mangle this architectural 
monstrosity, I think we should develop something symmetrical to the new, mostly 
pretty good optionsForClientTLS - 
https://twistedmatrix.com/documents/15.5.0/api/twisted.internet.ssl.html#optionsForClientTLS
 

 - which operates entirely in terms of high-level wrapper objects defined in 
twisted.internet.ssl.  Make an 'optionsForServerTLS', which can have a simpler 
interface, because it will just accept relevant configuration parameters for 
server TLS, and under the covers still use CertificateOptions.  Initially we 
can provide the 'extraCertificateOptions' escape-hatch as we have with 
'optionsForClientTLS', but once we've got a nice way to deal with esoterica 
like selecting TLS protocol versions and selecting cipher suites in those APIs, 
we can deprecate and remove the escape-hatch and be left with a clean function. 

So, are you up for contributing an 'optionsForServerTLS'?

> There also doesn't seem to be a way around importing
> OpenSSLCertificateAuthorities from _sslverify (i.e. "private" class) if
> you want to give optionsForClientTLS() more than a single certificate as
> trustRoot. The only way I can see is to construct one of those from a
> list of OpenSSL certificate instances and pass that as trustRoot=


Yes, that is in fact an oversight.  No need to write a ticket up yourself; you 
can just fix this one:

https://twistedmatrix.com/trac/ticket/7671 


Thanks a ton for your interest, it would be great to get more people interested 
in TLS to maintain this stuff!

-glyph___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] [INCOMPATIBLE CHANGE] Removing Gadfly support from adbapi

[Amber "Hawkie" Brown]

So, apparently, a long time ago, there was a database called Gadfly, and 
Twisted used to test adbapi against it. However, since then, we've moved on 
from Python versions that gadfly supports, so it outright doesn't work now -- 
not buggy, not weird -- just doesn't even import.

This doesn't change any user facing code, but does change some tests, and even 
though it's covered under the compatibility policy, I thought I'd put it on the 
ML anyway. :)

You can find the code at https://twistedmatrix.com/trac/ticket/8119. We do not 
require any signoffs to remove it, this email is purely informational.

- Amber


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Attaching the release number to a closed/merged ticket

[Adi Roiban]

Hi,

I would like to ask you if you think that is a good idea to have the
version of Twisted in which the changes associated with a ticket.

The use case would be: Someone search the net for something related to
Twisted (a bug or some feature) and the land to a Trac ticket. Just by
looking at the Trac ticket that person should see if the ticket is still in
work, is invalid or changes were made in release YY.NN

---

My proposal for implementing this is:

Each release will have a new milestone with the same name called
'next-release'.

Once the changes for a ticket were merged the ticket is assigned to the
'next-release' milestone.

When release is done, the next-release is renamed to the release name and
all previous tickets will be auto-updated.

A new milestone called 'next-release' is created.

Invalid or duplicate tickets should not have the 'next-relesese' milestone.

---

Amber commented that using milestones for such a thing is not a good idea
and that we should use tags like: landed-in-15.5, landed-for-15.5 ... and
keep milestones like Python-3 unchanged.

I don't like tags as when a ticket is landed we don't know if next release
will be16.0 or 15.6.

We can use a 'next-release' tag and when a release is done, check all
tickets and update their tag.



Please send your suggestions and comments.

Thanks!


-- 
Adi Roiban
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] twisted.web response.py questions

[peter]

hi,


looking over:
https://twistedmatrix.com/documents/14.0.2/_downloads/response.py


im not really sure why one would use the line:

self.remaining  =  1024  *  10


this suggest to me that one knew what kind of page size was 
expected...but what if you dont?

wouldnt it make more sense to use someting like this:

def dataReceived(self, bytes):
self.page_content = self.page_content + bytes


this would sum up all the data until connectionLost is called.
and in connectionLost():

def  connectionLost(self,  reason):
print  'Finished receiving body:',  reason.getErrorMessage()
self.finished.callback(self.page_content)


and then print it?




also i dont get why one would use

 return  finished


in cbRequest. where is this finished returned to?
its called via:

d.addCallback(cbRequest)

isnt the result from cbRequest thrown away?
i would expect the line to read:
new_deferred = d.addCallback(cbRequest)



thx for your answers






___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [INCOMPATIBLE CHANGE] Removing Gadfly support from adbapi

[Jason Williams]

We don't use Gadfly but I really appreciate you mentioning the changes like 
this on the ML. :)

Sent via iPhone

> On Dec 4, 2015, at 04:07, Amber Hawkie Brown  
> wrote:
> 
> So, apparently, a long time ago, there was a database called Gadfly, and 
> Twisted used to test adbapi against it. However, since then, we've moved on 
> from Python versions that gadfly supports, so it outright doesn't work now -- 
> not buggy, not weird -- just doesn't even import.
> 
> This doesn't change any user facing code, but does change some tests, and 
> even though it's covered under the compatibility policy, I thought I'd put it 
> on the ML anyway. :)
> 
> You can find the code at https://twistedmatrix.com/trac/ticket/8119. We do 
> not require any signoffs to remove it, this email is purely informational.
> 
> - Amber
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Suggested plan for GitHub migration

[Craig Rodrigues]

On Thu, Dec 3, 2015 at 7:07 PM, Glyph Lefkowitz 
wrote:

> The important thing about a "checklist" though, is checking things off -
> how will that be kept up to date in sync with what has actually happened?
>
>
The checklist is written using the GitHub flavored markdown syntax for
checklists:

https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments

so when the tasks are completed, this checklist will be updated by changing:

   [ ] task item foobar

to

  [X]  task item foobar

and committing the updated checklist to GitHub.

Adi and Amber are on board with this, so it should be fine.
--
Craig
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] OSCAR stopped working and we didn't notice

[Glyph Lefkowitz]

According to this stack overflow question:

http://stackoverflow.com/questions/34095372/python-twisted-words-protocols-oscar-default-implementation-no-longer-connects-t
 


our OSCAR protocol implementation no longer works with the live AIM service.

I suspect we just need to bump some version numbers (we claim to be a version 
of Windows AIM from 2001 or so, I think) but it might be interesting to figure 
out some kind of integration testing strategy for these proprietary protocols 
so that we actually find out before users start posting stuff to random other 
websites.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Attaching the release number to a closed/merged ticket

[Glyph Lefkowitz]

> On Dec 4, 2015, at 4:51 AM, Adi Roiban  wrote:
> 
> Hi,
> 
> I would like to ask you if you think that is a good idea to have the version 
> of Twisted in which the changes associated with a ticket.
> 
> The use case would be: Someone search the net for something related to 
> Twisted (a bug or some feature) and the land to a Trac ticket. Just by 
> looking at the Trac ticket that person should see if the ticket is still in 
> work, is invalid or changes were made in release YY.NN 
>  
> ---
> 
> My proposal for implementing this is:
> 
> Each release will have a new milestone with the same name called 
> 'next-release'. 
> 
> Once the changes for a ticket were merged the ticket is assigned to the 
> 'next-release' milestone.
> 
> When release is done, the next-release is renamed to the release name and all 
> previous tickets will be auto-updated.
> 
> A new milestone called 'next-release' is created.
> 
> Invalid or duplicate tickets should not have the 'next-relesese' milestone.
> 
> ---
> 
> Amber commented that using milestones for such a thing is not a good idea and 
> that we should use tags like: landed-in-15.5, landed-for-15.5 ... and keep 
> milestones like Python-3 unchanged.
> 
> I don't like tags as when a ticket is landed we don't know if next release 
> will be16.0 or 15.6.
> 
> We can use a 'next-release' tag and when a release is done, check all tickets 
> and update their tag.
> 
> 
> 
> Please send your suggestions and comments.

By "tags" do you mean "keywords"?  If so, couldn't we just use the 
'landed-in-next' keyword and then have a little script that replaced it with 
'landed-in-15.6' at the time of the release?

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [INCOMPATIBLE CHANGE] Removing Gadfly support from adbapi

[Glyph Lefkowitz]

> On Dec 4, 2015, at 4:07 AM, Amber Hawkie Brown  
> wrote:
> 
> So, apparently, a long time ago, there was a database called Gadfly, and 
> Twisted used to test adbapi against it. However, since then, we've moved on 
> from Python versions that gadfly supports, so it outright doesn't work now -- 
> not buggy, not weird -- just doesn't even import.
> 
> This doesn't change any user facing code, but does change some tests, and 
> even though it's covered under the compatibility policy, I thought I'd put it 
> on the ML anyway. :)
> 
> You can find the code at https://twistedmatrix.com/trac/ticket/8119. We do 
> not require any signoffs to remove it, this email is purely informational.
> 
> - Amber

I think the all-caps policy-compliant "INCOMPATIBLE CHANGE" was maybe a little 
overkill, given it's not actually incompatible under the policy definition, but 
thanks for announcing nonetheless :).

The purpose of testing with gadfly was just to have a database that didn't 
require an external process set up; I don't think anyone seriously used Gadfly 
ever.  So the modern equivalent would be sqlite3 - do we test against that?  (I 
seem to recall that we do...)

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [INCOMPATIBLE CHANGE] Removing Gadfly support from adbapi

[Amber Brown]

We don't! Those tests never run, because "import sqlite" doesn't work on 2.7. 
Today's plan is to put up a patch to test stdlib sqlite3 and pysqlite2 :)

On 5 Dec 2015 09:29, Glyph Lefkowitz  wrote:
>
>
> > On Dec 4, 2015, at 4:07 AM, Amber Hawkie Brown  
> > wrote: 
> > 
> > So, apparently, a long time ago, there was a database called Gadfly, and 
> > Twisted used to test adbapi against it. However, since then, we've moved on 
> > from Python versions that gadfly supports, so it outright doesn't work now 
> > -- not buggy, not weird -- just doesn't even import. 
> > 
> > This doesn't change any user facing code, but does change some tests, and 
> > even though it's covered under the compatibility policy, I thought I'd put 
> > it on the ML anyway. :) 
> > 
> > You can find the code at https://twistedmatrix.com/trac/ticket/8119. We do 
> > not require any signoffs to remove it, this email is purely informational. 
> > 
> > - Amber 
>
> I think the all-caps policy-compliant "INCOMPATIBLE CHANGE" was maybe a 
> little overkill, given it's not actually incompatible under the policy 
> definition, but thanks for announcing nonetheless :). 
>
> The purpose of testing with gadfly was just to have a database that didn't 
> require an external process set up; I don't think anyone seriously used 
> Gadfly ever.  So the modern equivalent would be sqlite3 - do we test against 
> that?  (I seem to recall that we do...) 
>
> -glyph 
>
>
> ___ 
> Twisted-Python mailing list 
> Twisted-Python@twistedmatrix.com 
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python 
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python