[sword-devel] using encryption with current osis2mod (r2435

[Jonathan Marsden]

Tim Chase wrote:

> Using the windows versions of the tool osis2mod I have run tests 
> making four types of modules(raw, raw + cipher, zipped, zipped +
> cipher). In both cases that the -c switch was used ( -c
> abcd1234efgh5678) while the osis2mod program output indicated that
> the cipher key phase was being used, identical modules were produced
> without any encryption.

Thanks for doing the extra tests!  This suggests that either there is a
Windows / Linux difference in this area somewhere, or else the SWORD and
osis2mod you are using were not compiled with USBINARY defined and so
(by design??) do not encrypt at all under any circumstances.

Since the export restrictions are history, we should probably check that
 the Windows binaries Crosswire publishes do have the encryption code
enabled.  I know the default in usrinst.sh is to compile with -DUSBINARY
on Unix-like patforms, so all my tests based on svn have it defined.
I'm not sure what the Windows defaults are... as far as I can tell,
lib/vcppmake/vc8/libsword.vcproj does not define USBINARY anywhere.

Hmmm... and I think our package debian/rules file also omits it, which
would explain why my r2400 osis2mod (installed from a .deb) didn't
encrypt, but both the crosswire.org r2337 one (of unknown origin, but
presumably compiled by hand) and my r2435 one (compiled by hand from svn
using usrinst.sh) did.

Of course, I *would* discover this packaging issue literally a few hours
after the Ubuntu Karmic Feature Freeze happens (bad timing!).

SUMMARY: Looks like we could use a bit more consistency in our default
compiler/linker options :)

Tim, if you are compiling SWORD yourself under Windows, please try
defining USBINARY in the appropriate PreprocessorDefinitions line(s) in
lib/vcppmake/vc8/libsword.vcproj and recompile, reinstall, and retest
yet again.  I think and hope that is the right place to define this for
a Windows Visual C++ build.

Chris and the SWORD devs: it might be helpful if an osis2mod (and all
the family of *2mod utilities for that matter) that is compiled without
USBINARY defined would output an error message, rather than saying it is
encrypting but not actually doing so... how hard would this be to add?
Maybe even not offer the -c option if USBINARY is omitted at compile
time, and changing the help output accordingly?

Or, if there is no need at all for USBINARY now anyway, as I rather
suspect, then it might be better to just remove the

#ifdef USBINARY

and the related

#else
    return b;
#endif

from src/modules/common/sapphire.cpp and so guarantee that every copy of
SWORD always has the encryption code compiled into it future :)

Jonathan