Requests not working in a Docker container #3948

javixeneize · 2017-03-31T11:38:41Z

Hi

Thats the old story about SSL not working with requests, but one step further.... Docker containers

I have an application that uses requests, and it works fine in my local machine, but, when deploying it in a Docker container, i am having an error with requests module (SSL error)

[2017-03-31 11:32:29,863] ERROR in app: Exception on /send [POST]
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1982, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1612, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1598, in dispatch_request
return self.view_functionsrule.endpoint
File "app.py", line 62, in sendrequest
response=sess.post(url,params, headers=h,verify=False)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 535, in post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 497, in send
raise SSLError(e, request=request)
SSLError: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",)

I have heard it might be related to openSSL. Any idea on how this can be resolved? Should i include any dependency?

sigmavirus24 · 2017-03-31T11:40:28Z

Can you run openssl version in your container?

Lukasa · 2017-03-31T11:59:36Z

This can also very definitely be related to the Python version, we'd like to know that as well.

javixeneize · 2017-03-31T13:35:54Z

Hi

Python 2.7 (12)
Openssl 1.0.2g

Thanks

Lukasa · 2017-03-31T13:36:41Z

Are you running the same version of Requests in the container and outside? What are the two versions?

javixeneize · 2017-03-31T14:31:10Z

2.11.1 when working, and 2..12.5 inside the container. Does it make any difference?

Lukasa · 2017-03-31T14:41:16Z

Yeah, there are some decent code changes between those two versions. Want to try downgrading to 2.11 quickly in the container to see what happens?

javixeneize · 2017-03-31T14:56:04Z

Still failing, but with a different error message
...
...
File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 491, in send
raise SSLError(e, request=request)
SSLError: EOF occurred in violation of protocol (_ssl.c:590)

Lukasa · 2017-03-31T14:56:50Z

Hrm. That different error is pretty much the same error. Can you reveal to us what web server you're trying to contact?

javixeneize · 2017-03-31T15:05:39Z

Thats my own server, which has a self signed certificate. I am sending verify=False to ignore SSL but doesnt seem to like it

response=sess.post(url,params, headers=h,verify=False)

Lukasa · 2017-03-31T15:07:20Z

Can you show the TLS configuration for your server, and what OpenSSL version it is linked against?

javixeneize · 2017-03-31T15:12:59Z

Its TLS 1.2 and same openSSL version... nothing special. I dont think there is anything wrong on server side as it works fine outside the docker container

…

On Fri, Mar 31, 2017 at 4:07 PM, Cory Benfield ***@***.***> wrote: Can you show the TLS configuration for your server, and what OpenSSL version it is linked against? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290738188>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55o2K5PaiflW3wHWD_rZYm_WFXXGyks5rrRa6gaJpZM4Mvjzc> .

Lukasa · 2017-03-31T15:15:32Z

So, "wrong" here is defined only in whether there is a mismatch between what the client and server expect. Out of interest, does your server expect SNI? Are you reaching your server via hostname or IP?

sigmavirus24 · 2017-03-31T15:15:57Z

In that container, can you curl your server with the same URL? Or even just telnet to it? I wonder if requests can even reach the server from where you've deployed the container.

javixeneize · 2017-03-31T15:17:52Z

Hi In response to both. it expects SNI and i reach it via hostname From the container i can telnet to the server, there is no problem with that. I have exposed another service via http and it works fine, its purely the SSL handshake what is failing

…

On Fri, Mar 31, 2017 at 4:16 PM, Ian Cordasco ***@***.***> wrote: In that container, can you curl your server with the same URL? Or even just telnet to it? I wonder if requests can even reach the server from where you've deployed the container. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290740743>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55kVKzprqGA1n1PKJznWX_g_V7nsxks5rrRi-gaJpZM4Mvjzc> .

Lukasa · 2017-03-31T15:19:02Z

Ok, what's the result of running openssl s_client -connect host:port to your server from inside the container?

javixeneize · 2017-03-31T15:33:23Z

Hi It connects without any issue (connected(00003))

…

On Fri, Mar 31, 2017 at 4:19 PM, Cory Benfield ***@***.***> wrote: Ok, what's the result of running openssl s_client -connect host:port to your server from inside the container? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290741631>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55oeDzw5HhrujLbMFLA6CCowT0umwks5rrRmLgaJpZM4Mvjzc> .

Lukasa · 2017-03-31T15:34:06Z

Sorry, the whole result. I'm interested in what the result of the negotiation is.

javixeneize · 2017-03-31T15:39:01Z

Verify return code: 19 (self signed certificate in certificate chain)

…

On Fri, Mar 31, 2017 at 4:34 PM, Cory Benfield ***@***.***> wrote: Sorry, the *whole* result. I'm interested in what the result of the negotiation is. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290746053>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55o4JyAkpP5h1ZPLBOkRONN2z9Em8ks5rrRz-gaJpZM4Mvjzc> .

sigmavirus24 · 2017-03-31T15:40:25Z

That is not the whole result. Please copy and paste everything from that command.

Lukasa · 2017-03-31T15:40:26Z

No, the whole result. All the output. Everything it prints.

javixeneize · 2017-03-31T15:45:02Z

There is nothing else interesting there, just tls version, cert info etc... Im having exactly the same response outside the container El El vie, 31 mar 2017 a las 16:40, Cory Benfield <notifications@github.com> escribió:

…

No, the *whole* result. All the output. Everything it prints. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290747930>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55iD8dY2eDxdfz1j0YzpteN8ThFJ3ks5rrR58gaJpZM4Mvjzc> .

Lukasa · 2017-03-31T15:46:09Z

That information is exactly what I am interested in. Something in our TLS Client Hello is making your server mad, and so I'm interested in seeing what your server is negotiating.

javixeneize · 2017-03-31T15:59:43Z

Ok, lets do something to be sure its not my certificate. I will search any other page that uses a self signed certificate ( if you know of any please share) and i will try against that, so you will be able to connect that server too El El vie, 31 mar 2017 a las 16:46, Cory Benfield <notifications@github.com> escribió: That information is exactly what I am interested in. Something in our TLS Client Hello is making your server mad, and so I'm interested in seeing what your server is negotiating. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290749603>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55oT_6jlrkIO4VlXRsoohjEGzNy3pks5rrR_TgaJpZM4Mvjzc> .

Lukasa · 2017-03-31T16:02:17Z

It's not your certificate. The error message in question (Unexpected EOF) means that during the TLS handshake the server has sent us a TCP FIN or RST packet. That means the server has chosen to close the connection, not us. That means the server has decided we are not doing something it likes. As a result, this cannot be the fault of your certificate: we haven't gotten to the point of validating it yet.

sigmavirus24 · 2017-03-31T16:19:26Z

@javixeneize without the information we've asked you for, I'm not sure what else we can do to help.

javixeneize · 2017-03-31T16:20:27Z

Ok ok... i will provide that on monday El El vie, 31 mar 2017 a las 17:19, Ian Cordasco <notifications@github.com> escribió:

…

@javixeneize <https://github.com/javixeneize> without the information we've asked you for, I'm not sure what else we can do to help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/kennethreitz/requests/issues/3948#issuecomment-290759070>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55ugTXZp-cZpp9JJJ7WmACcYXho2Rks5rrSeegaJpZM4Mvjzc> .

harry1064 · 2017-05-31T06:44:28Z

root@4f66ccbaef3c:/# openssl s_client -connect api.quinto.ai:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = fbbot.quintoapp.com
verify return:1
---
Certificate chain
 0 s:/CN=fbbot.quintoapp.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCjCCA/KgAwIBAgISA1Bg18LrjA3qyyrEDmzE+5YSMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzAzMTQwNzMyMDBaFw0x
NzA2MTIwNzMyMDBaMB4xHDAaBgNVBAMTE2ZiYm90LnF1aW50b2FwcC5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0xbEa4W4k4BlPrIxeVX+ekPl1
Od4OuwepY5Ha2BQd6YMiphh+we5H6JVu2XDuPbQnmQMtEwGa2T2Adhic4bGPPC7+
0j+utJuqGBRIbYJ09A5EQOhB4HhOSI82l1ZpPkHpvOiC4UoEgG4KOLnqBX0JydI3
8vhiV4EgbLr77wARsEeinK+Zj+7bpsEK8q+B7mR5km6f6tKT/i++Wd4Fx3Pz7iuK
aCulKzG4IMxopE/9DDf608H/3cFcSHvg/4IguPoOCx2ArNKE7QCNFGYAx9HhnV2y
AYVbd2WGWeJKuNWEwCF+nvxGDo4cHdT6kq9HHB6kPTYrZb7PrKtkq1C3MNB/AgMB
AAGjggIUMIICEDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFENiqFyUkXGaxd/woyxi
6SqQz2WqMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMHAGCCsGAQUF
BwEBBGQwYjAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNy
eXB0Lm9yZy8wLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5j
cnlwdC5vcmcvMB4GA1UdEQQXMBWCE2ZiYm90LnF1aW50b2FwcC5jb20wgf4GA1Ud
IASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsGAQUFBwIB
FhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIwgZ4MgZtU
aGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IFJlbHlp
bmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIENlcnRp
ZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0Lm9yZy9y
ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAf80at95dsb9WsSMaChtKNEJR
FfuPd/5MZaqFxWM6+AtEGZt2qbeOExIShEHFehUSWQnrCBTiPY6ildK1E5nhduap
4K0O7FrnMVaNBhnoBT7jsZMs7ivLpaKCT6imR71hQTUv07xw1kQJMu/jrHHtVjNi
9iI+VryZeETIVBtCXbirwKxT0JYLicdS/9M9m9wC7/H8xWVkcRR5dMI2Im+4klX4
eGmgi+XCJPkDZZEpfQHmIqQQ9ccCpP0BFs0JqfwLich71NdPihVnJDhVZrEVMcgs
+412WdWCOTIXrEzsL6xddypVETY2k5Z3S8sZTInWA9nYOGHW82xwh6/tRU+yiQ==
-----END CERTIFICATE-----
subject=/CN=fbbot.quintoapp.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3157 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 78B1ABFE5A7BF1E698FB5D43D1A75D6F874DD9D2E12816E3276B349FC0C4B96B
    Session-ID-ctx:
    Master-Key: B6EE0F224CB1A93379B86524E9F01D618A018E2F1D68F5AB29F7570611F0D9CF4210F9946335A9FAAEEA143B0BC98D26
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 00 39 b1 81 4d f9 90 0a-b2 dd a8 e7 b5 6b 74 7c   .9..M........kt|
    0010 - ba 4e 8b 51 75 df c4 ae-e1 6c dc 3e 05 a1 0e fc   .N.Qu....l.>....
    0020 - 4e 61 83 34 f4 ea 06 b7-8d 54 82 01 a8 b2 fa 2a   Na.4.....T.....*
    0030 - 48 69 01 b5 06 6b ee 18-3d 93 f5 d7 31 d8 66 8f   Hi...k..=...1.f.
    0040 - a4 6f f4 6c 2d 48 37 9f-33 b7 36 49 39 1f 2f 31   .o.l-H7.3.6I9./1
    0050 - 1a 0d 8f 8e 34 36 3d d1-09 fb 6b 5b 5d 68 80 3e   ....46=...k[]h.>
    0060 - 66 d9 44 11 4d 12 d5 cc-df eb c3 45 ae 04 10 56   f.D.M......E...V
    0070 - 34 ad 98 8f f9 1b f2 33-00 a4 b3 3c a5 40 80 8e   4......3...<.@..
    0080 - 9b f1 b5 40 e5 2b 29 86-7e 2b f6 95 03 4b e3 b4   ...@.+).~+...K..
    0090 - ab 16 25 bc 47 bf fb 87-dc 13 0e 10 a8 1b 18 fb   ..%.G...........
    00a0 - 3b 65 07 96 05 ce 1a c2-9a d4 d8 73 fd 38 40 8b   ;e.........s.8@.
    00b0 - 0e 52 df 26 19 fc 9f 04-06 28 b3 25 5c e2 64 51   .R.&.....(.%\.dQ

    Start Time: 1496212705
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

Lukasa · 2017-05-31T08:32:02Z

What's your actual problem @harry1064?

harry1064 · 2017-05-31T08:45:50Z

@Lukasa if you see the above result of openssl s_client -connect api.quinto.ai:443 command i ran inside docker container running on my server, You will see CN to be fbbot.quintoapp.com which is pointing to host server where my docker container is running.
But the same command i ran on host server, CN was api.quinto.ai.
So basically, i have a python server running on docker container and i want to make request to another server api.quinto.ai but I am not not able to do that using requests. Same python code i ran on interpreter on host machine, that is working fine but when i log in to docker container and ran same code from inside the python interpreter, its not working

Lukasa · 2017-05-31T08:48:25Z

By default OpenSSL s_client does not present the server name indication field, which means that the remote server will present whatever certificate it chooses. Do you get the same output in both cases if you change your command to:

openssl s_client -connect api.quinto.ai:443 -servername api.quinto.ai

Even if you don't, this sounds like a problem with docker, not with Requests: you appear to be reproducing a problem using the openssl command line, which doesn't use Requests in any way. So I'm not sure how you want us to solve your problem.

harry1064 · 2017-05-31T08:51:31Z

I got same response with both the cases. So i also think this is the problem with docker as they are maybe using mapping between iptables.

michi88 · 2017-07-20T19:57:06Z

Maybe this can help someone. For me I needed to install this:

OpenSSL 1.0.2g 1 Mar 2016

requests[security]==2.7.0  # not 2.18.x
cryptography==1.9   # not 2.0

sigmavirus24 · 2017-07-29T23:35:59Z

This discussion went stale months ago. I'm closing this. We can reopen it if necessary.

gabrielfgularte · 2018-01-11T14:08:56Z

@harry1064 @javixeneize do you guys have found a solution for this? I'm with the same problem and maybe this can be a Docker problem. But I really don't know how to overcome this...

Thanks!

javixeneize · 2018-01-11T17:14:22Z

Nope... El El jue, 11 ene 2018 a las 14:11, Gabriel Gularte < notifications@github.com> escribió:

…

@harry1064 <https://github.com/harry1064> @javixeneize <https://github.com/javixeneize> do you guys have found a solution for this? I'm with the same problem and maybe this can be a Docker problem. But I really don't know how to overcome this... Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3948 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMK55roWfMLccuizdHkWQTTOq2gU3BXMks5tJhYegaJpZM4Mvjzc> .

michi88 · 2018-01-12T07:19:26Z

try installing these versions:

requests[security]==2.7.0
cryptography==1.9
pyOpenSSL==17.4.0

Fizmath · 2019-05-13T07:42:26Z

Hello ,
I had similar problem , after degrading to the above mentioned versions everything went smoothly ( python 3.6 )

yankee14 · 2021-08-02T02:43:11Z

I am having a similar issue with requests in python 3.9.2. My script works correctly outside of docker, but does not run correctly in a container. I tried to rule out networking as the issue with docker run --network host. I tried installing the module versions listed here #3948 (comment) but pip throws a bunch of errors and can't install them.

# pip list
Package            Version
------------------ ---------
APScheduler        3.7.0
certifi            2021.5.30
cffi               1.14.6
charset-normalizer 2.0.4
cryptography       3.4.7
idna               3.2
lxml               4.6.3
numpy              1.21.1
pandas             1.3.1
pip                21.2.2
pycparser          2.20
pyOpenSSL          20.0.1
python-dateutil    2.8.2
pytz               2021.1
requests           2.26.0
setuptools         54.2.0
six                1.16.0
timeago            1.0.15
tzlocal            2.1
urllib3            1.26.6
wheel              0.36.2

sharpvik · 2021-08-05T16:48:34Z

Same as above here... This is frustrating. Me and my senior poked around with the packets, monitored some traffic but nothing helps, even downgrade to requests[security]=2.7.0. Have you got any idea what this is? Because it is really stalling my project rn.

yankee14 · 2021-08-05T17:04:34Z

@javixeneize @sigmavirus24 can we reopen this?

sigmavirus24 · 2021-08-05T17:33:47Z

The comments above explain exactly what the problem is. There is no way to write code or release to fix your problem and we're not currently capable of hand-holding everyone's custom problem for free.

As has been explained above there's something that should be doscoverably different between your environments that's causing requests to upset your server during the TLS handshake. That's only discoverable by you. Re-opening this isn't appropriate as a result

sharpvik · 2021-08-05T18:11:38Z

As has been explained above there's something that should be doscoverably different between your environments that's causing requests to upset your server during the TLS handshake.

In my case, I don't think that my server is upset with the handshake. I can't reach even google.com from container with a basic requests.get('https://www.google.com').

sigmavirus24 closed this as completed Jul 29, 2017

Fizmath mentioned this issue May 13, 2019

Request.post to a high latency external URL causes interruption in SocketIO , Running inside Docker. miguelgrinberg/Flask-SocketIO#961

Closed

github-actions bot locked as resolved and limited conversation to collaborators Nov 3, 2021

Requests not working in a Docker container #3948

Requests not working in a Docker container #3948

Comments

javixeneize commented Mar 31, 2017

sigmavirus24 commented Mar 31, 2017

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

Lukasa commented Mar 31, 2017

sigmavirus24 commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

sigmavirus24 commented Mar 31, 2017

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

Lukasa commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

Lukasa commented Mar 31, 2017

sigmavirus24 commented Mar 31, 2017

javixeneize commented Mar 31, 2017 via email

harry1064 commented May 31, 2017 • edited by Lukasa

Lukasa commented May 31, 2017

harry1064 commented May 31, 2017

Lukasa commented May 31, 2017

harry1064 commented May 31, 2017

michi88 commented Jul 20, 2017

sigmavirus24 commented Jul 29, 2017

gabrielfgularte commented Jan 11, 2018

javixeneize commented Jan 11, 2018 via email

michi88 commented Jan 12, 2018

Fizmath commented May 13, 2019

yankee14 commented Aug 2, 2021

sharpvik commented Aug 5, 2021 • edited

yankee14 commented Aug 5, 2021

sigmavirus24 commented Aug 5, 2021

sharpvik commented Aug 5, 2021

harry1064 commented May 31, 2017 •

edited by Lukasa

sharpvik commented Aug 5, 2021 •

edited