#clearCredentials vs. ModificationForbidden

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

#clearCredentials vs. ModificationForbidden

marcel.taeumel
Hi all!

How to update MCHttpRepository >> #clearCredentials?

clearCredentials
user ifNotNil: [user atAllPut: $x].
password ifNotNil: [password atAllPut: $x].
user := password := String empty

Make those strings not be read-only?

Best,
Marcel


Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Jakob Reschke
Use becomeForward: and collect garbage?

Marcel Taeumel <[hidden email]> schrieb am Fr., 5. Juni 2020, 16:27:
Hi all!

How to update MCHttpRepository >> #clearCredentials?

clearCredentials
user ifNotNil: [user atAllPut: $x].
password ifNotNil: [password atAllPut: $x].
user := password := String empty

Make those strings not be read-only?

Best,
Marcel



Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Christoph Thiede

Use becomeForward: and collect garbage?


Afaik you cannot forward a read-only object?


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Freitag, 5. Juni 2020 17:53:30
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
 
Use becomeForward: and collect garbage?

Marcel Taeumel <[hidden email]> schrieb am Fr., 5. Juni 2020, 16:27:
Hi all!

How to update MCHttpRepository >> #clearCredentials?

clearCredentials
user ifNotNil: [user atAllPut: $x].
password ifNotNil: [password atAllPut: $x].
user := password := String empty

Make those strings not be read-only?

Best,
Marcel



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Jakob Reschke
With copyHash: false, I hope you can. It should not touch the original
object, which is to be discarded anyway.

Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
<[hidden email]>:

>
> > Use becomeForward: and collect garbage?
>
>
> Afaik you cannot forward a read-only object?
>
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
> Gesendet: Freitag, 5. Juni 2020 17:53:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>
> Use becomeForward: and collect garbage?
>
> Marcel Taeumel <[hidden email]> schrieb am Fr., 5. Juni 2020, 16:27:
>>
>> Hi all!
>>
>> How to update MCHttpRepository >> #clearCredentials?
>>
>> clearCredentials
>> user ifNotNil: [user atAllPut: $x].
>> password ifNotNil: [password atAllPut: $x].
>> user := password := String empty
>>
>> Make those strings not be read-only?
>>
>> Best,
>> Marcel
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Christoph Thiede

This does not work for me:


x := 'x'.
x beReadOnlyObject.
y := ''.
x becomeForward: y copyHash: false.

Still raises a ModificationForbidden.


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Freitag, 5. Juni 2020 19:31:30
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
 
With copyHash: false, I hope you can. It should not touch the original
object, which is to be discarded anyway.

Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
<[hidden email]>:
>
> > Use becomeForward: and collect garbage?
>
>
> Afaik you cannot forward a read-only object?
>
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
> Gesendet: Freitag, 5. Juni 2020 17:53:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>
> Use becomeForward: and collect garbage?
>
> Marcel Taeumel <[hidden email]> schrieb am Fr., 5. Juni 2020, 16:27:
>>
>> Hi all!
>>
>> How to update MCHttpRepository >> #clearCredentials?
>>
>> clearCredentials
>> user ifNotNil: [user atAllPut: $x].
>> password ifNotNil: [password atAllPut: $x].
>> user := password := String empty
>>
>> Make those strings not be read-only?
>>
>> Best,
>> Marcel
>>
>



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Jakob Reschke
Hmm so I was obviously wrong. I understand why, if I think what
happens to a method's string literal if you becomeForward: it... And
actually since Spur this would really write something to the object's
memory space, despite my assumption.

So why are these immutable? Because you specify a repository with an
evaluable constructor snippet, which has the credentials as string
literals, correct? Can't we just copy these arguments in the
constructors/setters, to make them "owned" and mutable?

Am Fr., 5. Juni 2020 um 19:36 Uhr schrieb Thiede, Christoph
<[hidden email]>:

>
> This does not work for me:
>
>
> x := 'x'.
> x beReadOnlyObject.
> y := ''.
> x becomeForward: y copyHash: false.
>
> Still raises a ModificationForbidden.
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
> Gesendet: Freitag, 5. Juni 2020 19:31:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>
> With copyHash: false, I hope you can. It should not touch the original
> object, which is to be discarded anyway.
>
> Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
> <[hidden email]>:
> >
> > > Use becomeForward: and collect garbage?
> >
> >
> > Afaik you cannot forward a read-only object?
> >
> > ________________________________
> > Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
> > Gesendet: Freitag, 5. Juni 2020 17:53:30
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
> >
> > Use becomeForward: and collect garbage?
> >
> > Marcel Taeumel <[hidden email]> schrieb am Fr., 5. Juni 2020, 16:27:
> >>
> >> Hi all!
> >>
> >> How to update MCHttpRepository >> #clearCredentials?
> >>
> >> clearCredentials
> >> user ifNotNil: [user atAllPut: $x].
> >> password ifNotNil: [password atAllPut: $x].
> >> user := password := String empty
> >>
> >> Make those strings not be read-only?
> >>
> >> Best,
> >> Marcel
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

marcel.taeumel
Collection >> #wipeAllFromMemory would be nice to have. :-D Could be a combination of atAllPut: and #removeAll. And deal with ModificationForbidden.

Best,
Marcel

Am 05.06.2020 21:11:30 schrieb Jakob Reschke <[hidden email]>:

Hmm so I was obviously wrong. I understand why, if I think what
happens to a method's string literal if you becomeForward: it... And
actually since Spur this would really write something to the object's
memory space, despite my assumption.

So why are these immutable? Because you specify a repository with an
evaluable constructor snippet, which has the credentials as string
literals, correct? Can't we just copy these arguments in the
constructors/setters, to make them "owned" and mutable?

Am Fr., 5. Juni 2020 um 19:36 Uhr schrieb Thiede, Christoph
:
>
> This does not work for me:
>
>
> x := 'x'.
> x beReadOnlyObject.
> y := ''.
> x becomeForward: y copyHash: false.
>
> Still raises a ModificationForbidden.
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev im Auftrag von Jakob Reschke
> Gesendet: Freitag, 5. Juni 2020 19:31:30
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>
> With copyHash: false, I hope you can. It should not touch the original
> object, which is to be discarded anyway.
>
> Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
> :
> >
> > > Use becomeForward: and collect garbage?
> >
> >
> > Afaik you cannot forward a read-only object?
> >
> > ________________________________
> > Von: Squeak-dev im Auftrag von Jakob Reschke
> > Gesendet: Freitag, 5. Juni 2020 17:53:30
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
> >
> > Use becomeForward: and collect garbage?
> >
> > Marcel Taeumel schrieb am Fr., 5. Juni 2020, 16:27:
> >>
> >> Hi all!
> >>
> >> How to update MCHttpRepository >> #clearCredentials?
> >>
> >> clearCredentials
> >> user ifNotNil: [user atAllPut: $x].
> >> password ifNotNil: [password atAllPut: $x].
> >> user := password := String empty
> >>
> >> Make those strings not be read-only?
> >>
> >> Best,
> >> Marcel
> >>
> >
>
>



Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Tobias Pape
> On 06.06.2020, at 08:01, Marcel Taeumel <[hidden email]> wrote:
>
> Collection >> #wipeAllFromMemory would be nice to have. :-D Could be a combination of atAllPut: and #removeAll. And deal with ModificationForbidden.
>

I think this is hard to do in a general case (think Intervals?) and is a bit mushy between system-level programming and breaking object-oriented encapsulation.

A dedicated, wipeable Password-safe storage would be better. Thinking of it, we could go a step further and give it an interface such that the clear text of a password is passed on only in minimal contexts to fool memory snooping.

Best regards
        -Tobias


> Best,
> Marcel
>> Am 05.06.2020 21:11:30 schrieb Jakob Reschke <[hidden email]>:
>>
>> Hmm so I was obviously wrong. I understand why, if I think what
>> happens to a method's string literal if you becomeForward: it... And
>> actually since Spur this would really write something to the object's
>> memory space, despite my assumption.
>>
>> So why are these immutable? Because you specify a repository with an
>> evaluable constructor snippet, which has the credentials as string
>> literals, correct? Can't we just copy these arguments in the
>> constructors/setters, to make them "owned" and mutable?
>>
>> Am Fr., 5. Juni 2020 um 19:36 Uhr schrieb Thiede, Christoph
>> :
>> >
>> > This does not work for me:
>> >
>> >
>> > x := 'x'.
>> > x beReadOnlyObject.
>> > y := ''.
>> > x becomeForward: y copyHash: false.
>> >
>> > Still raises a ModificationForbidden.
>> >
>> >
>> > Best,
>> >
>> > Christoph
>> >
>> > ________________________________
>> > Von: Squeak-dev im Auftrag von Jakob Reschke
>> > Gesendet: Freitag, 5. Juni 2020 19:31:30
>> > An: The general-purpose Squeak developers list
>> > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>> >
>> > With copyHash: false, I hope you can. It should not touch the original
>> > object, which is to be discarded anyway.
>> >
>> > Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
>> > :
>> > >
>> > > > Use becomeForward: and collect garbage?
>> > >
>> > >
>> > > Afaik you cannot forward a read-only object?
>> > >
>> > > ________________________________
>> > > Von: Squeak-dev im Auftrag von Jakob Reschke
>> > > Gesendet: Freitag, 5. Juni 2020 17:53:30
>> > > An: The general-purpose Squeak developers list
>> > > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>> > >
>> > > Use becomeForward: and collect garbage?
>> > >
>> > > Marcel Taeumel schrieb am Fr., 5. Juni 2020, 16:27:
>> > >>
>> > >> Hi all!
>> > >>
>> > >> How to update MCHttpRepository >> #clearCredentials?
>> > >>
>> > >> clearCredentials
>> > >> user ifNotNil: [user atAllPut: $x].
>> > >> password ifNotNil: [password atAllPut: $x].
>> > >> user := password := String empty
>> > >>
>> > >> Make those strings not be read-only?
>> > >>
>> > >> Best,
>> > >> Marcel
>> > >>
>> > >
>> >
>> >
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Christoph Thiede

How would you design such a password safe? Wouldn't this be to be implemented on VM side to make sure no one unauthorized can access it, e. g. via mirror primitive?


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Samstag, 6. Juni 2020 10:47:28
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
 
> On 06.06.2020, at 08:01, Marcel Taeumel <[hidden email]> wrote:
>
> Collection >> #wipeAllFromMemory would be nice to have. :-D Could be a combination of atAllPut: and #removeAll. And deal with ModificationForbidden.
>

I think this is hard to do in a general case (think Intervals?) and is a bit mushy between system-level programming and breaking object-oriented encapsulation.

A dedicated, wipeable Password-safe storage would be better. Thinking of it, we could go a step further and give it an interface such that the clear text of a password is passed on only in minimal contexts to fool memory snooping.

Best regards
        -Tobias


> Best,
> Marcel
>> Am 05.06.2020 21:11:30 schrieb Jakob Reschke <[hidden email]>:
>>
>> Hmm so I was obviously wrong. I understand why, if I think what
>> happens to a method's string literal if you becomeForward: it... And
>> actually since Spur this would really write something to the object's
>> memory space, despite my assumption.
>>
>> So why are these immutable? Because you specify a repository with an
>> evaluable constructor snippet, which has the credentials as string
>> literals, correct? Can't we just copy these arguments in the
>> constructors/setters, to make them "owned" and mutable?
>>
>> Am Fr., 5. Juni 2020 um 19:36 Uhr schrieb Thiede, Christoph
>> :
>> >
>> > This does not work for me:
>> >
>> >
>> > x := 'x'.
>> > x beReadOnlyObject.
>> > y := ''.
>> > x becomeForward: y copyHash: false.
>> >
>> > Still raises a ModificationForbidden.
>> >
>> >
>> > Best,
>> >
>> > Christoph
>> >
>> > ________________________________
>> > Von: Squeak-dev im Auftrag von Jakob Reschke
>> > Gesendet: Freitag, 5. Juni 2020 19:31:30
>> > An: The general-purpose Squeak developers list
>> > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>> >
>> > With copyHash: false, I hope you can. It should not touch the original
>> > object, which is to be discarded anyway.
>> >
>> > Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
>> > :
>> > >
>> > > > Use becomeForward: and collect garbage?
>> > >
>> > >
>> > > Afaik you cannot forward a read-only object?
>> > >
>> > > ________________________________
>> > > Von: Squeak-dev im Auftrag von Jakob Reschke
>> > > Gesendet: Freitag, 5. Juni 2020 17:53:30
>> > > An: The general-purpose Squeak developers list
>> > > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>> > >
>> > > Use becomeForward: and collect garbage?
>> > >
>> > > Marcel Taeumel schrieb am Fr., 5. Juni 2020, 16:27:
>> > >>
>> > >> Hi all!
>> > >>
>> > >> How to update MCHttpRepository >> #clearCredentials?
>> > >>
>> > >> clearCredentials
>> > >> user ifNotNil: [user atAllPut: $x].
>> > >> password ifNotNil: [password atAllPut: $x].
>> > >> user := password := String empty
>> > >>
>> > >> Make those strings not be read-only?
>> > >>
>> > >> Best,
>> > >> Marcel
>> > >>
>> > >
>> >
>> >
>>
>





Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Jakob Reschke
Take into consideration that there is already a Password class in
Network-Kernel.

Am Sa., 6. Juni 2020 um 14:31 Uhr schrieb Thiede, Christoph
<[hidden email]>:

>
> How would you design such a password safe? Wouldn't this be to be implemented on VM side to make sure no one unauthorized can access it, e. g. via mirror primitive?
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
> Gesendet: Samstag, 6. Juni 2020 10:47:28
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
>
> > On 06.06.2020, at 08:01, Marcel Taeumel <[hidden email]> wrote:
> >
> > Collection >> #wipeAllFromMemory would be nice to have. :-D Could be a combination of atAllPut: and #removeAll. And deal with ModificationForbidden.
> >
>
> I think this is hard to do in a general case (think Intervals?) and is a bit mushy between system-level programming and breaking object-oriented encapsulation.
>
> A dedicated, wipeable Password-safe storage would be better. Thinking of it, we could go a step further and give it an interface such that the clear text of a password is passed on only in minimal contexts to fool memory snooping.
>
> Best regards
>         -Tobias
>
>
> > Best,
> > Marcel
> >> Am 05.06.2020 21:11:30 schrieb Jakob Reschke <[hidden email]>:
> >>
> >> Hmm so I was obviously wrong. I understand why, if I think what
> >> happens to a method's string literal if you becomeForward: it... And
> >> actually since Spur this would really write something to the object's
> >> memory space, despite my assumption.
> >>
> >> So why are these immutable? Because you specify a repository with an
> >> evaluable constructor snippet, which has the credentials as string
> >> literals, correct? Can't we just copy these arguments in the
> >> constructors/setters, to make them "owned" and mutable?
> >>
> >> Am Fr., 5. Juni 2020 um 19:36 Uhr schrieb Thiede, Christoph
> >> :
> >> >
> >> > This does not work for me:
> >> >
> >> >
> >> > x := 'x'.
> >> > x beReadOnlyObject.
> >> > y := ''.
> >> > x becomeForward: y copyHash: false.
> >> >
> >> > Still raises a ModificationForbidden.
> >> >
> >> >
> >> > Best,
> >> >
> >> > Christoph
> >> >
> >> > ________________________________
> >> > Von: Squeak-dev im Auftrag von Jakob Reschke
> >> > Gesendet: Freitag, 5. Juni 2020 19:31:30
> >> > An: The general-purpose Squeak developers list
> >> > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
> >> >
> >> > With copyHash: false, I hope you can. It should not touch the original
> >> > object, which is to be discarded anyway.
> >> >
> >> > Am Fr., 5. Juni 2020 um 19:24 Uhr schrieb Thiede, Christoph
> >> > :
> >> > >
> >> > > > Use becomeForward: and collect garbage?
> >> > >
> >> > >
> >> > > Afaik you cannot forward a read-only object?
> >> > >
> >> > > ________________________________
> >> > > Von: Squeak-dev im Auftrag von Jakob Reschke
> >> > > Gesendet: Freitag, 5. Juni 2020 17:53:30
> >> > > An: The general-purpose Squeak developers list
> >> > > Betreff: Re: [squeak-dev] #clearCredentials vs. ModificationForbidden
> >> > >
> >> > > Use becomeForward: and collect garbage?
> >> > >
> >> > > Marcel Taeumel schrieb am Fr., 5. Juni 2020, 16:27:
> >> > >>
> >> > >> Hi all!
> >> > >>
> >> > >> How to update MCHttpRepository >> #clearCredentials?
> >> > >>
> >> > >> clearCredentials
> >> > >> user ifNotNil: [user atAllPut: $x].
> >> > >> password ifNotNil: [password atAllPut: $x].
> >> > >> user := password := String empty
> >> > >>
> >> > >> Make those strings not be read-only?
> >> > >>
> >> > >> Best,
> >> > >> Marcel
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Chris Muller-3
In reply to this post by marcel.taeumel
Hi Marcel,

We should remove MCHttpRepository>>'user' and 'password' instVars entirely, and simply stick with #userAndPasswordFromSettingsDo:.

When they select 'edit repository info' function of the Repository menu, it should update the prefs file.

We should not store id's and passwords in the image.

Best,
  Chris

On Fri, Jun 5, 2020 at 9:27 AM Marcel Taeumel <[hidden email]> wrote:
Hi all!

How to update MCHttpRepository >> #clearCredentials?

clearCredentials
user ifNotNil: [user atAllPut: $x].
password ifNotNil: [password atAllPut: $x].
user := password := String empty

Make those strings not be read-only?

Best,
Marcel



Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

marcel.taeumel
Hi Chris,

this reads like the central password-safe storage Tobias proposed earlier in this thread. That storage can be in the file system anyway or use a dedicated interface to the VM to wipe its contents from the object space. I would rather not hard-code it to always rely on file-system access though. :-) Squeak runs without even having access to .changes file.

Best,
Marcel

Am 10.06.2020 03:26:40 schrieb Chris Muller <[hidden email]>:

Hi Marcel,

We should remove MCHttpRepository>>'user' and 'password' instVars entirely, and simply stick with #userAndPasswordFromSettingsDo:.

When they select 'edit repository info' function of the Repository menu, it should update the prefs file.

We should not store id's and passwords in the image.

Best,
  Chris

On Fri, Jun 5, 2020 at 9:27 AM Marcel Taeumel <[hidden email]> wrote:
Hi all!

How to update MCHttpRepository >> #clearCredentials?

clearCredentials
user ifNotNil: [user atAllPut: $x].
password ifNotNil: [password atAllPut: $x].
user := password := String empty

Make those strings not be read-only?

Best,
Marcel



Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

Chris Muller-3
Hi Marcel,

this reads like the central password-safe storage Tobias proposed earlier in this thread. 

Okay, but #userAndPasswordFromSettingsDo: exists and works now.  There's an opportunity to improve the system by mere deletion.
 
That storage can be in the file system anyway or use a dedicated interface to the VM to wipe its contents from the object space.

Except we're not wiping the contents on image save, so everyone's passwords are being left in dozens of images.  People reuse sensitive passwords.  We should care about that.
 
I would rather not hard-code it to always rely on file-system access though. :-) Squeak runs without even having access to .changes file.

For this, please prioritize for security first.  Monticello doesn't run without the filesystem.  We have an easy opportunity to better safeguard private user data, is there something else that's rubbing you wrong about this idea?

Best,
  Chris


Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

marcel.taeumel
Hi Chris.

There's an opportunity to improve the system by mere deletion.

Well ... Monticello needs file-system access anyway for the package-cache. So, I think you are right. :-)

Best,
Marcel

Am 11.06.2020 03:22:00 schrieb Chris Muller <[hidden email]>:

Hi Marcel,

this reads like the central password-safe storage Tobias proposed earlier in this thread. 

Okay, but #userAndPasswordFromSettingsDo: exists and works now.  There's an opportunity to improve the system by mere deletion.
 
That storage can be in the file system anyway or use a dedicated interface to the VM to wipe its contents from the object space.

Except we're not wiping the contents on image save, so everyone's passwords are being left in dozens of images.  People reuse sensitive passwords.  We should care about that.
 
I would rather not hard-code it to always rely on file-system access though. :-) Squeak runs without even having access to .changes file.

For this, please prioritize for security first.  Monticello doesn't run without the filesystem.  We have an easy opportunity to better safeguard private user data, is there something else that's rubbing you wrong about this idea?

Best,
  Chris


Reply | Threaded
Open this post in threaded view
|

Re: #clearCredentials vs. ModificationForbidden

timrowledge
>
> > There's an opportunity to improve the system by mere deletion.

Delete those meres!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
..... REALITY.SYS Corrupted - Unable to recover Universe