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
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
