[sword-devel] Engine personal cipher support / Nestle - Aland 28th ed. German Bible Society
Jaak Ristioja
jaak at ristioja.ee
Thu Oct 31 07:48:45 MST 2019
On 31.10.19 01:30, Troy A. Griffitts wrote:
> Thank you for pointing out one problematic input condition which passes
> the validation checks already in the code.
>
> Your statement that there is no validation on input is incorrect. There
> is validation on input. You found one case which passed those
> validation checks. An additional check has been added to handle your
> case of passing an empty personalization prefix to the depersonalization
> mechanism.
>
> We appreciate your reporting of this unvalidated scenario. If you find
> additional strings which cause issues, please continue to provide feedback.
I believe the function should no longer crash (except when it runs out
of memory and throws an exception). If the size of the input string and
the parsed segments were bound, one could rewrite the entire function
without any memory allocations.
> Regarding the publisher's reason for requesting personalized unlock
> codes, in their mind, a user is less likely to share their unlock code
> if it is, e.g.,
>
> RISTIOJAJA2019-wEt-lum-UIw-GlQN
>
> They know it does not provide any additional software protection.
>
> I agree with their reasoning that it is a disincentive to share one's
> unlock key if the origin of that shared key can be traced back to a user.
>
> Hope this makes sense,
Yes, thank you Troy! That was my only conjecture as well. But it is a
really weak disincentive, because one can easily just de-personalize
"RISTIOJAJA2019-wEt-lum-UIw-GlQN" to "abc-123-def" and share that, or
even share DeutscheBibelgesellschaftPrivat-NvM-y0K-vbU-arWR or
TroyGriffitts2019-UWV-IOO-iYY-LBVM if one wants to shift the blame.
J
More information about the sword-devel
mailing list