<div>Thanks Peter,</div>
<div>
<br />
</div>
<div>We should therefore also encourage Karl to review and update any such modules in the Xiphos repository.</div>
<div>
<br />
</div>
<div>The reason I added my aside was that version values are clearly used for comparison purposes to determine whether a module has been updated.</div>
<div>Version is one of maybe only a few configuration keys upon which calculations are made.</div>
<div>This logically led me to pose the question about potential buffer overflows, even though I'm not part of the SWORD coding team.</div>
<div>cf. My awareness of what can be exploited from a buffer overflow or the like has been honed by 13 years of watching the Security Now! webcasts on twit.tv</div>
<div>
<br />
</div>
<div>Further aside: How does JSword process the same key?</div>
<div>
<br />
</div>
<div>David</div>
<div>
<br />
</div>
<div id="protonmail_mobile_signature_block">Sent from ProtonMail Mobile</div>
<div>
<br />
<div>
<div>
<br />
</div>On Tue, Sep 25, 2018 at 11:54, Peter Von Kaehne <<a href="mailto:refdoc@gmx.net" class="">refdoc@gmx.net</a>> wrote:</div>
<blockquote class="protonmail_quote" type="cite">I think there are two aspects then - version numbers should be correct in current modules. I think the bulk of the modules you listed are Xiphos, not CrossWire, but at least one is issued by CrossWire, maybe more. I will fix CrossWire's set.
<br />
<br />The other is - wrong version numbers should not crash the engine or produce unreliable/undefined results. Or at least the engine should go down with a decent error message. In essence all places where wrong module conf file entries can cause grief in
the engine, I guess some level of sanity checking should happen - Particularly if we want to encourage other publishers to take up offering repositories.
<br />
<br />Peter
<br />
<br />
<br />
<br />> Gesendet: Dienstag, 25. September 2018 um 10:56 Uhr
<br />> Von: "Jaak Ristioja" <jaak@ristioja.ee>
<br />> An: sword-devel@crosswire.org
<br />> Betreff: Re: [sword-devel] Module version numbers
<br />>
<br />> > Aside: Are there any limits to the number of dot separators in the
<br />> Version value, or to the number of digits in total or in any part?
<br />> > Would SWORD crash with a buffer overflow were it to encounter an
<br />> inordinately long Version?
<br />>
<br />> The relevant code to parse the version string is in the SWVersion
<br />> constructor:
<br />>
<br />> SWVersion::SWVersion(const char *version) {
<br />> char *buf = new char[ strlen(version) + 1 ];
<br />> char *tok;
<br />> major = minor = minor2 = minor3 = -1;
<br />>
<br />> strcpy(buf, version);
<br />> tok = strtok(buf, ".");
<br />> if (tok)
<br />> major = atoi(tok);
<br />> tok = strtok(0, ".");
<br />> if (tok)
<br />> minor = atoi(tok);
<br />> tok = strtok(0, ".");
<br />> if (tok)
<br />> minor2 = atoi(tok);
<br />> tok = strtok(0, ".");
<br />> if (tok)
<br />> minor3 = atoi(tok);
<br />> delete [] buf;
<br />> }
<br />>
<br />> Very long version strings can only crash it if this runs out of memory.
<br />> Other than that, it will just return an incorrect version. There are no
<br />> limits to the number of dot separators, but only up to 4 version
<br />> components separated by dots are actually parsed. AFAIK, the behavior of
<br />> atoi() is undefined for invalid input. On my system, the results are as
<br />> follows:
<br />>
<br />> "9.1" -> 9.1
<br />> "99.1" -> 99.1
<br />> "999.1" -> 999.1
<br />> "9999.1" -> 9999.1
<br />> "99999.1" -> 99999.1
<br />> "999999.1" -> 999999.1
<br />> "9999999.1" -> 9999999.1
<br />> "99999999.1" -> 99999999.1
<br />> "999999999.1" -> 999999999.1
<br />> "9999999999.1" -> 1410065407.1
<br />> "99999999999.1" -> 1215752191.1
<br />> "999999999999.1" -> -727379969.1
<br />> "9999999999999.1" -> 1316134911.1
<br />> "99999999999999.1" -> 276447231.1
<br />> "999999999999999.1" -> -1530494977.1
<br />> "9999999999999999.1" -> 1874919423.1
<br />> "99999999999999999.1" -> 1569325055.1
<br />> "999999999999999999.1" -> -1486618625.1
<br />> "9999999999999999999.1" -> -1.1
<br />> "99999999999999999999.1" -> -1.1
<br />>
<br />>
<br />> J
<br />>
<br />> On 25.09.2018 12:03, David Haslam wrote:
<br />> > Ignoring the spurious SwordVersion hit, it seems that the string after the dash is a date in six digit format.
<br />> >
<br />> > IMHO, these modules should simply be re-issued with the dates recorded in the respective History key.
<br />> >
<br />> > It's not worth the effort to make the API parse these as they are now.
<br />> > The dash is a nonconformance to what should be in the Version key.
<br />> >
<br />> > Aside: Are there any limits to the number of dot separators in the Version value, or to the number of digits in total or in any part?
<br />> > Would SWORD crash with a buffer overflow were it to encounter an inordinately long Version?
<br />> >
<br />> > Best regards,
<br />> >
<br />> > David
<br />> >
<br />> > Sent from ProtonMail Mobile
<br />> >
<br />> > On Tue, Sep 25, 2018 at 09:44, Jaak Ristioja <jaak@ristioja.ee> wrote:
<br />> >
<br />> >> Hello!
<br />> >>
<br />> >> Most modules include version numbers matching the regular expression
<br />> >>
<br />> >> ^[0-9]+(.[0-9]+)*$
<br />> >>
<br />> >> However, looking at the .conf files, there are version fields with
<br />> >> values also containing dashes:
<br />> >>
<br />> >> ~/.sword/mods.d $ grep -E 'Version=.*-' *
<br />> >> 2tgreek.conf:Version=2.7-120109
<br />> >> invstrongsrealgreek.conf:Version=1.4-090107
<br />> >> jesermons.conf:SwordVersion=2017-05-24
<br />> >> strongsrealgreek.conf:Version=1.5-150704
<br />> >> tischmorph.conf:Version=2.7-120109
<br />> >>
<br />> >> How should these be interpreted? Should 1.2-3.4 be interpreted as
<br />> >> (1).(2-3).(4) or (1.2)-(3.4)? It seems that SWVersion interprets such as
<br />> >> just 1.2.4 (without the -3 entirely).
<br />> >>
<br />> >> God bless!
<br />> >> J
<br />> >>
<br />> >> _______________________________________________
<br />> >> sword-devel mailing list: sword-devel@crosswire.org
<br />> >> http://www.crosswire.org/mailman/listinfo/sword-devel
<br />> >> Instructions to unsubscribe/change your settings at above page
<br />> >>
<br />> >>
<br />> >> _______________________________________________
<br />> >> sword-devel mailing list: sword-devel@crosswire.org
<br />> >> http://www.crosswire.org/mailman/listinfo/sword-devel
<br />> >> Instructions to unsubscribe/change your settings at above page
<br />>
<br />>
<br />> _______________________________________________
<br />> sword-devel mailing list: sword-devel@crosswire.org
<br />> http://www.crosswire.org/mailman/listinfo/sword-devel
<br />> Instructions to unsubscribe/change your settings at above page
<br />>
<br />
<br />_______________________________________________
<br />sword-devel mailing list: sword-devel@crosswire.org
<br />http://www.crosswire.org/mailman/listinfo/sword-devel
<br />Instructions to unsubscribe/change your settings at above page
<br />
</blockquote>
</div>