[bt-devel] NASB Unlock Key

Sat Jan 4 18:55:31 MST 2020

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 <textpar>? Can the parser
expect the representation format to be ASCII (with escapes) according to
the RTF spec?

Now, adding <a href="">links</a> to the mix, should this HTML construct
be parsed inside all RTF constructs or just certain contexts? Or should
the HTML <a> element be parsed before RTF? Can the <a>display text</a>
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 <jaak at ristioja.ee> 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
> 