Option to use windows ca store with openssl. #4346

gvollant · 2019-09-13T09:43:23Z

This patch allow using Windows certificate store for Windows curl compiled with openssl

the curl command line utility with automatically uses it when there is no --cacert , no --capath option and curl-ca-bundle.crt is not specified
(before the patch, the https connexion failed)
user can also enter

https://curl.haxx.se//mail/lib-2018-09/0038.html

https://curl.haxx.se//mail/lib-2018-09/0028.html

bagder · 2019-09-15T15:23:58Z

The travis builds using boringssl fail, due to unrelated reasons. The rest seem green!

bagder

And perhaps consider to squash all commits into a single one and force-push, to make this patch easier to review!

bagder · 2019-09-15T15:25:47Z

src/tool_operate.c

-            // so the only possible solution is using the windows ca store
-            config->cacert = strdup(CURL_WINDOWS_CA_STORE);            
+        if(!config->cacert && !config->capath) {
+            /* now, we are under MS-Windows.


Note that this is not using a 2-space indent level, which all curl code does. You should probably make sure all your code follow that style.

gvollant · 2019-09-15T15:55:26Z

I tried to made squash , but I’m not a git guru! Can you made now the work for merging as possible? Thing will probably not be easy for me if there is some github/git special stuff… De : Daniel Stenberg [mailto:notifications@github.com] Envoyé : dimanche 15 septembre 2019 17:27 À : curl/curl Cc : gvollant; Author Objet : Re: [curl/curl] Option to use windows ca store with openssl. (#4346) @bagder commented on this pull request.

gvollant · 2019-09-16T06:59:18Z

I don't understand why somes test fails...

bagder · 2019-09-16T08:23:36Z

With "squash", all your changes should be made into a single commit. Right now this change is very hard to review since it is spread out over a lot of commits where most of them change things done in previous commits...

With the git command line tool, it can be made like this:

update your master to be in sync with upstream
check out your feature branch git checkout branch
rebase your branch: git rebase -i origin/branch - the -i means interacetive. Make all commit lines except the first one say 'f' in the first column, which means fixup and that means it'll be merged into the previous commit.
Now all commits should have been turned into a single one in your branch.
You can't push this normally now, you need to use git push -f to force push

I can work around this, but if I provide feedback on this patch how are you going to update it? Just keep adding commits and make it harder and harder for others to read?

PS at least one of your commits changed line endings on the code which makes things complicated at least for me.

gvanem · 2019-09-16T09:00:49Z

I don't understand why somes test fails...

First failed is test 714. Running it here gives me no clues either, but the log/memdump shows a leak:

memanalyze.pl -v log\memdump
Leak detected: memory still allocated: 64 bytes
At af93ce8, there's 64 bytes.
 allocated by mprintf.c:1049

gvollant · 2019-09-16T12:27:20Z

I done the squash

mback2k · 2019-09-16T12:38:39Z

.travis.yml

 sudo: required
+go:
+    "1.13"


This change seems not to be related.

It's probably a merge or rebase... I don't want change myself ...

it comes probably from ac34c70

mback2k · 2019-09-16T12:40:56Z

include/curl/curl.h

+ curl compiled for MS-Windows using OpenSSL for using Windows CA Store
+    to verify peer
+  as suggested in https://curl.haxx.se/mail/lib-2018-09/0039.html */
+#define CURL_WINDOWS_CA_STORE     "\\\\\\WINDOWS_CA_STORE"


The number of backslashes seems a bit weird, especially considering escaping. Maybe think of something more clear?

there is 3*2=6. backslash
on windows a path beginning with two backslash can be a network path
three baskslash is impossible so there is no conflict
https://en.wikipedia.org/wiki/Path_(computing)#Uniform_Naming_Convention )

If you'd use three forward-slashes instead, you'd avoid a lot of escaping problems and still be pretty safe, won't you? I think the main problem is here if we expect command line users to be able to set this.

ok, I just replaced backslash by forward slash

gvollant · 2019-09-17T13:09:34Z

Is review less hard now these two PR ? <#4346> #4346 all modification are on <26866fb> 26866fb And <#4356> #4356 87f313d De : Daniel Stenberg [mailto:notifications@github.com] Envoyé : lundi 16 septembre 2019 10:24 À : curl/curl Cc : gvollant; Author Objet : Re: [curl/curl] Option to use windows ca store with openssl. (#4346) With "squash", all your changes should be made into a single commit. Right now this change is very hard to review since it is spread out over a lot of commits where most of them change things done in previous commits... With the git command line tool, it can be made like this: 1. update your master to be in sync with upstream 2. check out your feature branch git checkout branch 3. rebase your branch: git rebase -i origin/branch - the -i means interacetive. Make all commit lines except the first one say 'f' in the first column, which means fixup and that means it'll be merged into the previous commit. 4. Now all commits should have been turned into a single one in your branch. 5. You can't push this normally now, you need to use git push -f to force push I can work around this, but if I provide feedback on this patch how are you going to update it? Just keep adding commits and make it harder and harder for others to read? PS at least one of your commits changed line endings on the code which makes things complicated at least for me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4346?email_source=notifications&email_token=AAIKFN64LM52PD5SRVULNKLQJ47DFA5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6YNSLA#issuecomment-531683628> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIKFN5N4SICH7BGMIO2MCLQJ47DFANCNFSM4IWOA7RA> . <https://github.com/notifications/beacon/AAIKFN6MZSP2WVP2SB3DVLLQJ47DFA5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6YNSLA.gif>

bagder · 2019-09-17T14:24:34Z

I done the squash

You also merged two unrelated commits (from another branch), which is what broke the tests. When you've squashed and rebased, this should only be a single commit and definitely not commits that were authored by someone else than you!

I think this starts to look fine. I mostly miss the documentation of this new feature now.

To think about: Is there a way an application can know or should be able to figure out if libcurl supports this at run-time?

gvollant · 2019-09-17T17:50:13Z

I tried fix the git again…. I also made #4371 from memory for libcurl 4356 modification are included in 4371 De : Daniel Stenberg [mailto:notifications@github.com] Envoyé : mardi 17 septembre 2019 16:25 À : curl/curl Cc : gvollant; Author Objet : Re: [curl/curl] Option to use windows ca store with openssl. (#4346) I done the squash You also merged two unrelated commits (from another branch), which is what broke the tests. When you've squashed and rebased, this should only be a single commit and definitely not commits that were authored by someone else than you! I think this starts to look fine. I mostly miss the documentation of this new feature now. To think about: Is there a way an application can know or should be able to figure out if libcurl supports this at run-time? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4346?email_source=notifications&email_token=AAIKFN2JXBT6T2LZTU6OAKLQKDSEPA5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD64WRPQ#issuecomment-532244670> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIKFN6O5VT26AZ67KUENF3QKDSEPANCNFSM4IWOA7RA> . <https://github.com/notifications/beacon/AAIKFN3C262OMYZGWCZH2FLQKDSEPA5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD64WRPQ.gif>

gvollant · 2019-09-18T08:49:54Z

« Is there a way an application can know or should be able to figure out if libcurl supports this at run-time” I’m not sure understanding. You want known if we can check if current version of windows support it? I can only say I tested witn Windows 7 SP1 and Windows 10 De : Daniel Stenberg [mailto:notifications@github.com] Envoyé : mardi 17 septembre 2019 16:25 À : curl/curl Cc : gvollant; Author Objet : Re: [curl/curl] Option to use windows ca store with openssl. (#4346) I done the squash You also merged two unrelated commits (from another branch), which is what broke the tests. When you've squashed and rebased, this should only be a single commit and definitely not commits that were authored by someone else than you! I think this starts to look fine. I mostly miss the documentation of this new feature now. To think about: Is there a way an application can know or should be able to figure out if libcurl supports this at run-time? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4346?email_source=notifications&email_token=AAIKFN2JXBT6T2LZTU6OAKLQKDSEPA5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD64WRPQ#issuecomment-532244670> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIKFN6O5VT26AZ67KUENF3QKDSEPANCNFSM4IWOA7RA> . <https://github.com/notifications/beacon/AAIKFN3C262OMYZGWCZH2FLQKDSEPA5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD64WRPQ.gif>

gvollant · 2019-09-19T06:23:32Z

Sorry, I don't have idea of what need modification? Can you help me?

gvollant · 2019-09-28T06:28:05Z

I don't understand the travis problem

jay · 2019-10-06T03:38:23Z

lib/vtls/openssl.c

+        "ROOT");
+
+    if(hStore) {
+      while((pContext = CertEnumCertificatesInStore(hStore, pContext))


do any attributes of the certificate have to be checked like notbefore notafter etc or does openssl do this

bagder · 2019-11-10T22:33:43Z

Maybe also add a little mention in the docs for the option where this can be set?

michael-o · 2020-04-29T10:00:42Z

I ask myself whether it is a good idea to document CURLSSLOPT_NATIVE_CA explicitly with Windows. One can probably write a patch for obtain certs from macOS's Keychain which would be a native CA store too.

gvollant · 2020-04-29T10:37:27Z

I ask myself whether it is a good idea to document CURLSSLOPT_NATIVE_CA explicitly with Windows. One can probably write a patch for obtain certs from macOS's Keychain which would be a native CA store too.

Yes, good idea. This is probably easy

https://stackoverflow.com/questions/42432473/programmatically-read-root-ca-certificates-in-ios

https://stackoverflow.com/questions/32472337/osx-export-system-certificates-from-keychain-in-pem-format-programmatically

gvollant · 2020-05-05T20:19:37Z

I do a small text modification

bagder · 2020-05-07T08:23:12Z

Lots of CI failures still. Remember to run make checksrc locally to pick most of these ones up yourself:

./vtls/openssl.c:2889:82: warning: Longer than 79 columns (LONGLINE)
         /* Continue with a warning if no certificate verification is required. */
./vtls/openssl.c:2901:82: warning: Longer than 79 columns (LONGLINE)
         /* Continue with a warning if no certificate verification is required. */
checksrc: 0 errors and 2 warnings
checksrc: 0 errors and 5 warnings suppressed

gvollant · 2020-05-07T10:10:53Z

Thank you a lot, I did not known checksrc I fixed the source problem, but I don’t known how I can fix: https://github.com/curl/curl/actions/runs/98001972 De : Daniel Stenberg [mailto:notifications@github.com] Envoyé : jeudi 7 mai 2020 10:23 À : curl/curl Cc : Gilles Vollant; Author Objet : Re: [curl/curl] Option to use windows ca store with openssl. (#4346) Lots of CI failures still. Remember to run make checksrc locally to pick most of these ones up yourself: ./vtls/openssl.c:2889:82: warning: Longer than 79 columns (LONGLINE) /* Continue with a warning if no certificate verification is required. */ ./vtls/openssl.c:2901:82: warning: Longer than 79 columns (LONGLINE) /* Continue with a warning if no certificate verification is required. */ checksrc: 0 errors and 2 warnings checksrc: 0 errors and 5 warnings suppressed — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4346 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIKFN3TNWNQ7W5J6V22HSDRQJVX7ANCNFSM4IWOA7RA> . <https://github.com/notifications/beacon/AAIKFN3QUYTRKDPHHSD6PZDRQJVX7A5CNFSM4IWOA7RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEVBGCBY.gif>

michael-o

There is an inconsistency throughout in the documentation and log messages. Sometimes "root certificates", "ca certificates", "CA certificates", etc. Can you apply/propose consistent naming?
Nitpicking: also note that the native CA store might not only contain root certificates, but also intermediate ones.

michael-o · 2020-05-07T11:06:31Z

docs/libcurl/opts/CURLOPT_SSL_OPTIONS.3

+.IP CURLSSLOPT_NATIVE_CA
+With the build against OpenSSL library, uses the native operating system
+store of root certificates instead of any other CA certificates.
+Currenly supported with MS-Windows.


Please either write "Windows" or "Microsoft Windows" consistently.

michael-o · 2020-05-07T11:07:06Z

docs/libcurl/opts/CURLOPT_SSL_OPTIONS.3

+store of root certificates instead of any other CA certificates.
+Currenly supported with MS-Windows.
+Caution: use only CURLOPT_CAINFO with curl 7.70.1 or later for MS-Windows
+using OpenSSL library. On other configuration, curl will have no certificate.


This sentence has a weird word oder.

can you suggest me alternative text modified?
My english is not perfect, so I prefer you suggest a new version than ask me fix, then review and ask modify again

I don't understand the sentence at all. It describes CURLSSLOPT_NATIVE_CA and then it speaks of CURLOPT_CAINFO without explaining how they relate here. Can you elaborate what this is trying to say?

My edited version says this now, but I'd like to understand the comment about CURLOPT_CAINFO so that we can perhaps add that:

Tell libcurl to use the operating system's native CA store for certificate verifiction. Works when built to use OpenSSL on Windows. (Added in 7.71.0)

wa must remove CURLOPT_CAINFO reference. I wrote this test before we add CURLSSLOPT_NATIVE_CA

So now, we must only say CURLOPT_CAINFO is only for new version of curl (for windows , and pehaps on other OS later).
Before new version of curl, we need provide a file of certificate

We can possibly add that CURLSSLOPT_NATIVE_CA overrides CURLOPT_CAINFO if both are set...

michael-o · 2020-05-07T11:18:49Z

For those who'd like to play with EKUs, try our Siemens CAs:
siemens-certs.txt

bagder · 2020-05-08T13:57:29Z

Thanks a lot @gvollant for your very hard work on this and for your patience. This has now landed, scheduled to ship in the next release; 7.71.0.

gvollant · 2020-05-08T13:59:29Z

Thanks a lot @gvollant for your very hard work on this and for your patience. This has now landed, scheduled to ship in the next release; 7.71.0.

no problem, and thank you for help me. You learned me somes git command, the nice checksrc tool and help me with my poor english :-)

mhils · 2020-05-08T16:19:23Z

Sorry for chiming in late here, but I just saw @bagder's tweet and figured this should at least be mentioned: There's been an extensive discussion among Python folks regarding OpenSSL + system trust stores in psf/requests#2966. The consensus seems to be that enumerating the Windows CA store isn't really a good idea.
First, Windows doesn't ship with all of the certificates available and downloads them on-demand when certificates are validated. cURL may not trust some legitimate CAs on fresh Windows installs. Not sure if that is a practical problem, but something to keep in mind.
Second, it's a bit of a security concern. @Lukasa sums it up nicely (psf/requests#2966 (comment)):

A side note: the wrong fix is to extract the root certificates from the system and have the Python OpenSSL validate using them as roots. The system trust store has its own validation logic on macOS and Windows, and failing to use it can lead to spurious trust failures at best and incorrect trust successes at worst. You have to entirely delegate cert verification to the system APIs to do this properly, by handing the peer cert chain over.

So yeah - I know this is merged, I really don't want to take away from @gvollant's excellent work here, but there are some security concerns so I figured I should bring it up.

mback2k · 2020-05-08T17:16:06Z

You have to entirely delegate cert verification to the system APIs to do this properly, by handing the peer cert chain over.

One alternative approach could be to instead disable the verification in OpenSSL, ask it to provide the server certificate to libcurl and then validate it similar to the code in schannel_verify.c:

curl/lib/vtls/schannel_verify.c

Line 530 in 92501a1

CURLcode Curl_verify_certificate(struct connectdata *conn, int sockindex)

First, Windows doesn't ship with all of the certificates available and downloads them on-demand when certificates are validated. cURL may not trust some legitimate CAs on fresh Windows installs. Not sure if that is a practical problem, but something to keep in mind.

I think this applies to intermediate CAs as root CAs are kept up to date via Windows Update.

Update: I was wrong, root CAs are also fetched on demand: https://docs.microsoft.com/en-us/previous-versions//cc751157(v=technet.10)?redirectedfrom=MSDN

Starting with the release of Windows Vista, root certificates are updated on Windows automatically. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate. If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes.

bagder · 2020-05-08T21:04:00Z

Security wise, this option has many angles and aspects and it is not at all necessary worse than without it.

Many people and applications are already converting the windows CA store into a PEM to use with curl and other applications so for those users, this step just makes things easier and less error-prone.

The argument about which CA store to use and trust could even be used the other way around as using the Windows store could in some cases be easier and be more likely to be updated and accurate rather than the separate PEM file. And more in sync with other applications and subsystems that might also be used.

The PEM file itself is often extracted from Mozilla and used outside of their verification code which similar to the Windows verification APIs also does a lot of other things and checks apart from using just the certs, so "just" using the PEM is also already a shortcut and one with caveats.

I think it is important to clearly document what this option means and does and leave to the user to make an enlightened decision.

One alternative approach could be to instead disable the verification in OpenSSL, ask it to provide the server certificate to libcurl and then validate it similar to the code in schannel_verify.c

Yes, I think that would be an improvement!

jay · 2020-05-09T03:59:28Z

IIRC recent versions of Windows routinely poll for root certificates. If you have a specific "incorrect trust success" example let's hear it. Regarding verification I just don't see why we should mix it up any more. We have Schannel backend, and OpenSSL backend, and now both of them can use the OS root store or the certificate bundle. That seems like enough to me.

mback2k · 2020-05-09T10:04:10Z

I just don't see why we should mix it up any more.

I wasn't talking about mixing it up, just change the way the OpenSSL backend uses the root CA store. Instead of "mirroring" it into the OpenSSL store, it could just ask Windows to verify the certificate. That would solve any potential CA refreshing issues and could improve the overall startup performance.

Slightly off topic: I must say I only ever experienced the CA refresh with Outlook on Windows missing some intermediates while validating S/MIME e-mail signatures. This lead to the e-mail signature first showing up as invalid and a few seconds later showing as valid.

gvollant · 2020-05-21T17:52:52Z

somes tips for verify under mac osx:

get x509 objet (like in get_cert_chain in openssl.c ) and call i2d_X509 get get der encoded data in memory

then call

https://developer.apple.com/documentation/security/1396073-seccertificatecreatewithdata?language=objc

https://developer.apple.com/documentation/security/1392592-secpolicycreatessl?language=objc

https://developer.apple.com/documentation/security/1401555-sectrustcreatewithcertificates?language=objc

gvollant · 2020-07-06T12:28:26Z

I open #5657 because the feature like I expected was disabled by #5585

gvollant changed the title ~~Option to use windows ca store with openssl~~ Option to use windows ca store with openssl. Sep 13, 2019

bagder reviewed Sep 15, 2019

View reviewed changes

gvollant force-pushed the winopenssl/wincastore_openssl branch from 38211dc to 26866fb Compare September 16, 2019 12:07

mback2k reviewed Sep 16, 2019

View reviewed changes

gvollant force-pushed the winopenssl/wincastore_openssl branch from 26866fb to 4d11fe5 Compare September 17, 2019 17:47

gvollant force-pushed the winopenssl/wincastore_openssl branch 2 times, most recently from 138a6fa to 1058cc0 Compare September 18, 2019 08:22

gvollant force-pushed the winopenssl/wincastore_openssl branch 4 times, most recently from 03b4db2 to 0311f16 Compare September 27, 2019 06:45

gvollant force-pushed the winopenssl/wincastore_openssl branch from 0311f16 to 182f3c5 Compare October 3, 2019 20:38

jay reviewed Oct 6, 2019

View reviewed changes

gvollant force-pushed the winopenssl/wincastore_openssl branch from 182f3c5 to df1ee46 Compare October 20, 2019 15:00

gvollant force-pushed the winopenssl/wincastore_openssl branch from df1ee46 to a16cf9c Compare November 10, 2019 17:21

bagder added the TLS label Nov 10, 2019

This comment has been minimized.

Sign in to view

gvollant requested a review from jay April 8, 2020 12:37

gvollant force-pushed the winopenssl/wincastore_openssl branch from 63b05f8 to eddb82a Compare April 8, 2020 14:43

gvollant force-pushed the winopenssl/wincastore_openssl branch from eddb82a to a1692ab Compare April 29, 2020 09:50

gvollant force-pushed the winopenssl/wincastore_openssl branch from a1692ab to e3fbb17 Compare May 3, 2020 08:42

Option to use windows ca store with openssl

1f150c7

gvollant force-pushed the winopenssl/wincastore_openssl branch from 0350ac8 to 1f150c7 Compare May 7, 2020 09:28

remove unused code

831d249

michael-o suggested changes May 7, 2020

View reviewed changes

bagder closed this in 148534d May 8, 2020

jay mentioned this pull request Jun 19, 2020

curl tool fall back on Windows native CA store overrides libcurl hardcoded paths #5585

Merged

gvollant mentioned this pull request Jul 6, 2020

Restore use Windows CA store as a fallback on curl.exe #5657

Closed

Prinzhorn mentioned this pull request Dec 11, 2020

Mitmproxy not using up the installed certificates mitmproxy/mitmproxy#4335

Closed

Option to use windows ca store with openssl. #4346

Option to use windows ca store with openssl. #4346

Conversation

gvollant commented Sep 13, 2019

bagder commented Sep 15, 2019

bagder left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gvollant commented Sep 15, 2019 via email

gvollant commented Sep 16, 2019

bagder commented Sep 16, 2019

gvanem commented Sep 16, 2019

gvollant commented Sep 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gvollant commented Sep 17, 2019 via email

bagder commented Sep 17, 2019

gvollant commented Sep 17, 2019 via email

gvollant commented Sep 18, 2019 via email

gvollant commented Sep 19, 2019

gvollant commented Sep 28, 2019

Choose a reason for hiding this comment

bagder commented Nov 10, 2019

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

michael-o commented Apr 29, 2020 • edited Loading

gvollant commented Apr 29, 2020

gvollant commented May 5, 2020

bagder commented May 7, 2020

gvollant commented May 7, 2020 via email

michael-o left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bagder May 8, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michael-o commented May 7, 2020

bagder commented May 8, 2020

gvollant commented May 8, 2020

mhils commented May 8, 2020

mback2k commented May 8, 2020 • edited Loading

bagder commented May 8, 2020 • edited Loading

jay commented May 9, 2020

mback2k commented May 9, 2020 • edited Loading

gvollant commented May 21, 2020

gvollant commented Jul 6, 2020

michael-o commented Apr 29, 2020 •

edited

Loading

bagder May 8, 2020 •

edited

Loading

mback2k commented May 8, 2020 •

edited

Loading

bagder commented May 8, 2020 •

edited

Loading

mback2k commented May 9, 2020 •

edited

Loading