[prev in list] [next in list] [prev in thread] [next in thread]
List: python-dev
Subject: [Python-Dev] Fwd: Request for pronouncement on PEP 493 (HTTPS verification backport guidance)
From: Toshio Kuratomi <a.badger () gmail ! com>
Date: 2015-11-24 15:19:22
Message-ID: CABVPEKpwtweLG5Gi=OedSc+=f111e0F7Hz9jYYSxqCGBUAWuyw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Nov 24, 2015 6:28 AM, "Laura Creighton" <lac@openend.se> wrote:
>
> In a message of Tue, 24 Nov 2015 14:05:53 +0000, Paul Moore writes:
> >Simply adding "people who have no control over their broken
> >infrastructure" with a note that this PEP helps them, would be
> >sufficient here (and actually helps the case for the PEP, so why not?
> >;-))
>
> But does it help them? Or does it increase the power of those who
> hand out certificates and who are intensely security conscious over
> those who would like to get some work done this afternoon?
>
My reading is that it will help more people but lockdown environments can
still trump their users if they wish.
If a distribution wishes to give users of older python versions the option
of verifying certificates then they will need to backport changes
authorized by previous peps. By themselves, those changes would make it so
environment owners and application authors are in complete control. If an
application is coded to do cert verification and the remote end has
certificates that aren't recognized as valid on the client end then the
user would have to change the client application code to be able to use it
in their environment (or figure out how to get the ca for the remote end
into their local certificate store... in extreme cases, this might be
impossible - the ca cert has been lost or belongs to another company).
This pep tells distributions how they might give the client end a bit more
power when they backport. The settings file allows the client to toggle
verification site wide. The environment variable allows clients to toggle
it per application invocation. Both of these situations are better for a
client than having the backport and nothing else. Both of these can be
shut down by an environment owner with sufficient authority to limit what's
running on the client (not sure the scope of the environment owner's powers
here so I thought I should acknowledge this factor).
So basically: backporting other peps (to increase security) will subtract
power from the clients. This pep specifies several facilities the
backporters can implement to give some of that power back to the clients.
-Toshio
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_quote">On Nov 24, 2015 6:28 AM, "Laura \
Creighton" <<a href="mailto:lac@openend.se" \
target="_blank">lac@openend.se</a>> wrote:<br>><br>> In a message of Tue, 24 \
Nov 2015 14:05:53 +0000, Paul Moore writes:<br>> >Simply adding "people \
who have no control over their broken<br>> >infrastructure" with a note \
that this PEP helps them, would be<br>> >sufficient here (and actually helps \
the case for the PEP, so why not?<br>> >;-))<br>><br>> But does it help \
them? Or does it increase the power of those who<br>> hand out certificates and \
who are intensely security conscious over<br>> those who would like to get some \
work done this afternoon?<br>><br>My reading is that it will help more people but \
lockdown environments can still trump their users if they wish.<div> <br>If a \
distribution wishes to give users of older python versions the option of verifying \
certificates then they will need to backport changes authorized by previous peps. \
By themselves, those changes would make it so environment owners and application \
authors are in complete control. If an application is coded to do cert verification \
and the remote end has certificates that aren't recognized as valid on the client \
end then the user would have to change the client application code to be able to use \
it in their environment (or figure out how to get the ca for the remote end into \
their local certificate store... in extreme cases, this might be impossible - the ca \
cert has been lost or belongs to another company).<br><br>This pep tells \
distributions how they might give the client end a bit more power when they backport. \
The settings file allows the client to toggle verification site wide. The \
environment variable allows clients to toggle it per application invocation. Both \
of these situations are better for a client than having the backport and nothing \
else. Both of these can be shut down by an environment owner with sufficient \
authority to limit what's running on the client (not sure the scope of the \
environment owner's powers here so I thought I should acknowledge this \
factor).<br><br>So basically: backporting other peps (to increase security) will \
subtract power from the clients. This pep specifies several facilities the \
backporters can implement to give some of that power back to the \
clients.<br><br>-Toshio</div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div>
</div>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-marcsub-zyf4%40marc.info
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic