Save as new image -> ModificationForbidden!



Hi, there.

I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.

Boom! ModificationForbidden!

Here is the interesting stack:

Context>>modificationForbiddenFor:at:put:

LargePositiveInteger(Object)>>basicAt:put:

SecurityManager>>flushSecurityKey:

SecurityManager>>flushSecurityKeys

SecurityManager>>shutDown

SecurityManager class>>shutDown

SecurityManager class(Behavior)>>shutDown:

[] in SmalltalkImage>>send:toClassesNamedIn:with:

OrderedCollection>>do:

SmalltalkImage>>send:toClassesNamedIn:with:

SmalltalkImage>>processShutDownList:

Well, that code tries to change a LargePositiveInteger:

SecurityManager >> flushSecurityKey: aKey

"Flush a security key"

| n |

n := aKey first.

1 to: n basicSize do:[:i| n basicAt: i put: 0].

n := aKey second.

1 to: n basicSize do:[:i| n basicAt: i put: 0].

How to fix that without breaking security measures or the underlying concept?

Best,

Marcel

Am 24.03.2020 11:04:48 schrieb Torge Husfeldt <[hidden email]>:

Simple: 

• create a weak reference to said bigInt

• remove last hard reference

• call gc

• verify that weak reference points to reclaimed object 

;)

You will have to do that one step down the stack, though 

Von meinem iPhone gesendet

Am 24.03.2020 um 09:39 schrieb Marcel Taeumel <[hidden email]>:



Hi, there.

I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.

Boom! ModificationForbidden!

Here is the interesting stack:

Context>>modificationForbiddenFor:at:put:

LargePositiveInteger(Object)>>basicAt:put:

SecurityManager>>flushSecurityKey:

SecurityManager>>flushSecurityKeys

SecurityManager>>shutDown

SecurityManager class>>shutDown

SecurityManager class(Behavior)>>shutDown:

[] in SmalltalkImage>>send:toClassesNamedIn:with:

OrderedCollection>>do:

SmalltalkImage>>send:toClassesNamedIn:with:

SmalltalkImage>>processShutDownList:

Well, that code tries to change a LargePositiveInteger:

SecurityManager >> flushSecurityKey: aKey

"Flush a security key"

| n |

n := aKey first.

1 to: n basicSize do:[:i| n basicAt: i put: 0].

n := aKey second.

1 to: n basicSize do:[:i| n basicAt: i put: 0].

How to fix that without breaking security measures or the underlying concept?

Best,

Marcel

Hi Marcel,

I cannot reproduce this using a fresh Trunk image (Update 19541, VM 201912311458), because privateKeyPair is nil by default, but the following looks suspicious to me:

No idea how your image can have this, as #loadOLPCOwnerKeys has no senders in Trunk, but maybe we should fix this defect via #copy and write an update script ...

Best,

Christoph

Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <[hidden email]>:

Hi Marcel,

System-ul.1148 should work the issue around. Please let me know if it
helped.
The main issue is that literal objects created by Compiler >> #evaluate:*
are now immutable but I think they shouldn't be. What do you think?


Levente

On Tue, 24 Mar 2020, Marcel Taeumel wrote:

> Hi, there.
>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
>
> Boom! ModificationForbidden!
>
> Here is the interesting stack:
>
> Context>>modificationForbiddenFor:at:put:
> LargePositiveInteger(Object)>>basicAt:put:
> SecurityManager>>flushSecurityKey:
> SecurityManager>>flushSecurityKeys
> SecurityManager>>shutDown
> SecurityManager class>>shutDown
> SecurityManager class(Behavior)>>shutDown:
> [] in SmalltalkImage>>send:toClassesNamedIn:with:
> OrderedCollection>>do:
> SmalltalkImage>>send:toClassesNamedIn:with:
> SmalltalkImage>>processShutDownList:
>
> Well, that code tries to change a LargePositiveInteger:
>
> SecurityManager >> flushSecurityKey: aKey
> "Flush a security key"
> | n |
> n := aKey first.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
> n := aKey second.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
>
> How to fix that without breaking security measures or the underlying concept?
>
> Best,
> Marcel
>
>

Hi Marcel, hi Levente!

> For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

Am 25.03.2020 09:32:04 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel, hi Levente!

> For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

> 

> x := {1. 2. 3}.

> x at: 1 put: #foo.

> x "#(#foo 2 3) --- wrong print string!"

Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).

Also, the following example shows that brace nodes generate a new instance each time:

c := Object newSubclass.

c compile: 'foo ^ {1. 2. 3}'.

o := c new.

o foo at: 1 put: #foo.

o foo. "#(1 2 3)"

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 25. März 2020 09:19:01
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

 

Hi Levente, hi Christoph.

> I cannot reproduce this using a fresh Trunk image

I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)

> The main issue is that literal objects created by Compiler >> #evaluate:*  are now immutable but I think they shouldn't be. What do you think?

Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.

For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

x := {1. 2. 3}.

x at: 1 put: #foo.

x "#(#foo 2 3) --- wrong print string!"

y := #(1 2 3).

y at: 1 put: #foo. "ModificationForbidden"

Then, in the past, I have been complaining about the array cache in compiled methods:

someDefault

   ^ #(1 2 3)

In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?

***

In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?

> System-ul.1148 should work the issue around. Please let me know if it 

helped.

Not quite. I think have to manually clear the current keys in the SecurityManager first.

Best,

Marcel

Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <[hidden email]>:

Hi Marcel,

System-ul.1148 should work the issue around. Please let me know if it
helped.
The main issue is that literal objects created by Compiler >> #evaluate:*
are now immutable but I think they shouldn't be. What do you think?


Levente

On Tue, 24 Mar 2020, Marcel Taeumel wrote:

> Hi, there.
>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
>
> Boom! ModificationForbidden!
>
> Here is the interesting stack:
>
> Context>>modificationForbiddenFor:at:put:
> LargePositiveInteger(Object)>>basicAt:put:
> SecurityManager>>flushSecurityKey:
> SecurityManager>>flushSecurityKeys
> SecurityManager>>shutDown
> SecurityManager class>>shutDown
> SecurityManager class(Behavior)>>shutDown:
> [] in SmalltalkImage>>send:toClassesNamedIn:with:
> OrderedCollection>>do:
> SmalltalkImage>>send:toClassesNamedIn:with:
> SmalltalkImage>>processShutDownList:
>
> Well, that code tries to change a LargePositiveInteger:
>
> SecurityManager >> flushSecurityKey: aKey
> "Flush a security key"
> | n |
> n := aKey first.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
> n := aKey second.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
>
> How to fix that without breaking security measures or the underlying concept?
>
> Best,
> Marcel
>
>

On Mar 25, 2020, at 10:13 AM, Jakob Reschke <[hidden email]> wrote:

Marcel Taeumel <[hidden email]> schrieb am Mi., 25. März 2020, 09:36:

> Why do you think this is the wrong print string?

It happens easily to evaluate the printString again. If we now have ModificationForbidden, this can be quite confusing.

Same for #storeString:

{1. 2. 3} storeString         -> '#(1 2 3)'

Best,

Marcel

Am 25.03.2020 09:32:04 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel, hi Levente!

> For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

> 

> x := {1. 2. 3}.

> x at: 1 put: #foo.

> x "#(#foo 2 3) --- wrong print string!"

Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).

Also, the following example shows that brace nodes generate a new instance each time:

c := Object newSubclass.

c compile: 'foo ^ {1. 2. 3}'.

o := c new.

o foo at: 1 put: #foo.

o foo. "#(1 2 3)"

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 25. März 2020 09:19:01
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

 

Hi Levente, hi Christoph.

> I cannot reproduce this using a fresh Trunk image

I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)

> The main issue is that literal objects created by Compiler >> #evaluate:*  are now immutable but I think they shouldn't be. What do you think?

Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.

For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

x := {1. 2. 3}.

x at: 1 put: #foo.

x "#(#foo 2 3) --- wrong print string!"

y := #(1 2 3).

y at: 1 put: #foo. "ModificationForbidden"

Then, in the past, I have been complaining about the array cache in compiled methods:

someDefault

   ^ #(1 2 3)

In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?

***

In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?

> System-ul.1148 should work the issue around. Please let me know if it 

helped.

Not quite. I think have to manually clear the current keys in the SecurityManager first.

Best,

Marcel

Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <[hidden email]>:

Hi Marcel,

System-ul.1148 should work the issue around. Please let me know if it
helped.
The main issue is that literal objects created by Compiler >> #evaluate:*
are now immutable but I think they shouldn't be. What do you think?


Levente

On Tue, 24 Mar 2020, Marcel Taeumel wrote:

> Hi, there.
>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
>
> Boom! ModificationForbidden!
>
> Here is the interesting stack:
>
> Context>>modificationForbiddenFor:at:put:
> LargePositiveInteger(Object)>>basicAt:put:
> SecurityManager>>flushSecurityKey:
> SecurityManager>>flushSecurityKeys
> SecurityManager>>shutDown
> SecurityManager class>>shutDown
> SecurityManager class(Behavior)>>shutDown:
> [] in SmalltalkImage>>send:toClassesNamedIn:with:
> OrderedCollection>>do:
> SmalltalkImage>>send:toClassesNamedIn:with:
> SmalltalkImage>>processShutDownList:
>
> Well, that code tries to change a LargePositiveInteger:
>
> SecurityManager >> flushSecurityKey: aKey
> "Flush a security key"
> | n |
> n := aKey first.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
> n := aKey second.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
>
> How to fix that without breaking security measures or the underlying concept?
>
> Best,
> Marcel
>
>

Hm, it would be indeed very confusing it the same code worked in a workspace but not in a compiled method.

Would it be a trade-off if we changed Object >> #readFrom: to apply #asWriteable on the deserialized object?



If you write #(1 2 3) in an inspector on a variable and accept that value, does it now make the variable's value immutable?



Hm, it would be indeed very confusing it the same code worked in a workspace but not in a compiled method.

Would it be a trade-off if we changed Object >> #readFrom: to apply #asWriteable on the deserialized object?

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 25. März 2020 18:45:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

 

Hi Jakob,

On Mar 25, 2020, at 10:13 AM, Jakob Reschke <[hidden email]> wrote:



If you write #(1 2 3) in an inspector on a variable and accept that value, does it now make the variable's value immutable?

Read-only ;-) Potsdam were the people who wanted the language ui change from mutable/immutable to writable/read-only to reserve mutable/immutable for deep immutability for E-style concurrency :-)

Yes, it means it is marked as read-only.  Currently you can either write #(1 2 3) copy or #(1 2 3) beWritableObject.  But we could modify the Inspector’s accept action to preserve the state if the object is of the same class, etc.  I’m not necessarily in favor of such auto-magic; it can get tricky.  But I understand that this use case might turn out to be tedious.

I guess what we should be doing is collecting these “gotchers” for the HelpBrowser page on read-only literals that we’ll want to feature in the release.

And of course we’re early in the discussion Levente started about whether literals answered by doits should be read-only or not.  I said I thought they should be in the interests of consistency.  But in the interests of utility one might want them to be writable.  I think one wants large integers and floats to be read-only no matter what, right?  So we’re taking about literal arrays, byte arrays, and strings.  If so, it seems to me that the right place to do any modifications to make things writable is in the evaluators.  Perhaps we add an evaluateWritableResult: or add a writableResult: argument to the core evaluator api that would make array, byte array and string results writable iff the argument was true, the result was of the relevant class and it was a literal in the doit method.

Weird (or perhaps not) that I can’t remember this issue ever coming up in VisualWorks.  Anyone got a better recollection than me?

Marcel Taeumel <[hidden email]> schrieb am Mi., 25. März 2020, 09:36:

> Why do you think this is the wrong print string?

It happens easily to evaluate the printString again. If we now have ModificationForbidden, this can be quite confusing.

Same for #storeString:

{1. 2. 3} storeString         -> '#(1 2 3)'

Best,

Marcel

Am 25.03.2020 09:32:04 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel, hi Levente!

> For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

> 

> x := {1. 2. 3}.

> x at: 1 put: #foo.

> x "#(#foo 2 3) --- wrong print string!"

Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).

Also, the following example shows that brace nodes generate a new instance each time:

c := Object newSubclass.

c compile: 'foo ^ {1. 2. 3}'.

o := c new.

o foo at: 1 put: #foo.

o foo. "#(1 2 3)"

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 25. März 2020 09:19:01
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

 

Hi Levente, hi Christoph.

> I cannot reproduce this using a fresh Trunk image

I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)

> The main issue is that literal objects created by Compiler >> #evaluate:*  are now immutable but I think they shouldn't be. What do you think?

Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.

For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

x := {1. 2. 3}.

x at: 1 put: #foo.

x "#(#foo 2 3) --- wrong print string!"

y := #(1 2 3).

y at: 1 put: #foo. "ModificationForbidden"

Then, in the past, I have been complaining about the array cache in compiled methods:

someDefault

   ^ #(1 2 3)

In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?

***

In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?

> System-ul.1148 should work the issue around. Please let me know if it 

helped.

Not quite. I think have to manually clear the current keys in the SecurityManager first.

Best,

Marcel

Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <[hidden email]>:

Hi Marcel,

System-ul.1148 should work the issue around. Please let me know if it
helped.
The main issue is that literal objects created by Compiler >> #evaluate:*
are now immutable but I think they shouldn't be. What do you think?


Levente

On Tue, 24 Mar 2020, Marcel Taeumel wrote:

> Hi, there.
>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
>
> Boom! ModificationForbidden!
>
> Here is the interesting stack:
>
> Context>>modificationForbiddenFor:at:put:
> LargePositiveInteger(Object)>>basicAt:put:
> SecurityManager>>flushSecurityKey:
> SecurityManager>>flushSecurityKeys
> SecurityManager>>shutDown
> SecurityManager class>>shutDown
> SecurityManager class(Behavior)>>shutDown:
> [] in SmalltalkImage>>send:toClassesNamedIn:with:
> OrderedCollection>>do:
> SmalltalkImage>>send:toClassesNamedIn:with:
> SmalltalkImage>>processShutDownList:
>
> Well, that code tries to change a LargePositiveInteger:
>
> SecurityManager >> flushSecurityKey: aKey
> "Flush a security key"
> | n |
> n := aKey first.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
> n := aKey second.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
>
> How to fix that without breaking security measures or the underlying concept?
>
> Best,
> Marcel
>
>

Am 25.03.2020 20:52:14 schrieb Thiede, Christoph <[hidden email]>:

Hm, it would be indeed very confusing it the same code worked in a workspace but not in a compiled method.

Would it be a trade-off if we changed Object >> #readFrom: to apply #asWriteable on the deserialized object?

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 25. März 2020 18:45:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

 

Hi Jakob,

On Mar 25, 2020, at 10:13 AM, Jakob Reschke <[hidden email]> wrote:



If you write #(1 2 3) in an inspector on a variable and accept that value, does it now make the variable's value immutable?

Read-only ;-) Potsdam were the people who wanted the language ui change from mutable/immutable to writable/read-only to reserve mutable/immutable for deep immutability for E-style concurrency :-)

Yes, it means it is marked as read-only.  Currently you can either write #(1 2 3) copy or #(1 2 3) beWritableObject.  But we could modify the Inspector’s accept action to preserve the state if the object is of the same class, etc.  I’m not necessarily in favor of such auto-magic; it can get tricky.  But I understand that this use case might turn out to be tedious.

I guess what we should be doing is collecting these “gotchers” for the HelpBrowser page on read-only literals that we’ll want to feature in the release.

And of course we’re early in the discussion Levente started about whether literals answered by doits should be read-only or not.  I said I thought they should be in the interests of consistency.  But in the interests of utility one might want them to be writable.  I think one wants large integers and floats to be read-only no matter what, right?  So we’re taking about literal arrays, byte arrays, and strings.  If so, it seems to me that the right place to do any modifications to make things writable is in the evaluators.  Perhaps we add an evaluateWritableResult: or add a writableResult: argument to the core evaluator api that would make array, byte array and string results writable iff the argument was true, the result was of the relevant class and it was a literal in the doit method.

Weird (or perhaps not) that I can’t remember this issue ever coming up in VisualWorks.  Anyone got a better recollection than me?

Marcel Taeumel <[hidden email]> schrieb am Mi., 25. März 2020, 09:36:

> Why do you think this is the wrong print string?

It happens easily to evaluate the printString again. If we now have ModificationForbidden, this can be quite confusing.

Same for #storeString:

{1. 2. 3} storeString         -> '#(1 2 3)'

Best,

Marcel

Am 25.03.2020 09:32:04 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel, hi Levente!

> For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

> 

> x := {1. 2. 3}.

> x at: 1 put: #foo.

> x "#(#foo 2 3) --- wrong print string!"

Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).

Also, the following example shows that brace nodes generate a new instance each time:

c := Object newSubclass.

c compile: 'foo ^ {1. 2. 3}'.

o := c new.

o foo at: 1 put: #foo.

o foo. "#(1 2 3)"

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 25. März 2020 09:19:01
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

 

Hi Levente, hi Christoph.

> I cannot reproduce this using a fresh Trunk image

I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)

> The main issue is that literal objects created by Compiler >> #evaluate:*  are now immutable but I think they shouldn't be. What do you think?

Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.

For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

x := {1. 2. 3}.

x at: 1 put: #foo.

x "#(#foo 2 3) --- wrong print string!"

y := #(1 2 3).

y at: 1 put: #foo. "ModificationForbidden"

Then, in the past, I have been complaining about the array cache in compiled methods:

someDefault

   ^ #(1 2 3)

In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?

***

In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?

> System-ul.1148 should work the issue around. Please let me know if it 

helped.

Not quite. I think have to manually clear the current keys in the SecurityManager first.

Best,

Marcel

Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <[hidden email]>:

Hi Marcel,

System-ul.1148 should work the issue around. Please let me know if it
helped.
The main issue is that literal objects created by Compiler >> #evaluate:*
are now immutable but I think they shouldn't be. What do you think?


Levente

On Tue, 24 Mar 2020, Marcel Taeumel wrote:

> Hi, there.
>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
>
> Boom! ModificationForbidden!
>
> Here is the interesting stack:
>
> Context>>modificationForbiddenFor:at:put:
> LargePositiveInteger(Object)>>basicAt:put:
> SecurityManager>>flushSecurityKey:
> SecurityManager>>flushSecurityKeys
> SecurityManager>>shutDown
> SecurityManager class>>shutDown
> SecurityManager class(Behavior)>>shutDown:
> [] in SmalltalkImage>>send:toClassesNamedIn:with:
> OrderedCollection>>do:
> SmalltalkImage>>send:toClassesNamedIn:with:
> SmalltalkImage>>processShutDownList:
>
> Well, that code tries to change a LargePositiveInteger:
>
> SecurityManager >> flushSecurityKey: aKey
> "Flush a security key"
> | n |
> n := aKey first.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
> n := aKey second.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
>
> How to fix that without breaking security measures or the underlying concept?
>
> Best,
> Marcel
>
>