disallow assignment to unknown ssl.SSLContext attributes
I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime
Thank you Thomas for concisely and fairly reporting your experience, and based on that suggesting a way to improve Python. Thank you for taking the time to do this. Here's a typo that caused a bug (which inconvenienced the original poster): context.miunimum_version = ssl.TLSVersion.TLSv1_3
context.minimum_version = ssl.TLSVersion.TLSv1_3
Here's the fix the original poster suggested: I'd like invalid attribute assignment to be prevented at runtime
This can already be done, if type(context) is defined using __slots__. However, a search in the docs for slots is not so helpful. https://docs.python.org/3/search.html?q=slots Some of the better search results (for the question asked) seem to be: https://docs.python.org/3/reference/datamodel.html?highlight=slots#object.__... https://docs.python.org/3/reference/datamodel.html?highlight=slots https://docs.python.org/3/howto/descriptor.html?highlight=slots I see two ideas here. One idea is to improve the documentation for __slots__, and perhaps provide tools that make it easier to create a class that uses slots. Here's a challenge. Find a page in docs.python.org that describes clearly, with helpful examples, when and how to use __slots__. The second idea, which the OP asks for, is a change to type(context) in the standard library ssl module. Here note: https://docs.python.org/3/library/ssl.html Warning Don’t use this module without reading the Security considerations. Doing so may lead to a false sense of security, as the default settings of the ssl module are not necessarily appropriate for your application. Given that context is important for security, perhaps it's worthwhile closing the door to spelling errors creating security holes. -- Jonathan
Would a static type checker have found this? On Fri, Jun 25, 2021 at 02:07 Thomas Grainger <tagrain@gmail.com> wrote:
I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to:
context.miunimum_version = ssl.TLSVersion.TLSv1_3
it should have been:
context.minimum_version = ssl.TLSVersion.TLSv1_3
I'd like invalid attribute assignment to be prevented at runtime _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RPD5OI... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
No because existence of this attribute is dynamic On Fri, Jun 25, 2021, 3:44 PM Guido van Rossum <guido@python.org> wrote:
Would a static type checker have found this?
On Fri, Jun 25, 2021 at 02:07 Thomas Grainger <tagrain@gmail.com> wrote:
I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to:
context.miunimum_version = ssl.TLSVersion.TLSv1_3
it should have been:
context.minimum_version = ssl.TLSVersion.TLSv1_3
I'd like invalid attribute assignment to be prevented at runtime _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RPD5OI... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.) So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum <guido@python.org> wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way.
Another possible solution - although I'm not sure how practical this would be - would be to have __init__ accept only specific keyword arguments. You could do something like: ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT, minimum_version=ssl.PROTOCOL_TLSv1_1) and it would work, but if you misspell "minimum_version", it would error out. That's actually what I expected it to do, based on the signature; but it doesn't, it simply ignores the argument. Not actually sure what it does with kwargs. ChrisA
On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum <guido@python.org> wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding
__slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible.
It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
So unless there's evidence that nobody does that, we're stuck with the
status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way.
Another possible solution - although I'm not sure how practical this would be - would be to have __init__ accept only specific keyword arguments. You could do something like:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT, minimum_version=ssl.PROTOCOL_TLSv1_1)
and it would work, but if you misspell "minimum_version", it would error out. That's actually what I expected it to do, based on the signature; but it doesn't, it simply ignores the argument. Not actually sure what it does with kwargs.
But that's not what the OP wrote -- his code used an attribute assignment. It looks like SSLContext just throws the *args and **kwds away. You *must* set the attribute. I don't know why it has *args and **kwds at all -- maybe so that you can subclass it and define an __init__ that takes those? It all seems a mystery to me. I've never used this directly -- I've always just used urllib's default for https URLs. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
On Sat, Jun 26, 2021 at 5:09 AM Guido van Rossum <guido@python.org> wrote:
On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum <guido@python.org> wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way.
Another possible solution - although I'm not sure how practical this would be - would be to have __init__ accept only specific keyword arguments. You could do something like:
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT, minimum_version=ssl.PROTOCOL_TLSv1_1)
and it would work, but if you misspell "minimum_version", it would error out. That's actually what I expected it to do, based on the signature; but it doesn't, it simply ignores the argument. Not actually sure what it does with kwargs.
But that's not what the OP wrote -- his code used an attribute assignment. It looks like SSLContext just throws the *args and **kwds away. You *must* set the attribute. I don't know why it has *args and **kwds at all -- maybe so that you can subclass it and define an __init__ that takes those?
It all seems a mystery to me. I've never used this directly -- I've always just used urllib's default for https URLs.
Yeah - my first thought on reading the OP's issue was "hmm, can't you just use kwargs and get them validated?", but it doesn't validate. So this would require both changing the SSLContext class *and* the calling code. Unideal, but less backward incompatible than __slots__ would be. ChrisA
On 25/06/2021 20.17, Guido van Rossum wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com <mailto:bluenixdev@gmail.com>> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way.
I agree, it is a backwards incompatible change. Also __slots__ won't work. The class has class attributes that can be modified in instances. You cannot have attributes that are both class and instance attributes with __slots__. We'd have to overwrite __setattr__() and block unknown attributes of exact instances of ssl.SSLContext. Christian
On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes <christian@python.org> wrote:
On 25/06/2021 20.17, Guido van Rossum wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com <mailto:bluenixdev@gmail.com>> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way.
I agree, it is a backwards incompatible change. Also __slots__ won't work. The class has class attributes that can be modified in instances.
Oh, I see. There are two class attributes, sslsocket_class and sslobject_class, and their docs say they can be overridden per instance. Could we perhaps create a custom descriptor that allows both per-instance and per-class assignment and lookup?
You cannot have attributes that are both class and instance attributes with __slots__. We'd have to overwrite __setattr__() and block unknown attributes of exact instances of ssl.SSLContext.
Well, if we don't think it's supported behavior to subclass SSLContext, perhaps we could do that. The bug in the OP's code (misspelling minimum_version in assignment) is pretty hard to find. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
How about an alternative frozen dataclass with a explicit replace, configure and create methods? @dataclasses.dataclass(frozen=True) class SSLContextFactory: minimum_version: TLSVersion = TLSVersion.TLSv1_2 options: ... replace = dataclasses.replace def configure(self, ctx: SSLContext): ctx.mimumum_version = self.minimum_version ctx.options = self.options ... def create(self): ctx = SSLContext() self.configure(ctx) return ctx On Fri, 25 Jun 2021, 20:52 Guido van Rossum, <guido@python.org> wrote:
On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes <christian@python.org> wrote:
On 25/06/2021 20.17, Guido van Rossum wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com <mailto:bluenixdev@gmail.com>> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way.
I agree, it is a backwards incompatible change. Also __slots__ won't work. The class has class attributes that can be modified in instances.
Oh, I see. There are two class attributes, sslsocket_class and sslobject_class, and their docs say they can be overridden per instance. Could we perhaps create a custom descriptor that allows both per-instance and per-class assignment and lookup?
You cannot have attributes that are both class and instance attributes with __slots__. We'd have to overwrite __setattr__() and block unknown attributes of exact instances of ssl.SSLContext.
Well, if we don't think it's supported behavior to subclass SSLContext, perhaps we could do that. The bug in the OP's code (misspelling minimum_version in assignment) is pretty hard to find.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VGSFW6... Code of Conduct: http://python.org/psf/codeofconduct/
It may help to think separately about existing code using ssl, and about new code. However, I'm not a user of ssl, so please doubt my opinions below. EXISTING CODE Those maintaining existing code might welcome an easy way of checking that the code doesn't have a misleading assignment. They might also appreciate a quick fix, such as using a subclass of type(context) that does have __slots__. (Such devices might not work well with all existing code.) NEW CODE Those creating new code might appreciate a new API that has been redesigned to simplify the interface and better support security audits. For example: >>> context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) >>> context <ssl.SSLContext object at 0x7f3c7d357fa8> Perhaps better is that type(context).__repr__ show the attributes of the context object (and anything inherited from the parent class). BITWISE OPERATIONS Also, the sample code (in docs ssl.html) ctx = ssl.create_default_context(Purpose.CLIENT_AUTH) ctx.options &= ~ssl.OP_NO_SSLv3 contains bitwise operations whose meaning requires some thought. -- Jonathan
On Fri, Jun 25, 2021 at 12:48:51PM -0700, Guido van Rossum wrote:
I agree, it is a backwards incompatible change. Also __slots__ won't work. The class has class attributes that can be modified in instances.
Oh, I see. There are two class attributes, sslsocket_class and sslobject_class, and their docs say they can be overridden per instance. Could we perhaps create a custom descriptor that allows both per-instance and per-class assignment and lookup?
Something like this, perhaps? https://code.activestate.com/recipes/577030-dualmethod-descriptor/ -- Steve
On Fri, Jun 25, 2021 at 11:17:09AM -0700, Guido van Rossum wrote:
On Fri, Jun 25, 2021 at 8:22 AM Bluenix <bluenixdev@gmail.com> wrote:
I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would prevent this. You would see an error similar to: AttributeError: 'MyClass' object has no attribute 'my_attribute'
That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.)
Given that this is a mildly troubling security flaw/bug/vulnerability, I think that breaking backwards-compatibility is justified. If that requires a few users to subclass SSLContext, that's a relatively small cost for fixing the bug. I don't think it is serious enough to justify it in minor releases, but we can surely fix it in 3.11 or maybe even 3.10 if we move fast? (3.10.0 candidate 1 is scheduled for August.) I have no opinion whether it should be considered serious enough to backport to older versions, but I think it justifies a small backwards- incompatible change going forward. -- Steve
On 6/25/2021 8:09 PM, Steven D'Aprano wrote:
Hi Thomas,
On Fri, Jun 25, 2021 at 09:06:58AM -0000, Thomas Grainger wrote:
I'd like invalid attribute assignment to be prevented at runtime Are you making a specific request for ssl context objects, or a general language-wide request that applies to all objects?
It seems like many of the suggestions are SSLContext specific. I don't think we should be adding __slots__ or otherwise redefining the interface to that object. Isn't this a general "problem" in python, that's always been present? Why are we trying to address the problem with this specific object? I suggest doing nothing, or else thinking big and solve the general problem, if in fact it needs solving. Eric
On Sat, 26 Jun 2021 at 01:23, Eric V. Smith <eric@trueblade.com> wrote:
On 6/25/2021 8:09 PM, Steven D'Aprano wrote:
Hi Thomas,
On Fri, Jun 25, 2021 at 09:06:58AM -0000, Thomas Grainger wrote:
I'd like invalid attribute assignment to be prevented at runtime Are you making a specific request for ssl context objects, or a general language-wide request that applies to all objects?
It seems like many of the suggestions are SSLContext specific. I don't think we should be adding __slots__ or otherwise redefining the interface to that object. Isn't this a general "problem" in python, that's always been present? Why are we trying to address the problem with this specific object? I suggest doing nothing, or else thinking big and solve the general problem, if in fact it needs solving.
I would say that the general problem highlighted here is that assigning attributes is a bad API. Given that this is already how the SSL module works, a backwards compatible way to move forwards could be defining a new class with a more typical interface and better verification of inputs etc. Oscar
As has been said, allowing arbitrary attribute assignments is standard Python. But given the security implications, it does make sense to have more validation in this case. If backward incompatibility is not an option how about raising a Warning? -CHB On Fri, Jun 25, 2021 at 6:30 PM Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
On Sat, 26 Jun 2021 at 01:23, Eric V. Smith <eric@trueblade.com> wrote:
On 6/25/2021 8:09 PM, Steven D'Aprano wrote:
Hi Thomas,
On Fri, Jun 25, 2021 at 09:06:58AM -0000, Thomas Grainger wrote:
I'd like invalid attribute assignment to be prevented at runtime Are you making a specific request for ssl context objects, or a general language-wide request that applies to all objects?
It seems like many of the suggestions are SSLContext specific. I don't think we should be adding __slots__ or otherwise redefining the interface to that object. Isn't this a general "problem" in python, that's always been present? Why are we trying to address the problem with this specific object? I suggest doing nothing, or else thinking big and solve the general problem, if in fact it needs solving.
I would say that the general problem highlighted here is that assigning attributes is a bad API. Given that this is already how the SSL module works, a backwards compatible way to move forwards could be defining a new class with a more typical interface and better verification of inputs etc.
Oscar _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KKBYSX... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
[oops, hit Send too soon] On 6/25/21 5:20 PM, Eric V. Smith wrote:
It seems like many of the suggestions are SSLContext specific. I don't think we should be adding __slots__ or otherwise redefining the interface to that object. Isn't this a general "problem" in python...
In most cases I would agree with you, but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness. -- ~Ethan~
On Jun 26, 2021, at 3:35 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
[oops, hit Send too soon]
On 6/25/21 5:20 PM, Eric V. Smith wrote:
It seems like many of the suggestions are SSLContext specific. I don't think we should be adding __slots__ or otherwise redefining the interface to that object. Isn't this a general "problem" in python...
In most cases I would agree with you, but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
That I can agree with. I was too quick to reply earlier. Eric
-- ~Ethan~ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WQV7NW... Code of Conduct: http://python.org/psf/codeofconduct/
On 26.06.2021 21:32, Ethan Furman wrote:
On 6/25/21 5:20 PM, Eric V. Smith wrote:
It seems like many of the suggestions are SSLContext specific. I don't think we should be adding __slots__ or otherwise redefining the interface to that object. Isn't this a general "problem" in python...
In most cases I would agree with you, but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
Isn't this more an issue of API design rather than Python's flexibility when it comes to defining attributes ? IMO, a security relevant API should not use direct attribute access for adjusting important parameters. Those should always be done using functions or method calls which apply extra sanity checks and highlight issues in form of exceptions. And those are possible in Python without calling type checking, linters or other extra tools to the rescue. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jun 26 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
I'd prefer a frozen dataclass with an explicit replace method On Sat, 26 Jun 2021, 21:56 Marc-Andre Lemburg, <mal@egenix.com> wrote:
On 6/25/21 5:20 PM, Eric V. Smith wrote:
It seems like many of the suggestions are SSLContext specific. I don't
we should be adding
__slots__ or otherwise redefining the interface to that object. Isn't
On 26.06.2021 21:32, Ethan Furman wrote: think this a
general "problem" in
python...
In most cases I would agree with you, but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
Isn't this more an issue of API design rather than Python's flexibility when it comes to defining attributes ?
IMO, a security relevant API should not use direct attribute access for adjusting important parameters. Those should always be done using functions or method calls which apply extra sanity checks and highlight issues in form of exceptions.
And those are possible in Python without calling type checking, linters or other extra tools to the rescue.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 26 2021)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/53V2RC... Code of Conduct: http://python.org/psf/codeofconduct/
On 6/26/21 1:55 PM, Marc-Andre Lemburg wrote:
On 26.06.2021 21:32, Ethan Furman wrote:
In most cases I would agree with you, but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
Isn't this more an issue of API design rather than Python's flexibility when it comes to defining attributes ?
I think it's both, with the majority of the responsibility being on the API design.
IMO, a security relevant API should not use direct attribute access for adjusting important parameters. Those should always be done using functions or method calls which apply extra sanity checks and highlight issues in form of exceptions.
Agreed -- but Python's nature makes it easy to use attribute access to make adjustments, and that should also be constrained in security conscious objects. -- ~Ethan~
but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
It looks like there's a consensus being reached, should I create a bpo? Thomas Grainger On Sat, 26 Jun 2021 at 23:03, Ethan Furman <ethan@stoneleaf.us> wrote:
On 6/26/21 1:55 PM, Marc-Andre Lemburg wrote:
On 26.06.2021 21:32, Ethan Furman wrote:
In most cases I would agree with you, but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness.
Isn't this more an issue of API design rather than Python's flexibility when it comes to defining attributes ?
I think it's both, with the majority of the responsibility being on the API design.
IMO, a security relevant API should not use direct attribute access for adjusting important parameters. Those should always be done using functions or method calls which apply extra sanity checks and highlight issues in form of exceptions.
Agreed -- but Python's nature makes it easy to use attribute access to make adjustments, and that should also be constrained in security conscious objects.
-- ~Ethan~ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/W37274... Code of Conduct: http://python.org/psf/codeofconduct/
Thomas Grainger wrote: It looks like there's a consensus being reached, should I create a bpo?
Perhaps first state what seems to be the consensus and invite further comments before going to bpo. Disclaimer: I'd like to see both: 1. Something on PyPi to help persons who are using ssl on current Python. 2. Something in a future version of Python, that constrains attribute access. We can do (1) first, and it will help inform (2). -- Jonathan
httpx.create_ssl_context() is one such utility function python -m pip install httpx python
import httpx
ctx = httpx.create_ssl_context()
Ironically the context returned doesn't support ctx.minimum_version assignment due to another hangnail in the ssl.SSLContext API! This is fixed in the default branch however https://github.com/encode/httpx/pull/1714#event-4947041362 On Mon, 28 Jun 2021, 18:32 Jonathan Fine, <jfine2358@gmail.com> wrote:
Thomas Grainger wrote:
It looks like there's a consensus being reached, should I create a bpo?
Perhaps first state what seems to be the consensus and invite further comments before going to bpo.
Disclaimer: I'd like to see both:
1. Something on PyPi to help persons who are using ssl on current Python. 2. Something in a future version of Python, that constrains attribute access.
We can do (1) first, and it will help inform (2).
-- Jonathan
On 2021-06-28 07:03, Thomas Grainger wrote:
but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness. It looks like there's a consensus being reached, should I create a bpo?
If we're going to make backwards-incompatible changes to SSLContext, might it be a good idea to make a cleaner, more Pythonic API while we're at it so that people are discouraged from doing attribute-setting at all? Why not have the class accept only valid options at creation time and raise an error if any unexpected arguments are passed? Is there even any reason to allow changing the SSLContext parameters after creation, or could we just freeze them on instance creation and make people create a separate context if they want a different configuration? I think any of these would be better than the current setup that expects people to adjust the options by manually setting attributes one by one after instance creation. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
Another problem with the assignment API is that the order the attributes are assigned is important: Eg check_hostname needs to be assigned before verify_mode or a warning is raised: https://github.com/encode/httpx/pull/1687/commits/ed9aabfeff6c18652db918bd06... On Mon, 28 Jun 2021, 19:45 Brendan Barnwell, <brenbarn@brenbarn.net> wrote:
On 2021-06-28 07:03, Thomas Grainger wrote:
but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness. It looks like there's a consensus being reached, should I create a bpo?
If we're going to make backwards-incompatible changes to SSLContext, might it be a good idea to make a cleaner, more Pythonic API while we're at it so that people are discouraged from doing attribute-setting at all? Why not have the class accept only valid options at creation time and raise an error if any unexpected arguments are passed? Is there even any reason to allow changing the SSLContext parameters after creation, or could we just freeze them on instance creation and make people create a separate context if they want a different configuration? I think any of these would be better than the current setup that expects people to adjust the options by manually setting attributes one by one after instance creation.
-- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K5ZBPH... Code of Conduct: http://python.org/psf/codeofconduct/
On 28/06/2021 20.36, Brendan Barnwell wrote:
On 2021-06-28 07:03, Thomas Grainger wrote:
but in this case the object is security sensitive, and security should be much more rigorous in ensuring correctness. It looks like there's a consensus being reached, should I create a bpo?
If we're going to make backwards-incompatible changes to SSLContext, might it be a good idea to make a cleaner, more Pythonic API while we're at it so that people are discouraged from doing attribute-setting at all? Why not have the class accept only valid options at creation time and raise an error if any unexpected arguments are passed? Is there even any reason to allow changing the SSLContext parameters after creation, or could we just freeze them on instance creation and make people create a separate context if they want a different configuration? I think any of these would be better than the current setup that expects people to adjust the options by manually setting attributes one by one after instance creation.
There won't be any backwards incompatible changes to SSLContext in near future. There might be an additional API based on PEP 543 [1] configuration object if we find time to implement it for 3.11. Christian [1] https://www.python.org/dev/peps/pep-0543/#configuration
if we find time to implement it for 3.11.
https://www.python.org/dev/peps/pep-0543/#configuration was Withdrawn would this need a new PEP?
urllib3 was also burned by this problem https://github.com/urllib3/urllib3/issues/2636 On Fri, Jul 9, 2021, 5:39 PM Thomas Grainger <tagrain@gmail.com> wrote:
if we find time to implement it for 3.11.
https://www.python.org/dev/peps/pep-0543/#configuration was Withdrawn
would this need a new PEP? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VV7ZQV... Code of Conduct: http://python.org/psf/codeofconduct/
participants (13)
-
Bluenix -
Brendan Barnwell -
Chris Angelico -
Christian Heimes -
Christopher Barker -
Eric V. Smith -
Ethan Furman -
Guido van Rossum -
Jonathan Fine -
Marc-Andre Lemburg -
Oscar Benjamin -
Steven D'Aprano -
Thomas Grainger