From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.bugs Subject: bug#28489: Acknowledgement (27.0.50; eieio-persistent slot type validation should be a bit smarter) Date: Sat, 14 Oct 2017 14:13:34 +0200 Message-ID: <87zi8u0vwx.fsf@ericabrahamsen.net> References: <87lglcn8dt.fsf@ericabrahamsen.net> <878th1i50l.fsf@ericabrahamsen.net> <87wp4lf1kq.fsf@users.sourceforge.net> <87ing4cd04.fsf@ericabrahamsen.net> <87h8vnftnx.fsf@users.sourceforge.net> <87zi9fxvnh.fsf@ericabrahamsen.net> <8760c2fike.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1507983382 16026 195.159.176.226 (14 Oct 2017 12:16:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 12:16:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) To: 28489-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 14 14:16:14 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3LML-00023u-4m for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Oct 2017 14:16:05 +0200 Original-Received: from localhost ([::1]:53906 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3LMS-0001xN-JK for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Oct 2017 08:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3LML-0001vv-Gp for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 08:16:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3LMI-00043N-Ps for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 08:16:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58477) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e3LMI-00043B-LO for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 08:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e3LMI-0003Ym-G5 for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2017 08:16:02 -0400 Resent-From: Eric Abrahamsen Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Oct 2017 12:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 28489 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 28489@debbugs.gnu.org, eric@ericabrahamsen.net, eric@ericabrahamsen.net Original-Received: via spool by 28489-done@debbugs.gnu.org id=D28489.150798331213613 (code D ref 28489); Sat, 14 Oct 2017 12:16:02 +0000 Original-Received: (at 28489-done) by debbugs.gnu.org; 14 Oct 2017 12:15:12 +0000 Original-Received: from localhost ([127.0.0.1]:38923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3LLU-0003XV-6b for submit@debbugs.gnu.org; Sat, 14 Oct 2017 08:15:12 -0400 Original-Received: from mail.ericabrahamsen.net ([50.56.99.223]:44578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3LLR-0003XM-5t for 28489-done@debbugs.gnu.org; Sat, 14 Oct 2017 08:15:10 -0400 Original-Received: from localhost (mda5036d0.tmodns.net [208.54.80.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 2E037BFD56 for <28489-done@debbugs.gnu.org>; Sat, 14 Oct 2017 12:15:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.ericabrahamsen.net; s=mail; t=1507983308; bh=7zRkKSJkexuyYFY3qLs6a8RQIoG8SN/xKTO4m0djTBw=; h=From:To:Subject:References:Date:In-Reply-To:From; b=dILjfU9ROjajRtXExksHW8AEVU4ghhHcu3GEH2F/NaDrrC0R++3mY5nqjbue4Duxr k06qEaQTjAmxwmWrc98wuondVT9AoNrKdRjac+Ze3zXgKQIA0fqy1mCUAyALz40ctZ X7ohBmT3S+CY20DmN2E0G3mpPTU/cTlmIIcaSsDA= In-Reply-To: Eric Abrahamsen's message of "\(unknown date\)" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138400 Archived-At: Eric Abrahamsen writes: > On 09/28/17 20:35 PM, Noam Postavsky wrote: >> Eric Abrahamsen writes: >> >>> Essentially it is validating twice, both before and after the actual >>> objects are created. I don't have a very firm grasp of all the code >>> involved, but in principle I would prefer just to eval all object >>> construction forms regardless, and then let it blow up at "real" >>> validation time -- it was going to blow up anyway. >> >> Hmm, yeah, it does look the prevalidation is mostly redundant work. The >> docstring of eieio-persistent-convert-list-to-object mentions malicious >> code, perhaps the prevalidation should be with unsafep (i.e., don't try >> to typecheck anything, just make sure it's safe to eval). This would >> require that object constructors could be marked safe though. > > I've never looked at `unsafep' and don't know what's involved in marking > object constructors as safe, but that certainly sounds like the right > solution. > > Object creation *ought to* be safe. First, properties are already > stripped from strings. Second, the only way a creation of an object > could have side effects is if someone overloaded `initialize-instance' > or `shared-initialize' and inserted random hard-drive-destroying code > there. But `eieio-persistent-read' can't do that by itself; it would > have to be run in conjunction with a separate malicious library. > > Otherwise, object creation really just involves making objects, > validating the data that > > Aga > >>> But again, my patch or something like it would be enough to get >>> everything working as advertised. >> >> Right. I think your patch is probably fine, though a few tests might a >> good idea too. > > Tests are an excellent idea. Why don't I fool with this patch a bit > longer, write some tests, and commit the smallest change possible. Then > open another bug report on the larger question of validation, and the > possibility of marking object constructors as safe.