<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Prior to LetsEncrypt, there was no real free opportunity for certs except self-signed. Other free certs ended the chain (root CA) in something that clients would not recognize without configuration.Practically it appears the same as a self-signed cert. It is unreasonable to have end-users configure for new root CA. (It is easy enough for an end user to do.) <div class=""><br class=""></div><div class="">Ultimately a root CA is a self-signed certificate. The difference is that the public key is installed into the root CA store on the user’s computer or into the user’s “browser’s” store. Then certs signed by that CA are not self-signed. This is essentially what many companies do for internal communication. The DoD likewise.</div><div class=""><br class=""></div><div class="">At CrossWire, we are using LetsEncrypt to provide signed certs. I presume that if a front-end uses the patch in SWORD, that it will work, properly verifying the cert.<br class=""><div class=""><br class=""></div><div class="">IMHO:</div><div class="">The front-end&/end-user should have the choice to use SSL or not. If SSL, the front-end&/end-user should be notified whether the cert:</div><div class="">a) doesn’t match the endpoint.</div><div class="">b) is expired.</div><div class="">c) is self-signed</div><div class="">d) is signed by an unknown CA</div><div class=""><br class=""></div><div class="">I don’t think it should be a hard fail in the SWORD engine.</div><div class=""><br class=""></div><div class="">Regarding a), I’ve noticed that proxies often do MiTM, substituting their own valid certs but not for the endpoint. In the past, this was not checked by clients. Some clients, e.g. FireFox, now do. (Example, in many airports <a href="https://google.com" class="">https://google.com</a> in FireFox won’t work.)</div><div class=""><br class=""></div><div class="">In Him,</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>DM</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 26, 2017, at 5:38 AM, Troy A. Griffitts <<a href="mailto:scribe@crosswire.org" class="">scribe@crosswire.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">So, the background and original thinking with this: It was originally<br class="">turned on because it wasn't too long ago that CrossWire used self-signed<br class="">certificates.<br class=""><br class="">My thinking was, primary security concern are twofold: 1) It's not like<br class="">a browser where a user is sending data; we're not enabling user data<br class="">transmission, but instead just Bible downloads. 2) persecuted countries;<br class="">the destination isn't masked by using https, only which Bible. If<br class="">someone is monitoring the download from our site, an authenticated host<br class="">connection won't hide that, and if they are monitoring the content, then<br class="">it is only the Scriptures.<br class=""><br class="">I'm certainly willing to add a compile flag to enable/disable<br class="">self-signed certs. I'm also willing to make this a runtime option for<br class="">the client of the library.<br class=""><br class="">Troy<br class=""><br class=""><br class="">On 06/26/2017 11:26 AM, Jaak Ristioja wrote:<br class=""><blockquote type="cite" class="">I think we need to make a distinction between developers and end users<br class="">here. IMHO it were best if the end user were presented with a choice<br class="">about whether to trust the self-signed, unverified or invalid<br class="">certificates, and perhaps also provide means to trust the presented<br class="">certificate permanently.<br class=""><br class="">PS: I haven't tested it, but adding the self-signed certificates to the<br class="">root CA store might be a valid workaround for development purposes.<br class=""><br class="">On 26.06.2017 12:15, Peter Von Kaehne wrote:<br class=""><blockquote type="cite" class="">Fair point, but a change from one to the other may be preferable for philosophical reasons, but practically I - and others - need to be able as users to make a determination what we want to accept and what not, instead of being forced into one direction. And, as tool writer and user (not frontend writer) I need to be able to override such things mechanically, i.e. without further user interaction. <br class=""><br class=""><blockquote type="cite" class="">Gesendet: Montag, 26. Juni 2017 um 10:04 Uhr<br class="">Von: "Jaak Ristioja" <<a href="mailto:jaak@ristioja.ee" class="">jaak@ristioja.ee</a>><br class="">An: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class="">Betreff: Re: [sword-devel] SWORD 1.8.0RC3<br class=""><br class="">Overriding this setting was never possible with Sword in the first place.<br class=""><br class="">On 26.06.2017 11:05, <a href="mailto:refdoc@gmx.net" class="">refdoc@gmx.net</a> wrote:<br class=""><blockquote type="cite" class="">As a user I would want to be able to override this, does this patch make<br class="">this impossible?<br class=""><br class="">Sent from my mobile. Please forgive shortness, typos and weird autocorrects.<br class=""><br class=""><br class="">-------- Original Message --------<br class="">Subject: Re: [sword-devel] SWORD 1.8.0RC3<br class="">From: Jaak Ristioja<br class="">To: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class="">CC:<br class=""><br class=""><br class=""> Sure! Verifying TLS certificates is explicitly disabled the file<br class=""><br class=""> src/mgr/curlhttpt.cpp<br class=""><br class=""> by the lines:<br class=""><br class=""> /* Disable checking host certificate */<br class=""> curl_easy_setopt(session, CURLOPT_SSL_VERIFYPEER, false);<br class=""><br class=""> I've attached a patch for Sword SVN trunk which removed these lines. For<br class=""> the Sword++ commit, see<br class=""> <a href="https://github.com/swordxx/swordxx/commit/49de93ca35f61601376fab0ac8689f48a76dd4d6" class="">https://github.com/swordxx/swordxx/commit/49de93ca35f61601376fab0ac8689f48a76dd4d6</a><br class=""><br class=""> J<br class=""><br class=""><br class=""> On 26.06.2017 04:10, Greg Hellings wrote:<br class=""><blockquote type="cite" class="">Jaak,<br class=""><br class="">Can you provide a version of that patch for 1.7 (and 1.8, if there<br class=""></blockquote> is a<br class=""><blockquote type="cite" class="">difference)? Or point me to where it lives? I will definitely wrap<br class=""></blockquote> that<br class=""><blockquote type="cite" class="">into the packaging for Fedora and SuSE as it is absolutely<br class=""></blockquote> inappropriate<br class=""><blockquote type="cite" class="">to have SSL checking skipped at the library level without it being a<br class="">very explicit step for users.<br class=""><br class="">If Troy won't fix this glaring security hole, it can at least be fixed<br class="">by the packagers. I would encourage any Debian and/or Ubuntu users to<br class="">file bugs against Sword packaging in their environments (if their<br class="">maintainer isn't here) and the same for any other distribution users.<br class=""><br class="">--Greg<br class=""><br class="">On Sun, Jun 25, 2017 at 6:56 PM, Jaak Ristioja > > wrote:<br class=""><br class="">Regarding TLS, I think the choice of whether to trust a self-signed<br class="">certificate should explicitly be left to the user at run-time (e.g<br class=""></blockquote> like<br class=""><blockquote type="cite" class="">browsers do), rather than blindly accepting any (even expired?)<br class="">certificates.<br class=""><br class="">Regarding the other fix, frontends can (and already do) handle<br class=""></blockquote> threading<br class=""><blockquote type="cite" class="">by themselves, but afaik even for a single-threaded process the<br class="">callbacks accepted by Sword have no direct means to terminate the<br class="">installation process (e.g. by return value, or via a another callback<br class="">provided to the callback). So it seems that you're either saying that<br class=""><br class="">1) Sword users have no means to terminate potentially long-running<br class="">processes (and there's no plan to add such means), or<br class="">2) RemoteTransport::terminate() should never be called separately, but<br class="">exclusively only from inside callbacks invoked by Sword.<br class=""><br class="">In the latter case, this should be made clear in the documentation.<br class=""><br class="">Blessings,<br class="">J<br class=""><br class="">On 25.06.2017 21 :53, Troy A. Griffitts wrote:<br class=""><blockquote type="cite" class="">We have included some of your patches in the past (thank you<br class=""></blockquote>again), but<br class=""><blockquote type="cite" class="">not these. The first is intentional. We want to work with self<br class=""></blockquote></blockquote> signed<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">certs if necessary. Non of our content is private, only the fact<br class=""></blockquote>that a<br class=""><blockquote type="cite" class="">user might access our server and for this, we ask all our<br class=""></blockquote></blockquote> frontends to<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">warn against this for persecuted countries. The second goes<br class=""></blockquote>against our<br class=""><blockquote type="cite" class="">policy in the library that all threading should be handled by the<br class="">client, not the library. The client should instantiate an<br class=""></blockquote>InstallMgr in<br class=""><blockquote type="cite" class="">its own thread and register threads are callbacks, if they wish to<br class="">install in the background. If we start trying to handle threading<br class=""></blockquote>in the<br class=""><blockquote type="cite" class="">library itself, it is a huge switch from current policy and<br class=""></blockquote></blockquote> depends on<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">support for threading in all our compilers. Easy enough to just<br class="">instantiate separate SWMgr instances per thread. But thank you for<br class=""></blockquote>offering.<br class=""><blockquote type="cite" class="">Troy<br class=""><br class="">On June 25, 2017 8:33:53 PM GMT+02:00, Jaak Ristioja<br class=""><br class="">wrote:<br class=""><br class="">Hi Troy!<br class=""><br class="">It seems that no fixes from Sword++ were considered for<br class=""></blockquote>inclusion in SVN<br class=""><blockquote type="cite" class="">trunk, not even the two I explicitly proposed on this list in<br class=""></blockquote>response<br class=""><blockquote type="cite" class="">to the RC2 announcement: one fixing hangs in front ends and<br class=""></blockquote>the other<br class=""><blockquote type="cite" class="">fixing a pure security negligence which rendered SSL/TLS<br class=""></blockquote>susceptible to<br class=""><blockquote type="cite" class="">MitM attacks.<br class=""><br class="">?!?!<br class=""><br class="">J<br class=""><br class="">On 25.06.2017 18 :51, Troy A. Griffitts<br class=""></blockquote>wrote:<br class=""><blockquote type="cite" class=""><br class="">Again, thank you to all the testers and reporters of problems<br class="">for the<br class="">previous RC and those who contributed fixes. Hopefully, this<br class="">will stand<br class="">any scrutiny and become 1.8.0. Please let me know if you have<br class="">any feedback.<br class=""><br class=""><br class=""></blockquote><a href="http://crosswire.org/sword/alpha/alpha/sword-1.7.903.tar.gz" class="">http://crosswire.org/sword/alpha/alpha/sword-1.7.903.tar.gz</a><br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">Included since last RC:<br class=""><br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">r3482 | scribe | 2017-06-25 07:36:23 -0700 (Sun, 25 Jun 2017) |<br class="">2 lines<br class=""><br class="">Reworked strongs and lemma filters to better support any combo<br class="">of toggle<br class="">Added osisxhtml lemma type= support for other than Greek, Hebrew<br class="">strongs<br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">r3481 | scribe | 2017-06-25 04:45:04 -0700 (Sun, 25 Jun 2017) |<br class="">3 lines<br class=""><br class="">moved examples/simple.cpp to examples/tasks/simpleverselookup.cpp<br class=""><br class="">also updated CMakeList.txt to build new examples<br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">r3480 | scribe | 2017-06-25 04:44:29 -0700 (Sun, 25 Jun 2017) |<br class="">1 line<br class=""><br class="">added listbiblebooknames example<br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">r3479 | scribe | 2017-06-25 04:44:01 -0700 (Sun, 25 Jun 2017) |<br class="">1 line<br class=""><br class="">added flatapi installmgr example<br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">r3478 | refdoc | 2017-06-10 15:28:11 -0700 (Sat, 10 Jun 2017) |<br class="">2 lines<br class=""><br class="">added Belarussian locale file<br class=""><br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">r3477 | domcox | 2017-06-04 11:18:34 -0700 (Sun, 04 Jun 2017) |<br class="">1 line<br class=""><br class="">French translation update (Contrib. from Cyrille)<br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><br class=""><br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class=""></blockquote><br class=""><blockquote type="cite" class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""><br class=""><br class=""><br class=""></blockquote><br class=""></blockquote> ------------------------------------------------------------------------<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class=""></blockquote><br class=""><blockquote type="cite" class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""><br class="">--<br class="">Sent from my Android device with K-9 Mail. Please excuse my brevity.<br class=""><br class=""><br class="">_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class=""></blockquote><br class=""><blockquote type="cite" class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class=""><br class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">sword-devel mailing list: sword-devel@crosswire.org<br class="">http://www.crosswire.org/mailman/listinfo/sword-devel<br class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""></blockquote><br class=""><br class=""> _______________________________________________<br class=""> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class=""> Instructions to unsubscribe/change your settings at above page<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""></blockquote>_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>