[squeak-dev] #clearCredentials vs. ModificationForbidden

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Jun 6 12:30:47 UTC 2020


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200606/eb19517c/attachment.html>


More information about the Squeak-dev mailing list