[squeak-dev] #clearCredentials vs. ModificationForbidden

Jakob Reschke forums.jakob at resfarm.de
Sat Jun 6 13:22:27 UTC 2020


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
<Christoph.Thiede at student.hpi.uni-potsdam.de>:
>
> 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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de>
> 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 <marcel.taeumel at hpi.de> 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 <forums.jakob at resfarm.de>:
> >>
> >> 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
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >
>
>
>
>


More information about the Squeak-dev mailing list