[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28489: Acknowledgement (27.0.50; eieio-persistent slot type validati

From: Eric Abrahamsen
Subject: bug#28489: Acknowledgement (27.0.50; eieio-persistent slot type validation should be a bit smarter)
Date: Sat, 30 Sep 2017 11:05:44 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

Noam Postavsky <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>> That sounds like the right solution. I've never looked at
>> unsafep.el, and don't know exactly how it works,
> Basically, there is a whitelist: symbols which have the property `safe',
> are ok, stuff like progn is okay if all the things inside are also
> `safe'.  So if we can be sure an object constructor does nothing but
> create an object then it could be marked safe.
>> 3. Object creation could run malicious code *if* someone had overridden
>>    `initialize-instance' or `shared-initialize',
> Hmm, it might be a difficult to be confident that calling some generic
> function is safe.

It would indeed be complicated -- you'd have to locate all
currently-defined methods for those two generics, then run through them
and make sure everything in them was safe. I suppose it would be
possible, but pretty annoying.

I still think it would be worth bringing `eieio-skip-typecheck' into
play. I'm probably the only person in the world who cares about the
performance of eieio-persistent-read, but it wouldn't hurt!

>> I might as well write tests that exercise the whole eieio-persistent
>> round-trip: create a few test objects, write them to a tmp file, and
>> read them back as objects.
> Sounds good.

Here's the commit as it stands, seems to work fine. I'll let it mellow
for a while, and then commit to... emacs-26? Since it's technically a
bug fix?

Attachment: 0001-Fix-slot-typecheck-in-eieio-persistent.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]