[bt-devel] NASB Unlock Key
Jaak Ristioja
jaak at ristioja.ee
Sun Jan 5 17:36:07 MST 2020
Dear Troy,
Thank you for taking the time and effort to reach and communicate these
observations. Although I still don't agree with you in the matters
discussed, your letter has helped me better understand your position and
why we are often at odds. Thank you!
I will also try to briefly state my positions on what you wrote in hopes
it helps. I've tried to be more sensitive, but due to this being a very
late hour, I apologize if I'm too direct as I often tend to be.
I believe that do we share the goal of sharing the Gospel of Christ but
somewhat diverge on the methods and priorities. Fixating too strongly on
this one thing only might blind us from other perhaps even more
essential goals.
Regarding efficiency and deployability, I'd rather have well-working
software on most users devices than low quality software on virtually
every device. Most users update their devices, and we no longer have to
push for every bit of performance like 25 years ago, at least not for
software like SWORD. It is also much easier to port good code.
Not every improvement requires a new dependency, even thou these might
help. Alternatives can be developed specifically for SWORD, if
reasonable. While I agree that having many dependencies is not a good
thing, having bad dependencies (e.g. outdated or unsupported) is quite
often even worse. Note also, that some dependencies might only be
compile-time dependencies (e.g. header-only libraries, build tools) and
are not required during run-time.
Of all the dependencies of BibleTime, I think the SWORD library has the
currently the worst technical quality, and this has long been a bit of
an obstacle for us.
Regarding malicious modules, I'd prefer that every user had reasonable
defences (bug-free code) in their Bible app. Crosswire can't control all
all module repositories. And even with "officially endorsed" module
repositories some crypto would have to be used both by the server and
the clients (e.g. at least HTTPS if not module signing). I believe that
Crosswire does not currently have the abilities to develop and upkeep
such secure software systems, and even with such abilities it might not
always be possible to hinder some adversaries from taking over your
servers or intercepting your communications whereby malicious content is
served to users. Either by hacking into your computers or using a wrench
(https://www.xkcd.com/538/).
Given how Christians are being persecuted in countries like China, I
would like to give software correctness (especially for security) at
least some additional priority.
Regarding std::string vs SWBuf, could you please share those comparison
tests if you still have them? Have you also heard about string_view?
Even if your approach is faster, it leads to much less comprehensible
and much more error-prone code, e.g. containing many C-style
strwhatever() functions operating on raw pointers and such.
I agree that SWORD itself is not a specification, but its public
interfaces do need specifications. The API is not the only public
interface. So are all file formats of modules and module configurations,
and the protocols for searching and downloading modules from online. I
think it is important for those interfaces to have good specifications
for openness and interoperability which would help share the Gospel, no?
Best regards,
J
On 05.01.20 22:23, Troy A. Griffitts wrote:
> Dear Jaak,
>
> A few comments which I hope explain to others here on the list why we
> always seem to be at odds with each other.
>
> Let's start with on what I hope we, as children of God, can both agree:
>
> Our goal is to share the Gospel of Christ as widely as possible.
>
> We all have limited time we must be faithful, as best we can, to the
> Lord for how we use it.
>
> We each have a ton of things on our plates and must evaluate the benefit
> toward our end goal of sharing the Gospel as widely as possible when we
> consider priorities of items on our todo list.
>
> As Peter has said, this is an opensource project and I pray the Lord
> does have different items He would have us each work on toward our end
> goal of sharing the Gospel of Christ as widely as possible.
>
> Here are some differences we have:
>
> My object for SWORD is to be as efficient and widely deployable as
> possible to meet our goal-- to share the Gospel of Christ as widely as
> possible. SWORD runs on phones and supercomputers, TVs and PDAs, all
> sorts of versions of Windows, Linux, MacOS, Android, iOS with bindings
> for all kinds of programming languages.
>
> We've made choices over the years to limit the libraries we use, the
> complexity of objects passed over out public interfaces, and even
> features of programming language we use to allow us to compile on the
> widest set of hardware and environments as possible.
>
> This doesn't seem a priority for you and makes it difficult to consider
> your proposals.
>
> For example, in your last proposal you've send in the previous email:
>
>
> https://github.com/swordxx/swordxx/commit/5959759d6951462f154dec663ea1805090a576bd
>
> My first thought was, I could imagine a million scenarios where I could
> create malicious module content to break the engine. If we go down this
> path, then we are committing to something which is better served by
> simply having officially endorsed module repositories and a disclaimer
> if users get modules from elsewhere. This, to me is a better use of our
> time to share the Gospel of Christ with the widest audience as possible.
>
> A second criticism is that you've changed our public interface from
> passing an SWBuf to the filter to using std::string. I've argued this
> point with you in the past, showing that our SWBuf object, for the
> operations we do within SWORD was many times faster that std::string on
> practically all compilers and environments we've tested. I am quite
> sure we've discussed this previously.
>
> Another point is that SWORD is not a specification which needs to be
> written up articulately such that others and reimplement. SWORD is
> rather fluid and as we have new needs we change things under the hood.
> We focus the majority of our time making sure that clients of the engine
> continue to work such that frontends had a very low level of pain
> upgrading to new version. And though not always possible, our hope is
> that we can release a new revision of the engine and never require
> frontends to change their frontend code. We've done a pretty good job
> of this, in my opinion. Our focus is not to maintain a specification
> for the "under the hood" code. That's not a bad thing if we wanted
> other people to re-implement our engine, but we don't. We highly
> discourage this. There are much much better uses of our time, in my
> opinion. In fact having a rigid specification for "under the hood"
> would drastically reduce our efficiency and have no added benefit, if we
> do not wish others to try to re-implement our engine.
>
> Each time we discuss these things, we continue to talk past each other
> and it usually ends in frustration. I simply wish, with this email, to
> remind other listeners here on the list of the base disagreements we
> have with our priorities and provide concrete examples from this current
> interaction.
>
> I sincerely wish you and your project success for sharing the Gospel of
> Christ, and truly do wish we had a common vision for how to obtain this;
> you are genuinely a talented programmer and would love to have your
> skills advance our common goal.
>
> In Him,
>
> Troy
>
>
> On 1/5/20 6:31 AM, Jaak Ristioja wrote:
>
>> Hello Peter,
>>
>> I apologize for my poor understanding. I misunderstood Troys reply to
>> mean that the wiki contains "the specification" and thought that he
>> meant the http://wiki.crosswire.org/DevTools:conf_Files page. Now that
>> you also mentioned http://wiki.crosswire.org/Tutorial:Writing_Conf_files
>> I see that this page actually contains most of the information I was
>> missing.
>>
>> Thank you!
>>
>> I also apologize if I've created a misunderstanding, e.g. by not being
>> thoughtful enough to formulate more clearly what I'm looking for as a
>> reference. You are correct that much of the information is available on
>> the two wiki pages, but I think these do not well add up to constitute a
>> single document which could comfortably be categorized as a formal
>> technical specification, because many of the details are described in an
>> informal and non-technical manner.
>>
>> But then again I might still be wrong and in need of your corrective
>> remarks.
>>
>>
>> J
>>
>>
>> On 05.01.20 13:42, refdoc at gmx.net wrote:
>>> The subset of RTF and the encoding directions are for the last decade at least
>>> in our wiki
>>>
>>> http://wiki.crosswire.org/Tutorial:Writing_Conf_files
>>>
>>> I do not mind intelligent criticism of the wiki, but declarations of absence of
>>> information by long standing collaborators should be verified by running a
>>> simple search if the information is not found on first glance
>>>
>>> Jaak, that is directed at you.
>>>
>>> FWIW, this info on this page has been lifted (by David or me) from the original
>>> static tutorial subside, so is there for about 20 years in one form or another.
>>>
>>> Peter
>>>
>>> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [bt-devel] NASB Unlock Key
>>> From: Jaak Ristioja
>>> To: bt-devel at crosswire.org
>>> CC:
>>>
>>>
>>> It helps a bit, but that is a very loose definition, and hence ambigious.
>>>
>>> For example, starting with RTF: which version of RTF? The latest version
>>> (1.9.1) of the RTF specification is 278 pages long, dated 19 March 2008.
>>> The whole of it (including support for style sheets, tables, lists,
>>> indenting, hyperlinks, line spacing, paging, margins, embedded fonts,
>>> drawing objects, pictures, UTF-16, unicode escapes, codepages, character
>>> sets, embedded OLE objects, bi-directional text, ruby, ...) or only only
>>> a subset? Which subset? Probably limited to ? Can the parser
>>> expect the representation format to be ASCII (with escapes) according to
>>> the RTF spec?
>>>
>>> Now, adding links to the mix, should this HTML construct
>>> be parsed inside all RTF constructs or just certain contexts? Or should
>>> the HTML element be parsed before RTF? Can the display text
>>> inside the tags also contain RTF?
>>>
>>> From the perspective of writing a valid parser for these configuration
>>> entries, such details matter a great deal, which is why I'm concerned.
>>>
>>> Even with plain text entries, I couldn't find information about whether
>>> these are encded in ASCII, UTF-8, ISO-8859-?? or something else. In case
>>> its UTF-8, is the byte-order mark allowed at the beginning of the
>>> configuration file?
>>>
>>> I apologize if this sounded picky, but such details really do matter
>>> from the perspective of writing correct and safe parsers. And you might
>>> not agree with me, but I find it very important that our users get
>>> high-quality software not just in terms of features, but also in terms
>>> of robustness, reliability and cybersecurity.
>>>
>>> With these things in mind and given the many bugs I've found when
>>> working on that code for Sword++, I must say I don't feel safe using
>>> Sword filters.
>>>
>>> But if I interpret your reply correctly, you suggest running the
>>> configuration value through the RTFHTML filter and use that as HTML?
>>> That at least gives me some clues about how you imagine it to work,
>>> which subset of RTF should be supported etc, but I'd prefer such
>>> information to be in the specification instead.
>>>
>>> I'd be glad to help improve these specifications, but this would entail
>>> quite a lot of scrutiny, very likely on the Sword code as well. Given
>>> that there has been some tension between us in the past, this might
>>> perhaps require a bit of forethought. :)
>>>
>>> J
>>>
>>>
>>> PS: The latest version (1.9.1) of the RTF specification is 278 pages
>>> long, dated 19 March 2008.
>>>
>>> PPS: You might want to cherry-pick this Sword++ commit into Sword to fix
>>> two HTML injection issues in RTFHTML:
>>>
>>> https://github.com/swordxx/swordxx/commit/5959759d6951462f154dec663ea1805090a576bd
>>>
>>>
>>>
>>> On 05.01.20 02:15, Troy A. Griffitts wrote:
>>> > Hi Jaak,
>>> > What makes you think the specification isn't defined? It has always been,
>>> as many of our fields in the .conf file, RTF + a href links. If the wiki
>>> doesn't say this, it should. The RTF to HTML filter in the engine will give
>>> you content you can display in your html view.
>>> >
>>> > Hope this helps,
>>> >
>>> > Troy
>>> >
>>> >
>>> >
>>> > On January 4, 2020 5:06:50 PM MST, Jaak Ristioja wrote:
>>> >> Hello Troy,
>>> >>
>>> >> I guess we can display the UnlockInfo .conf entry as verbatim plain
>>> >> text. If support for hyperlinks and such would be needed, I would
>>> >> strongly prefer the format to have a formal specification which were
>>> >> acceptable to use in BibleTime.
>>> >>
>>> >> The specification being "just some simple HTML" is not good enough,
>>> >> because passing the contents of such fields directly to some HTML or
>>> >> web
>>> >> view widget is not acceptable, neither is embedding it verbatim inside
>>> >> other HTML, because that might break our GUI layouts/HTML and comes
>>> >> with
>>> >> security concerns (we don't want modules to be able to crash BibleTime,
>>> >> run scripts, consume too much resources etc).
>>> >>
>>> >> If you want I can help write formal grammars (EBNF or similar) for such
>>> >> things, as well as parsers, linters etc.
>>> >>
>>> >>
>>> >> Best regards,
>>> >> J
>>> >>
>>> >>
>>> >> On 05.01.20 00:56, Troy A. Griffitts wrote:
>>> >>> Hi Gary,
>>> >>>
>>> >>> Thanks for the suggestion. We had to weigh the pros and cons of
>>> >> this.
>>> >>> Lockman is testing the module in a few of our applications and also
>>> >>> wanted to review the installation and unlock process. We decided to
>>> >> do
>>> >>> all we can to make it as easy as possible for their executives-- who
>>> >> are
>>> >>> not programmers-- to review and make a decision on permission.
>>> >>>
>>> >>> One thing which has been mentioned a few times on sword-devel is that
>>> >>> frontends should begin to honor the new "UnlockInfo" .conf entry,
>>> >> which
>>> >>> has the purpose to explain to the user how to obtain an unlock key
>>> >> for a
>>> >>> particular module and in this modules clarifies to the user that this
>>> >>> module is still in the testing phase. It would be good to check
>>> >>> Bibletime to see if it has support for displaying "UnlockInfo" to the
>>> >>> user when a module is selected for installation.
>>> >>>
>>> >>> Thanks again for all you guys do,
>>> >>>
>>> >>> Troy
>>> >>>
>>> >>>
>>> >>> On 1/4/20 3:43 PM, Gary Holmlund wrote:
>>> >>>> Troy,
>>> >>>>
>>> >>>> Thanks for the information. Perhaps Lockman should not be in
>>> >>>>
>>> >>>> the masterRepoList.conf until it is available for purchase.
>>> >>>>
>>> >>>> Gary
>>> >>>>
>>> >>>>
>>> >>>> On 1/4/20 11:12 AM, Troy A. Griffitts wrote:
>>> >>>>> Hey guys. We don't have a deal with Lockman yet. They are
>>> >> reviewing
>>> >>>>> the latest work we've done and have pointed out a few issues we are
>>> >>>>> trying to fix. It does seem like we are at the brink of actually
>>> >> having
>>> >>>>> the NASB available, but we've said this for years, so I don't want
>>> >> to
>>> >>>>> promise anything. There is no place to purchase an unlock key yet
>>> >> and
>>> >>>>> when there is, it will be directly from Lockman. SWORD has had
>>> >> single
>>> >>>>> unlock code functionality unchanged for years in the engine. If
>>> >> Lockman
>>> >>>>> decides they want unique unlock codes per user, then you will need
>>> >> to
>>> >>>>> compile with SWORD trunk, as this capability was added about 12
>>> >> months
>>> >>>>> ago. Or with the soon to be release 1.9.0.
>>> >>>>>
>>> >>>>> Hope this clears things up a bit.
>>> >>>>>
>>> >>>>> Troy
>>> >>>>>
>>> >>>>>
>>> >>>>> On 1/3/20 9:41 PM, Gary Holmlund wrote:
>>> >>>>>> John,
>>> >>>>>>
>>> >>>>>> I would like to know this also. The unlock is implemented in the
>>> >>>>>>
>>> >>>>>> sword library. Perhaps you can get an answer at crosswire.org
>>> >>>>>>
>>> >>>>>> Gary Holmlund
>>> >>>>>>
>>> >>>>>> On 12/30/19 4:29 PM, John A. Sullivan III wrote:
>>> >>>>>>> Hello, all. I was absolutely thrilled to see the Lockman
>>> >> Foundation
>>> >>>>>>> now appear in the bookshelf options and I downloaded the NASB
>>> >> module.
>>> >>>>>>> I was about to purchase a key from Lockman but I see notes
>>> >> on-line
>>> >>>>>>> that
>>> >>>>>>> the module cannot yet be unlocked and is only for testing. I
>>> >> don't
>>> >>>>>>> know if those are old notes.
>>> >>>>>>>
>>> >>>>>>> If I purchase a NASB key, can I use it to unlock the NASB module
>>> >> in
>>> >>>>>>> Bibletime? Thank you for your dedication to this invaluable
>>> >> project -
>>> >>>>>>> John
>>> >>>>>> _______________________________________________
>>> >>>>>> bt-devel mailing list
>>> >>>>>> bt-devel at crosswire.org
>>> >>>>>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>> >>>>>>
>>> >>>>> _______________________________________________
>>> >>>>> bt-devel mailing list
>>> >>>>> bt-devel at crosswire.org
>>> >>>>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> bt-devel mailing list
>>> >>>> bt-devel at crosswire.org
>>> >>>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>> >>>
>>> >>> _______________________________________________
>>> >>> bt-devel mailing list
>>> >>> bt-devel at crosswire.org
>>> >>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> bt-devel mailing list
>>> >> bt-devel at crosswire.org
>>> >> http://www.crosswire.org/mailman/listinfo/bt-devel
>>> >
>>> >
>>> > _______________________________________________
>>> > bt-devel mailing list
>>> > bt-devel at crosswire.org
>>> > http://www.crosswire.org/mailman/listinfo/bt-devel
>>> >
>>>
>>>
>>> _______________________________________________
>>> bt-devel mailing list
>>> bt-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>>
>>>
>>> _______________________________________________
>>> bt-devel mailing list
>>> bt-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>>
>>
>> _______________________________________________
>> bt-devel mailing list
>> bt-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/bt-devel
>>
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>
More information about the bt-devel
mailing list