Save as new image -> ModificationForbidden!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Save as new image -> ModificationForbidden!

marcel.taeumel
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


Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Torge Husfeldt
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



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

marcel.taeumel
Hi Torge.

Thanks. I know how to workaround that debugger in my image. I was asking for a general fix for Trunk.

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



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Christoph Thiede

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


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Dienstag, 24. März 2020 11:43:30
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!
 
Hi Torge.

Thanks. I know how to workaround that debugger in my image. I was asking for a general fix for Trunk.

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



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Levente Uzonyi
In reply to this post by marcel.taeumel
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

marcel.taeumel
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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Christoph Thiede

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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Eliot Miranda-2
In reply to this post by Levente Uzonyi
Hi Levente,


> On Mar 24, 2020, at 1:18 PM, Levente Uzonyi <[hidden email]> wrote:
>
> 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?

That’s a good question.  I think they have to be, to be consistent.  It’s not hard to write eg
     a := ‘foo’ copy
or
     a := #((1 2 3) (4 5 6)) deepCopy


We might add a query to Object which is something like isReferencedLiteral so one can check if a read-only object is referenced as a literal in code before one sends it beWritableObject when one wants to patch things up in the inspector or debugger.

>
>
> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

marcel.taeumel
In reply to this post by Christoph Thiede
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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Jakob Reschke-2
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?

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
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Eliot Miranda-2
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
>
>





Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Christoph Thiede

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
>
>





Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Eliot Miranda-2
In reply to this post by marcel.taeumel



On Mar 25, 2020, at 12:52 PM, Thiede, Christoph <[hidden email]> wrote:



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?


Yes, I suggested this in response to Levente’s commit of System-ul.1148.  It might need to be smart.  For example, if the deserialized object referred to a literal deep within its structure, that literal shouldn’t be changed.  So it might me that the right way to implement this is indeed to change evaluation within readFrom: a it only makes literals within the doit(s) created writable.


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
>
>






Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Eliot Miranda-2
Hi Christoph,

On Wed, Mar 25, 2020 at 7:12 PM Eliot Miranda <[hidden email]> wrote:
On Mar 25, 2020, at 12:52 PM, Thiede, Christoph <[hidden email]> wrote:

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?


Yes, I suggested this in response to Levente’s commit of System-ul.1148.  It might need to be smart.  For example, if the deserialized object referred to a literal deep within its structure, that literal shouldn’t be changed.  So it might me that the right way to implement this is indeed to change evaluation within readFrom: a it only makes literals within the doit(s) created writable.

See if this makes sense in Inbox; Compiler-eem.421 and Kernel-eem.1320 in Inbox and see if you like the approach.

Name: Compiler-eem.421
Author: eem
Time: 25 March 2020, 9:00:37.328826 pm
UUID: 7bacb14a-f088-4fca-aa94-35dae28aa8e8
Ancestors: Compiler-nice.420

A suggested implementation of writable results from doits.  This scheme is careful to only make read-only collection literals that the compiler makes read-only, not e.g. numeric literals (which should always be read-only) or objects the evaluation makes read-only.

Name: Kernel-eem.1320
Author: eem
Time: 25 March 2020, 9:01:48.950717 pm
UUID: 5e03652f-dca4-40fb-991e-ec71a89bb282
Ancestors: Kernel-eem.1319

Use Compiler-eem.421 to make Object class>>readFrom: answer writable collection literals. 


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
>
>






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

marcel.taeumel
In reply to this post by Christoph Thiede
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 :-)

Yay! ^___^

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
>
>





Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Tobias Pape

> On 26.03.2020, at 09:54, Marcel Taeumel <[hidden email]> wrote:
>
> > 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 :-)

Stay tuned…
-t



Reply | Threaded
Open this post in threaded view
|

Re: Save as new image -> ModificationForbidden!

Eliot Miranda-2


> On Mar 26, 2020, at 2:00 AM, Tobias Pape <[hidden email]> wrote:
>
> 
>>> On 26.03.2020, at 09:54, Marcel Taeumel <[hidden email]> wrote:
>>>
>>> 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 :-)
>
> Stay tuned…

<3

> -t
>
>
>