Allow ssl certificates to be specified from memory rather than files.

[kristjanvalur]

BPO	16487
Nosy	@jcea, @orsenthil, @pitrou, @kristjanvalur, @giampaolo, @tiran, @njsmith, @asvetlov, @jgehrcke, @dstufft, @Martiusweb
PRs	gh-60691: allow certificates to be specified from memory #2449
Files	sslpatch1.patch sslpatch2.patch ssl.patch ssl2.patch ssl2.patch python_16487_jgehrcke_01.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tiran'
closed_at = None
created_at = <Date 2012-11-16.15:10:15.811>
labels = ['expert-SSL', '3.8', 'type-feature', '3.7', '3.9']
title = 'Allow ssl certificates to be specified from memory rather than files.'
updated_at = <Date 2020-03-01.22:19:26.571>
user = 'https://github.com/kristjanvalur'

bugs.python.org fields:

activity = <Date 2020-03-01.22:19:26.571>
actor = 'kristjan.jonsson'
assignee = 'christian.heimes'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2012-11-16.15:10:15.811>
creator = 'kristjan.jonsson'
dependencies = []
files = ['28002', '28866', '30707', '30718', '32612', '44092']
hgrepos = []
issue_num = 16487
keywords = ['patch']
message_count = 67.0
messages = ['175691', '175692', '175701', '175709', '175741', '175779', '175806', '175809', '180734', '180736', '180737', '190997', '191018', '191828', '191838', '191847', '191859', '191860', '191862', '191868', '191922', '191923', '191924', '191936', '191937', '191938', '191941', '191942', '191957', '191970', '202800', '202828', '202829', '202832', '202833', '246488', '246489', '246492', '246494', '246495', '246496', '246555', '272585', '275288', '277173', '281457', '293908', '297068', '303514', '307153', '307154', '307296', '307298', '307299', '307320', '307322', '307357', '307372', '307373', '307377', '307380', '307681', '309841', '324686', '362692', '363074', '363101']
nosy_count = 13.0
nosy_names = ['jcea', 'orsenthil', 'pitrou', 'kristjan.jonsson', 'giampaolo.rodola', 'christian.heimes', 'njs', 'asvetlov', 'jgehrcke', 'brandon-rhodes', 'dstufft', 'martius', 'Lord Anton Hvornum']
pr_nums = ['2449']
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue16487'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9']

[kristjanvalur]

The _ssl module (and indeed the openssl lib) relies heaviliy on actual filesystem locations to load certificates. A client or a server may not want to rely on physical filesystem locations to load certificates for authentication or verification. Physical disc files are cumbersome and present a management burden in the presence of multiple processes.

This patch adds extensions to the _ssl.c file which allows certificates, keys and certification chains to be provided by file contents, rather than file name.

The ctx.load_cert_chain and ctx.load_verify_locations take additional arguments to specify the data on this form.

the ssl.wrap_socket does not add arguments, rather the function is polymorphic in that the conents of the certfil/keyfile are examined and treated as file-data if beginning with -----BEGIN. the ca_certs is similarly treated as a list of file contents, if it is a list, (rather than a string)

This patch is the result of work at CCP for deploying ssl clients and servers in an isolated environment without having to resort to temporary disk files.

[kristjanvalur]

(the patch contains a local change to set the location of the 'external' dir, please disregard this.

[pitrou]

(the patch contains a local change to set the location of the
'external' dir, please disregard this.

Can you upload a cleaned up patch then? :)

[kristjanvalur]

Can't right now. It's only relevant for pcbuild anyway so you can test it for Unix if you want without fear. Don't worry, I always give my patches a cleanup before committing them.
Meanwhile, I'd welcome comments on the substance.

[pitrou]

Can't right now. It's only relevant for pcbuild anyway so you can test
it for Unix if you want without fear. Don't worry, I always give my
patches a cleanup before committing them.

I don't want to review a patch if you tell me that it has problematic stuff in it. Please first upload a cleaned up patch.

[pitrou]

By the way, without looking too much at the patch, I think it would be cleaner to let the certificate functions accept file-like objects, rather than adding keydata/certdata arguments.

[kristjanvalur]

The please don't. I'm actually growing tired of the way you seem to always latch onto every submission I make almost with hostility. I will find someone else to look this over.

[pitrou]

The please don't. I'm actually growing tired of the way you seem to
always latch onto every submission I make almost with hostility. I
will find someone else to look this over.

I fully realize my reply was blunt. But perhaps you could try to
understand that people care about the quality of the codebase and it is
why they care about reviewing patches before letting them in. Asking for
reviews of patches that you *know* contain unneeded cruft is rude.
Disregarding their comments and saying "I'll ask someone else because I
don't want to deal with you anymore" is even worse.

This certainly happens often to you, because (IME) you are often pushy
with your patches. So, yes, you must expect a certain amount of
defensive replies when being so. Just be prepared to deal with them.

[jcea]

Kristján, are you pursuing this yet?. Can we move on?

[kristjanvalur]

I wasn't pushing it anymore because there seemed to be no interest and Antoine attitude made me lose interest in contributing this. No one liked to comment on my approach except Antoine and I had grown tired of his persistent negativity and aloof manners. I might as well say that here that it is this kind of feedback that has turned me away from contributing to the project on several occations. At CCP we have a heavily patched version of python that we have modified throug time to deal with real world projects. I (and my company) genuinely like to contribute some of those improvements back to the trunk and regularly make efforts to do so (e.g. by taking the time and effort to port to python 3) but often they are met with with almost hostile negativity. I hope, for the sake of Python, that I am the only contributor meeting this kind of attitude.

Antoine, please take the time to read what I posted here again. I had a working patch, used in production. I uploaded, it, but when I got back home realized that an unrelated change was part of it. Unable to change it from there I asked politely that you disregard that "unrelated" change while looking at the _substance_ of patch. As you know, I am a committer and will polish things before checking them in, as anyone does.
How is that rude?

The patch still stands. I on a poor internet in a Chinese hotel and will attempt to download and edit the patch so that the irrelevant change to the PC build solution should no longer need to hinder anyone from reading it.