[squeak-dev] Re: Fixing SecureHashAlgorithm without plugins

timfelgentreff timfelgentreff at gmail.com
Thu May 19 08:37:22 UTC 2016


Hi Levente,

thank you, that change works great for me :)

Cheers,
Tim


Levente Uzonyi wrote
> Hi Tim,
> 
> I made a workaround using #adoptInstance: instead of copying in 
> System-ul.831. Hopefully you have one of the primitives (160, 115) it uses 
> implemented.
> I think it would be worth moving the fallback code from Integer down to 
> LargePositiveInteger, because that way SmallInteger receivers would 
> signal DNU instead of 'You can''t store in a SmallInteger'.
> 
> Levente
> 
> On Thu, 19 May 2016, timfelgentreff wrote:
> 
>> Hi,
>>
>> we're running the fallback code for SecureHashAlgorithm,
>> LargePositiveInteger, and lots of the optional primitives. In the
>> fallback
>> code of SecureHashAlgorithm>>finalHash there is a call that looks like
>> this:
>>
>>  (LargePositiveInteger new: result size)
>> 		replaceFrom: 1
>> 		to: result size
>> 		with: result
>> 		startingAt: 1;
>>                normalize
>>
>> Here, result is a ByteArray. The replaceFrom:to:with:startingAt: goes to
>> call primitive 105, which is marked as optional in the comment, so we do
>> not
>> implement it. However, the fallback code in
>> Integer>>replaceFrom:to:with:startingAt: sends digitAt: to the
>> replacement
>> object, and ByteArray doesn't understand that message.
>>
>> Clearly the fallback code behaves differently from the primitive.
>>
>> 1) One way to fix it would be to check the object type in the fallback
>> code.
>> If it is a byte object, we simply use at: (which is the same as digitAt:
>> for
>> Large*Integer).
>>
>> 2) Another fix is to add digitAt: to ByteArray. This feels very wrong to
>> me.
>>
>> 3) Alternatively, we might say that calling
>> replaceFrom:to:with:startingAt:
>> on an integer with any byte object is illegal. In that case, we could
>> instead fix the fallback code in SecureHashAlgorithm>>finalHash to do
>> this
>> in the end:
>>
>>  LargePositiveInteger adoptInstance: result.
>>  ^ result normalize
>>
>> This will fix the problem, but the fallback code will still be
>> inconsistent
>> with the primitive.
>>
>> I'm torn between 1 and 3, so what do you say?
>>
>> Cheers,
>> Tim
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Fixing-SecureHashAlgorithm-without-plugins-tp4895951.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>>





--
View this message in context: http://forum.world.st/Fixing-SecureHashAlgorithm-without-plugins-tp4895951p4895970.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.


More information about the Squeak-dev mailing list