[bt-devel] NASB Unlock Key
Greg Hellings
greg.hellings at gmail.com
Tue Jan 7 09:30:09 MST 2020
Jaak,
I'm not sure why you choose this hill to die on when BibleTime already does
exactly this for the module info.
https://github.com/bibletime/bibletime/blob/a1c5848cf70d79f97b4a80c769b4d688b0b9560e/src/backend/drivers/cswordmoduleinfo.cpp#L1035-L1041
Why now, when it's UnlockInfo, does this suddenly become a problem?
--Greg
On Tue, Jan 7, 2020 at 2:58 AM 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 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
> >>>>>
> >>>> _______________________________________________
> >>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/bt-devel/attachments/20200107/cf617d09/attachment-0001.html>
More information about the bt-devel
mailing list