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

[Greg Hellings]

Just another example emphasizing a reason to have module creation be
part of the test suite!

If I have time tonight, after work, I'll try to tackle making some
test cases.  Otherwise I will probably have a chance to get to it
later in the week.

--Greg

On Tue, Aug 25, 2009 at 9:16 AM, DM Smith<dmsmith at crosswire.org> wrote:
> On 08/25/2009 08:14 AM, DM Smith wrote:
>>
>> On Aug 25, 2009, at 5:42 AM, Chris Little wrote:
>>
>>>
>>>
>>> Jonathan Marsden wrote:
>>>>
>>>> Tim Chase wrote:
>>>>>
>>>>> Peter picked off my post to the module making forum.  Here are the
>>>>> steps that I went through for module creation on the windows platform
>>>>> where the osis2mod with cipher key does not produce an encrypted
>>>>> module.  Running on windows..
>>>>
>>>> Thanks for the detailed info.
>>>> I'm not usually up for Windows-specific troubleshooting/bugfixing "for
>>>> fun", I end up doing more than enough of that for work :)
>>>> However, Chris Little already seems to have zeroed in on the issue,
>>>> saying (about 24 hours ago):
>>>>>
>>>>> I suspect this is a problem specific to the Win32 VC++ builds, due to
>>>>> the old US export restriction code. I probably won't have a fix
>>>>> until tomorrow.
>>>>
>>>> so you may see a fix pretty soon, since from that reference point, it is
>>>> already "tomorrow" :)
>>>> Jonathan
>>>
>>> Actually, I'm pretty well dumbfounded now.
>>>
>>> I can't get the cipher to work anywhere that I've tried. It should be the
>>> case that if USBINARY is defined during the library build, it will enable
>>> the ciphering/deciphering code. If USBINARY is not defined, trying to do a
>>> cipher/decipher will just give you back the same text as you supplied.
>>>
>>> I tried adding USBINARY to the VC++ project, but that had no effect. I
>>> tried the BCB5 binaries from an older version (these have always had
>>> USBINARY defined), and I found that it was also failing to cipher. So I
>>> tried compiling svnhead in Ubuntu and found it to produce exactly the same
>>> result.
>>>
>>> I'm not sure how Jonathan is getting a positive result. I don't believe
>>> any significant changes to the cipher stuff were made between 2400 and head
>>> of osis2mod. So the different behavior reported between 2400 and 2435 is
>>> surprising.
>>>
>>> Anyway, that's all to say that I couldn't figure out what is wrong in the
>>> 1.5 hours I had to dedicate to the issue today. Additional reports of
>>> osis2mod working or not working with ciphering would probably be helpful.
>>
>> I'll look today to see that it works under Linux.
>
> It does not work.
>
> The code that has been there forever, no longer works. I checked out
> revision 1929 from June 2006 and with minor changes, compiled it against the
> current SWORD library. It has the same problem.
>
> That code is:
>        SWFilter *cipherFilter = 0;
>
>        if (!cipherKey.empty()){
>                fprintf(stderr, "Adding cipher filter with phrase: %s\n",
> cipherKey.c_str() );
>                cipherFilter = new CipherFilter(cipherKey.c_str());
>                module->AddRawFilter(cipherFilter);
>        }
>
> This is the same that is used in mod2zmod and tei2mod. Interestingly,
> cipherraw works entirely differently.
>
> I don't have a good environment to debug it and would appreciate someone to
> look at it. The basic idea is that the cipher is used on the raw text of a
> verse to create a jumbled string of the same length.
>
> In Him,
>    DM
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>