Nic, this is fantastic. Thanks!Sent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: [sword-devel] PocketSword updateFrom: Nic Carter To: sword-devel@crosswire.orgCC: Hi all,There is a new version of PS (1.4.8) on the App Store. Lots
Hi all,
There is a new version of PS (1.4.8) on the App Store. Lots of thanks to those
who assisted in getting this one out the door. It doesn't have all the fixes in
it I would have liked, but it fixes search, Strong's, 64bit & works with iOS 11.
Any bug reports are welcome & I'll see if I can
From time to time I play with different representations of interlinear text. I
thought I’d share the latest iteration which uses CSS3 and HTML5 Flex Box
layout:
Title: Interlinear text
An example of how to represent interlinear text
Introduction
Interlinear text lines up the
> On Jun 26, 2017, at 8:24 AM, Peter Von Kaehne wrote:
>
> Von: "DM Smith"
>> 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 tha
Von: "DM Smith"
> 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 man
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 config
So, the background and original thinking with this: It was originally
turned on because it wasn't too long ago that CrossWire used self-signed
certificates.
My thinking was, primary security concern are twofold: 1) It's not like
a browser where a user is sending data; we're not enabling user data
I think we need to make a distinction between developers and end users
here. IMHO it were best if the end user were presented with a choice
about whether to trust the self-signed, unverified or invalid
certificates, and perhaps also provide means to trust the presented
certificate permanently.
PS:
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 fronten
Overriding this setting was never possible with Sword in the first place.
On 26.06.2017 11:05, ref...@gmx.net wrote:
> As a user I would want to be able to override this, does this patch make
> this impossible?
>
> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>
>
<<< text/html; charset=utf-8: Unrecognized >>>
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Sure! Verifying TLS certificates is explicitly disabled the file
src/mgr/curlhttpt.cpp
by the lines:
/* Disable checking host certificate */
curl_easy_setopt(session, CURLOPT_SSL_VERIFYPEER, false);
I've attached a patch for Sword SVN trunk which removed these lines. For
the Sword++ commi
12 matches
Mail list logo
