[bt-devel] NASB Unlock Key
Jaak Ristioja
jaak at ristioja.ee
Tue Jan 7 11:37:28 MST 2020
Dear Troy,
> This let's us remain agile
Which might not always be a good thing because it might make it easier
to break things.
> not worrying that we might break someone else's implementation by
changing sonething
There is always room for accidents, even now. I still think that it is
better to have different versions of interfaces, possibly with a means
for parties to negotiate the best version used (e.g. the SWORD engine
supporting module configuration files written according to different
versions of the module configuration file format specification), because
this what best ensures compatibility and does not arbitrarily change any
expectations/assumptions held by the different components/parties.
If you make important changes to the protocol without negotiating with
frontend developers or do so without notice, you might be inadvertently
lead frontends to decide to strictly require specific versions of SWORD
which are known to work for them.
> we strongly discourage accessing our data without our engine-- in
fact, it is often illegal to do so, as many of our data modules have
permission granted to us specifically for use within our software.
Can you give an example of such a module? I know some modules only
restrict (re)distribution, but not use. The software itself seems to
contain no such warnings, and SWORD is under the GPL. Either way, I'm
still moving ahead with what is now called Sword++.
> your efforts to rewrite our entire engine and naming it something
misleading like sword++ which implies we support your efforts.
Btw, immediately after sending my previous e-mail this morning, I wrote
to #sword++ on Freenode that I'm thinking of changing the name to
something better. This will then be resolved.
> You are asking us to give up our agility to stick with strict
specifications which don't change without coordination with you so you
can rewrite our code in a way you like to solve problems our users might
experience but never have.
You can be agile and release a new version of a spec without
coordination. Is that not enough? Of course if continue to force changes
upon frontends without coordination, frontends will become more
defensive. You can stick to your agility and we can stick to SWORD
version 1.8.1.
Not that such a relation between me asking that and me rewriting code
exists, but Sword++ already contains much rewrite. I'm currently not
planning to work on SWORD much.
There has been at least one case where it seems you (or other SWORD
devs) didn't believe that a problem we reported actually existed or
occurred, or at least didn't care to fix the issue: the hang issue I
reported after the release of 1.8.0RC2 (see the "SWORD 1.8.0RC2" and
"SWORD 1.8.0RC3" threads in sword-devel) was a very real and
reproducible experience. I even referenced
https://github.com/swordxx/swordxx/commit/b253a8888c1dc683ea93b38efce0f6113dea9b47
to help this getting fixed, but to no avail. I guess that this never
appeared got put on a TODO list as well.
It is quite impossible to fix some bugs in SWORD code without bigger,
API-breaking changes. You don't seem to be motivated at all to integrate
any non-trivial changes even after long discussions, and I'm not
motivated to only fix the trivial bugs. Writing patches for SWORD is not
a priority for me, I will instead concentrate my development efforts on
Sword++ and BibleTime.
> I would personally be more concerned that they would change the TEXT
OF THE BIBLE!
Module signing.
> If, in fact, you have a case where you find RTFHTML crash, I would
love for you to describe the scenario and for you to submit a simple
patch to handle that corner case.
Have you already fixed the HTML injection issue in RTFHTML which I
referenced earlier? Regardless of changed syntax, std::string and such,
I believe it should be rather trivial to fix in SWORD as well.
> If you in fact have the eventual plan not to use our engine, but to
continue to use our datasets, against our will, I would suggest you
begin now by stopping to use our datasets because their markup and
format will change without warning and in addition you likely will be
violating copyright law by using many of them.
Please be more specific. I have a bunch of modules in my ~/.sword. How
do I tell whether I can use them with other software? Am I allowed by
copyright law to use cat and/or grep to find out?
Either way this sounds serious. Perhaps we should in BibleTime disable
the Crosswire repositories by default or at least add some kind of
warning message or icon to discourage their use, especially once we stop
using SWORD?
We might also consider hosting our own module repository for modules
which are freely redistributable, or perhaps even our own master
repository list.
> If a user decides to use our software to read data outside of what we
offer, this is equal to a user who downloads a set of HTML files and
opens them in their web browser. They have decided to trust the source.
They have to take some responsibility for their actions.
First of all, do you really have no glue about the enormous amounts of
effort web browser developers are putting into making their browsers
safe to use?
Secondly, the random user might have no clue about this. BibleTime users
might even never have heard of SWORD or Crosswire, let alone know how
trustworthy Crosswire repositories are. An official "BibleTime"
repository might seem much more trustworthy to BibleTime users.
Best regards,
J
On 07.01.20 12:44, Troy A. Griffitts wrote:
> Hi Jaak. It's 2am. I just want to write a quick reply for you and others to think about during your European day while we sleep over here in the US.
>
>> We at BibleTime have the
>> capability to write a better parser, to do so we would need a spec.
>
> Herein lies the core problem. You want CrossWire and SWORD to be something we are not.
>
> We are not a specification. We are not the source of a general dataset of Bible material. We have, with forethought, made the decision not to be these things. This let's us remain agile to change our code and our data formats and markup whenever we want, not worrying that we might break someone else's implementation by changing sonething. For this reason and others, we strongly discourage accessing our data without our engine-- in fact, it is often illegal to do so, as many of our data modules have permission granted to us specifically for use within our software. This is not our choice. We'd like for all of our data to be freely redistributable but often permission to us is the best we can get from publishers. This means that we don't support you rewriting a better parser, or your efforts to rewrite our entire engine and naming it something misleading like sword++ which implies we support your efforts.
>
> You are asking us to give up our agility to stick with strict specifications which don't change without coordination with you so you can rewrite our code in a way you like to solve problems our users might experience but never have.
>
> We don't build a generic reader. We control the data which is available with our software. If there is malicious data then the data is the problem. Sure, bugs might exist in our code, and sure, I'd certainly rather our code fail gracefully rather than crash on bad data; if you have a specific problem, I'd love to have a patch. I appreciated and applied your recent patch to the new unlock key personalization for the case when the seed was zero length.
>
> Concerning your proposed security possibilities: that someone hacks into our server and changes a small bit of our data, I would personally be more concerned that they would change the TEXT OF THE BIBLE!
>
> If we go down the road of trying to prevent all possible bad data scenarios from the .conf file, then we'd have to go down that same road for e.g., the OSISHTML filters. Trying to write a specification for Bible translators and then to actually get them to conform to that specification has not been a pretty thing. We often change a ton of inconsistent markup when we receive data from a publisher. So, to stress again, we are not a general reader of any data someone else might publish on the internet. We often massage data we receive from publishers to very specifically work with our engine.
>
> If, in fact, you have a case where you find RTFHTML crash, I would love for you to describe the scenario and for you to submit a simple patch to handle that corner case. And please make it look like it goes along with the other code which surrounds it-- as horrible as you might find our coding standarda. As of now none of our other frontends have reported they have experienced crashes with this filter, nor have any of the users from my frontends.
>
> If you in fact have the eventual plan not to use our engine, but to continue to use our datasets, against our will, I would suggest you begin now by stopping to use our datasets because their markup and format will change without warning and in addition you likely will be violating copyright law by using many of them. We do our best to help other project by including the source link where we obtain the data for each module. You can reprocess each from their source into some format your code desires. Blessings in your efforts.
>
> If you would like to improve actual problems your users run into, we would love to put you through the pains to live within our coding style and chosen boundaries and goals and to submit inconspicuous patches for any of these problems you find. I was happy to even entertain 'security' patches for your proposed scenarios until I saw they removed support for <a href> by escaping '<' and unnecessarily introduced std::string into the code... though I think you are missing the bigger picture here:
>
> If a user decides to use our software to read data outside of what we offer, this is equal to a user who downloads a set of HTML files and opens them in their web browser. They have decided to trust the source. They have to take some responsibility for their actions.
>
> Sorry, that was longer than I had intended,
>
> Troy
>
> On January 7, 2020 1:58:04 AM MST, Jaak Ristioja <jaak at ristioja.ee> wrote:
>>> and you are refusing to do this because... it somehow doesn't have a
>>> clear definition of what we are doing under the covers in our RTFHTML
>>> filter.
>>>
>>> Have I restated the exact current problem?
>>
>> No. The RTFHTML code does not properly handle corner cases leading the
>> way to potential (security?) issues for our users, which is why we're
>> not going to use that as it is right now. We at BibleTime have the
>> capability to write a better parser, to do so we would need a spec.
>> That
>> spec would define the allowed syntax for module writers, hence it is a
>> public interface and not a description of what RTFHTML does internally.
>> This would be the specification for the protocol of how SWORD (created
>> by Crosswire) interfaces with modules (created by module writers not
>> necessarily from Crosswire).
>>
>> Actually, perhaps it were better if there was a spec about the output
>> of
>> RTFHTML, e.g. something like Gary suggested. This together with RTFHTML
>> working properly (not crash, not have security bugs, properly report
>> errors including due to incorrect input) will likely suffice for the
>> needs of BibleTime at least for the foreseeable 5-7 years.
>>
>> A well-defined spec for the contents of that field (the input to
>> RTFHTML) might still be needed for module writers / generators /
>> converters etc to properly interface with SWORD. Note also that if your
>> configuration files would be properly versioned (e.g. configuration
>> file
>> contains the version of the spec it conforms to), you would have no
>> problems adding new features to the spec and to RTFHTML while also
>> bumping the versions. If done properly, the engine could seamlessly
>> handle module configurations conforming to different versions of the
>> spec. For example, if your current spec is version 5, and you want to
>> support a new feature in the configuration file, you just add the
>> feature into spec version 6, and then amend the configuration files
>> accordingly, e.g.
>>
>> [General]
>> SwordConfigurationApiVersionRequired=6
>>
>> Unfortunately, since such versioning is not part of the current spec,
>> you need certain workarounds for something like this to work for
>> features which extend the INI-like syntax of the configuration file,
>> not
>> just what changes the semantics for the values or similar.
>>
>> There are also other possibilities to add new features in backwards
>> compatible manner as well (so that module configurations with new
>> features still continue to work with (some) older versions of Sword)
>> but
>> this is much harder to do properly (even without specs).
>>
>> Therefore, since adding new features can mostly be done properly with
>> formal (versioned) specifications and mostly in compatible manner,
>> citing something like this as an excuse to not having specifications is
>> rather lame.
>>
>> What I am offering would not hinder SWORD from offering to frontend
>> developers what you called "new modules and new functionality with new
>> engine releases without any change in their code". On the contrary, I
>> believe this would actually improve compatibility. Furthermore, I feel
>> quite safe to state that proper specifications per se would not hinder
>> you to continue to provide new features as you've done previously
>> (except of course if you have already done certain things wrong). The
>> biggest downside is that you have to properly update the spec as well,
>> which might be tedious for people with not much experience in doing so.
>>
>> Whether this aligns with what you called your "purposes for the engine"
>> depends on you, or so it seems. As things stand now for BibleTime we
>> still have planned for BibleTime to use Sword++ instead of SWORD when
>> the time is right.
>>
>> J
>>
>>
>> On 07.01.20 02:06, Troy A. Griffitts wrote:
>>> So, just to summarize for all who are reading this thread...
>>>
>>> o A new useful feature for the end user has been added to SWORD and
>>> we're asking you to make this available to your user:
>>>
>>> to show them how to obtain an unlock key when they try to
>> install
>>> a locked module.
>>>
>>> The recommended way SWORD has for you to get the HTML for this is to
>> use
>>> these 2 lines:
>>>
>>> SWBuf unlockInfo = book->getConfigEntry("UnlockInfo");
>>> RTFHTML().processText(unlockInfo);
>>>
>>> and you are refusing to do this because... it somehow doesn't have a
>>> clear definition of what we are doing under the covers in our RTFHTML
>>> filter.
>>>
>>> Have I restated the exact current problem?
>>>
>>>
>>> To repeat. I don't WANT a concrete definition of what we are doing
>>> under the covers. I WANT to be able to... for example... support
>> some
>>> new HTML or RTF tag we might need in the future and I will add that
>>> support to the RTFHTML filter. All frontends using the recommended
>>> lines above will magically get the new functionality without needing
>> to
>>> change or even know we support new tags under the covers. This is
>>> intentional. SWORD is not a specification for someone to re-write.
>> It
>>> is an ever-growing library for programmers to use. We do our best to
>>> keep our public interfaces backward compatible and try to make
>>> improvements within the implementation.
>>>
>>> I am pushing back on your suggestion for the practical reasons:
>>>
>>> a) you can do what you need right now in a very easy way: 2 lines of
>>> code-- which has been the way to do this for 20+ years.
>>>
>>> b) your suggestion to define a formal spec for what I am doing in the
>>> RTFHTML filter will prohibit me from doing exactly what SWORD offers
>> to
>>> frontend developers: new modules and new functionality with new
>> engine
>>> releases without any change in their code.
>>>
>>> You are preventing your users from having functionality because we
>> don't
>>> do things the way you want. That's your choice. We offer the
>>> capability. You won't use it for some esoteric reason.
>>>
>>> I am happy to cooperate, but not at the expense of our purposes for
>> the
>>> engine.
>>>
>>> Troy
>>>
>>>
>>>
>>> On 1/6/20 3:46 PM, Jaak Ristioja wrote:
>>>> Dear Troy,
>>>>
>>>> I think the bottom line is that you just don't care for our
>> concerns.
>>>> Because by the end of the day, after much labor to communicate and
>>>> improve things, we are left empty-handed, and the concerns remain.
>>>>
>>>> Yes, you have a bunch of justifications for why our concerns,
>> proposals
>>>> and patches are stupid, unimportant or irrelevant pseudo-problems.
>> I'm
>>>> sorry, but we disagree. However stupid our concerns might seem to
>> you,
>>>> this doesn't change the fact that we still feel otherwise: that our
>>>> concerns are real.
>>>>
>>>> Issue after issue, e-mail after e-mail our needs have been ignored
>> and I
>>>> feel that every such response from you just makes me more and more
>> sick.
>>>> It doesn't even matter if you know best, whether you're right or
>> what
>>>> your reasons are — deeds speak louder than words. The fact is that
>> you
>>>> have been very uncooperative and I feel that this has been quite
>> toxic.
>>>>
>>>> BibleTime will display the UnlockInfo in verbatim plain text only
>> and
>>>> will not attempt to parse any specific formatting syntax until a
>> good
>>>> enough (for me) formal specification for that syntax has been
>> created.
>>>> My offer to help specify the syntax formally still stands.
>>>>
>>>> J
>>>>
>>>> On 06.01.20 00:47, Troy A. Griffitts wrote:
>>>>> Again, I would state that the problem you are having is that you
>> aren't
>>>>> content to use the SWORD engine as-is, but feel you need to
>> redesign all
>>>>> of its interfaces and re-implement large parts of the engine. I am
>> a
>>>>> consumer of the engine. I write frontends regularly against the
>>>>> engine. If you would be content to simply use the engine as it is
>>>>> written, you could write a frontend very quickly and without much
>> effort.
>>>>>
>>>>> I have often asked the bottom line question when you complain about
>>>>> these things:
>>>>>
>>>>> What exactly and practically, can't you do that you feel you need
>> to
>>>>> "hack around" the engine. What exact feature are you trying to
>>>>> implement that all other frontend developers haven't implemented?
>> We
>>>>> eat our own cooking. We write many different frontends in many
>>>>> different programming languages for many different sytles of Bible
>>>>> research, and improve the engine as we find difficulties writing
>> these
>>>>> frontends. It is not as if we live in a bubble and don't actually
>> use
>>>>> our code. If 3 of my frontends all had the same hack because SWORD
>> did
>>>>> something unnecessarily odd, I would be the first one to push an
>> update
>>>>> into the engine. So, without specific examples of what exactly you
>> are
>>>>> having trouble delivering to your users because of large issues
>> with
>>>>> SWORD-- more specific than "hacks all over", we can't help you
>> either
>>>>> understand how we intend for you to use SWORD to deliver that
>>>>> functionality and help you have an easier time, or else really see
>> some
>>>>> novel feature you are attempting to add which SWORD really doesn't
>>>>> easily handle and find together a way to improve things. SWORD
>> does
>>>>> very specific tasks, each in a very specific way. If you use it as
>> it
>>>>> was intended instead of trying to change its programmatic paradigm
>> to
>>>>> what you think it should be, it works reasonably well and provides
>> a
>>>>> huge amount of services necessary for building a Bible research
>> tool and
>>>>> will isolate you from a ton of tasks common to many Bible research
>>>>> tools, to let you focus on your users and your specific frontend,
>> and
>>>>> we'll try to protect you from having to rewrite your working code
>> by
>>>>> providing new modules and new features under the covers which you
>> can
>>>>> slowly add to your frontend if you feel it fits. If you "kick
>> against
>>>>> the goads" and try to make SWORD work in a way it wasn't intended,
>> you
>>>>> will likely run into issues. You have your entire frontend to
>> design as
>>>>> you see fit and use whatever programming paradigm you'd like.
>> Simply
>>>>> use SWORD as you would libz or libcurl or whatever other utility
>> you
>>>>> need. Accept their paradigm. If necessary, work within their
>> paradigm
>>>>> to add any features you see lacking, and save your idealism for
>> your own
>>>>> code. Life is too short to make everyone do things the way you
>> think
>>>>> they should do things.
>>>>>
>>>>> Again, I want to improve the engine. If you are building X super
>> cool
>>>>> feature and really can't figure out a way to add your super cool
>> feature
>>>>> because SWORD doesn't allow it, I am happy to discuss how we can
>> improve
>>>>> the engine to give you and all other frontend developers the
>> ability to
>>>>> deliver X to our end users. But these conversations between you
>> and I
>>>>> are usually about incomplete specifications and lack of use of the
>>>>> latest C++ features or the latest in vogue programming models or
>> trying
>>>>> to solve some theoretical problem no one has run into in 30 years
>> of SWORD.
>>>>>
>>>>> So, yes, I am not interested in changing a highly optimized and
>> highly
>>>>> portable codeset, to risk giving up that portability and
>> optmization so
>>>>> we can use the latest template library, latest programming
>> paradigm, or
>>>>> latest features in C++. Again, if you have a new feature you are
>>>>> attempting to add to Bibletime and just can't do it because you
>> have so
>>>>> much trouble getting the data you need from SWORD, please let me
>> know
>>>>> and I would love to discuss and improve the engine for you and
>> everyone
>>>>> else.
>>>>>
>>>>> Troy
>>>>>
>>>>>
>>>>> On 1/5/20 2:35 PM, Jaak Ristioja wrote:
>>>>>> Dear Peter,
>>>>>>
>>>>>> I really wish it were as simple as adding amending a few vague
>>>>>> statements. But actually, the specification is just plain
>> incorrect in
>>>>>> many ways not so easily amendable.
>>>>>>
>>>>>> For example, the tutorial states that "whitespace can be around
>> the = as
>>>>>> well." and also gives an example: "ModDrv = zText". This is
>>>>>> incorrect at least in part, because in such cases, SWConfig parses
>> the
>>>>>> key as "ModDrv " (with including the whitespace).
>>>>>>
>>>>>> For another example, there are issues with the so-called
>> "continuation
>>>>>> lines". Whereas http://wiki.crosswire.org/DevTools:conf_Files
>> states
>>>>>> these are allowed in some places and not in others, it seems to me
>> that
>>>>>> continuation lines are allowed and work everywhere (as that logic
>> seems
>>>>>> to be incorporated into FileMgr::getLine() which SWConfig uses to
>> read
>>>>>> lines). Additionally, the tutorial states that under the
>> "Continuation"
>>>>>> section the following:
>>>>>>
>>>>>> This is not a mechanism to make long lines more readable
>>>>>> in the module.conf file. It is a means to introducing a
>>>>>> break in the rendered output of that field when viewed by
>>>>>> a front-end or installer. It is akin to a xHTML <br/>.
>>>>>> That is, continuation is a formatting feature.
>>>>>>
>>>>>> Please correct me, but it seems exactly the opposite, because the
>>>>>> backslashes are stripped by FileMgr::getLine() so nothing can turn
>> them
>>>>>> into line breaks later. Continuation lines are simply a feature to
>> make
>>>>>> module.conf files more readable.
>>>>>>
>>>>>> There are also several other issues, but its not the issues
>> themselves
>>>>>> that are holding me back. I think the greater obstacle is that in
>>>>>> reality requires talks, exchange of information and much
>> cooperation
>>>>>> with Sword developers, including them fixing and improving the
>> engine.
>>>>>> But Sword developers are not that interested (see Troy's email
>> dated
>>>>>> Sun, 5 Jan 2020 13:23:40 -0700), they don't see such issues as big
>>>>>> problems. And in the end frontend developers like us have to grind
>> our
>>>>>> teeth while hacking around their technically "wonderful" library.
>>>>>>
>>>>>> As long as Sword developers continue to ignore most of our
>> technical
>>>>>> concerns, I don't see how me amending the wiki could be a
>> solution. The
>>>>>> best I could do is to document the brokenness. I don't see how it
>> were
>>>>>> possible for me to do better without more cooperation from the
>> Sword
>>>>>> developers, but it seems that once again we will not getting any
>> of
>>>>>> that... ;-\
>>>>>>
>>>>>> J
>>>>>>
>>>>>>
>>>>>> On 05.01.20 15:54, refdoc at gmx.net wrote:
>>>>>>> Dear Jaak,
>>>>>>>
>>>>>>> Thanks for the apology, accepted.
>>>>>>>
>>>>>>> Wrt the further remarks, this is an open source project and a
>> wiki. It is open
>>>>>>> to change and improvements. In particular the Wiki is very open
>> to improvements,
>>>>>>> get yourself an.account and add where things are vague or
>> unclear.
>>>>>>>
>>>>>>> I agree in that module security can become an issue when powerful
>> display
>>>>>>> engines are used uncritically and without sufficient sandboxing
>> and sanitizing
>>>>>>> of module content. We try and safeguard by having our own upload
>> criteria for
>>>>>>> modules and only allowing repos to become part of the "official"
>> set up which
>>>>>>> guarantee a certain level of sanity. Security as a process....
>> But this may well
>>>>>>> not be sufficient and in in the end each step of the process does
>> benefit from
>>>>>>> review and improvement at all times. So, join the wiki and
>> improve upon it, feel
>>>>>>> free.
>>>>>>>
>>>>>>> As such (not speaking about RTF as I know least about that) much
>> of the module
>>>>>>> related engine output is subject to a sanity check within the
>> filters whereby
>>>>>>> unrecognised codes are nuked or made safe.
>>>>>>>
>>>>>>> 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:
>>>>>>>
>>>>>>>
>>>>>>> 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 d
>
More information about the bt-devel
mailing list