<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 25, 2017 at 8:10 PM, Greg Hellings <span dir="ltr"><<a href="mailto:greg.hellings@gmail.com" target="_blank">greg.hellings@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Jaak,<br><br></div>Can you provide a version of that patch for 1.7 (and 1.8, if there is a difference)? Or point me to where it lives? I will definitely wrap that into the packaging for Fedora and SuSE as it is absolutely inappropriate to have SSL checking skipped at the library level without it being a very explicit step for users.<br><br></div><div>If Troy won't fix this glaring security hole, it can at least be fixed by the packagers. I would encourage any Debian and/or Ubuntu users to file bugs against Sword packaging in their environments (if their maintainer isn't here) and the same for any other distribution users.<span class="HOEnZb"><font color="#888888"><br></font></span></div></div></blockquote><div><br></div><div>With apologies to Troy, this paragraph carried an implication that I did not intend. The state of this code in the library is intentionally set. However, these known and documented security weaknesses are intended to be closed up by package maintainers of libraries in most distributions (e.g. SSL/TLS libraries that include weak ciphers that get disabled by package maintainers, bundlers, etc). This is one reason that packagers are encouraged to be and remain close to the development of upstream, as much as possible, so they can provide reasonably secure defaults in the package build even if those are not the default setting for upstream for whatever reason.<br><br></div><div>I did not mean to impugn Troy or cause him offense.<br><br></div><div>That said, perhaps a compile-time switch could be added to enable more security conscious options in the transport code? That way the task of packagers could be made easier by enabling a more security-conscious option at build time instead of patching the library.<br><br></div><div>--Greg<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class="HOEnZb"><font color="#888888"></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>--Greg<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 25, 2017 at 6:56 PM, Jaak Ristioja <span dir="ltr"><<a href="mailto:jaak@ristioja.ee" target="_blank">jaak@ristioja.ee</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regarding TLS, I think the choice of whether to trust a self-signed<br>
certificate should explicitly be left to the user at run-time (e.g like<br>
browsers do), rather than blindly accepting any (even expired?)<br>
certificates.<br>
<br>
Regarding the other fix, frontends can (and already do) handle threading<br>
by themselves, but afaik even for a single-threaded process the<br>
callbacks accepted by Sword have no direct means to terminate the<br>
installation process (e.g. by return value, or via a another callback<br>
provided to the callback). So it seems that you're either saying that<br>
<br>
1) Sword users have no means to terminate potentially long-running<br>
processes (and there's no plan to add such means), or<br>
2) RemoteTransport::terminate() should never be called separately, but<br>
exclusively only from inside callbacks invoked by Sword.<br>
<br>
In the latter case, this should be made clear in the documentation.<br>
<br>
Blessings,<br>
J<br>
<div><div class="m_8493965395779729993h5"><br>
On <a href="tel:25.06.2017%2021" value="+12506201721" target="_blank">25.06.2017 21</a>:53, Troy A. Griffitts wrote:<br>
> We have included some of your patches in the past (thank you again), but<br>
> not these. The first is intentional. We want to work with self signed<br>
> certs if necessary. Non of our content is private, only the fact that a<br>
> user might access our server and for this, we ask all our frontends to<br>
> warn against this for persecuted countries. The second goes against our<br>
> policy in the library that all threading should be handled by the<br>
> client, not the library. The client should instantiate an InstallMgr in<br>
> its own thread and register threads are callbacks, if they wish to<br>
> install in the background. If we start trying to handle threading in the<br>
> library itself, it is a huge switch from current policy and depends on<br>
> support for threading in all our compilers. Easy enough to just<br>
> instantiate separate SWMgr instances per thread. But thank you for offering.<br>
> Troy<br>
><br>
> On June 25, 2017 8:33:53 PM GMT+02:00, Jaak Ristioja <<a href="mailto:jaak@ristioja.ee" target="_blank">jaak@ristioja.ee</a>><br>
> wrote:<br>
><br>
> Hi Troy!<br>
><br>
> It seems that no fixes from Sword++ were considered for inclusion in SVN<br>
> trunk, not even the two I explicitly proposed on this list in response<br>
> to the RC2 announcement: one fixing hangs in front ends and the other<br>
> fixing a pure security negligence which rendered SSL/TLS susceptible to<br>
> MitM attacks.<br>
><br>
> ?!?!<br>
><br>
> J<br>
><br>
> On <a href="tel:25.06.2017%2018" value="+12506201718" target="_blank">25.06.2017 18</a>:51, Troy A. Griffitts wrote:<br>
><br>
> Again, thank you to all the testers and reporters of problems<br>
> for the<br>
> previous RC and those who contributed fixes. Hopefully, this<br>
> will stand<br>
> any scrutiny and become 1.8.0. Please let me know if you have<br>
> any feedback.<br>
><br>
> <a href="http://crosswire.org/sword/alpha/alpha/sword-1.7.903.tar.gz" rel="noreferrer" target="_blank">http://crosswire.org/sword/al<wbr>pha/alpha/sword-1.7.903.tar.gz</a><br>
><br>
><br>
> Included since last RC:<br>
><br>
</div></div>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> r3482 | scribe | 2017-06-25 07:36:23 -0700 (Sun, 25 Jun 2017) |<br>
> 2 lines<br>
><br>
> Reworked strongs and lemma filters to better support any combo<br>
> of toggle<br>
> Added osisxhtml lemma type= support for other than Greek, Hebrew<br>
> strongs<br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> r3481 | scribe | 2017-06-25 04:45:04 -0700 (Sun, 25 Jun 2017) |<br>
> 3 lines<br>
><br>
> moved examples/simple.cpp to examples/tasks/simpleverselook<wbr>up.cpp<br>
><br>
> also updated CMakeList.txt to build new examples<br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> r3480 | scribe | 2017-06-25 04:44:29 -0700 (Sun, 25 Jun 2017) |<br>
> 1 line<br>
><br>
> added listbiblebooknames example<br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> r3479 | scribe | 2017-06-25 04:44:01 -0700 (Sun, 25 Jun 2017) |<br>
> 1 line<br>
><br>
> added flatapi installmgr example<br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> r3478 | refdoc | 2017-06-10 15:28:11 -0700 (Sat, 10 Jun 2017) |<br>
> 2 lines<br>
><br>
> added Belarussian locale file<br>
><br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> r3477 | domcox | 2017-06-04 11:18:34 -0700 (Sun, 04 Jun 2017) |<br>
> 1 line<br>
><br>
> French translation update (Contrib. from Cyrille)<br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
><br>
><br>
><br>
> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mail<wbr>man/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
><br>
</span>> -----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mail<wbr>man/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
><br>
> --<br>
> Sent from my Android device with K-9 Mail. Please excuse my brevity.<br>
><br>
><br>
</span>> ______________________________<wbr>_________________<br>
<span>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailm<wbr>an/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
><br>
<br>
<br>
</span>______________________________<wbr>_________________<br>
<div class="m_8493965395779729993HOEnZb"><div class="m_8493965395779729993h5">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailm<wbr>an/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>