bug#28350: enriched.el code execution

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 09 Sep 2017 17:57:10 +0200
> From: charles@aurox.ch (Charles A. Roelli)
> CC: 28350@debbugs.gnu.org
> 
> > > +See Info node `(elisp)Display Property' for the use of these
> > > +display specifications."
> > > +  (ignore-errors
> > > +    (or (stringp prop)
> >             ^^^^^^^^^^^^
> > What about an image spec (including a slice spec)?
> 
> Okay, I see that image specs can be safe.  But are they all safe?

I think they are.  Does anyone know different?

> And I don't understand how a slice spec is used together with an image
> spec.  Is the slice spec used inside of IMAGE-PROPS, i.e. as you might
> gather from the manual:
> 
> ‘(image . IMAGE-PROPS)’
>      This kind of display specification is an image descriptor (*note
>      Images).  When used as a display specification, it means to
>      display the image instead of the text that has the display
>      specification.
> 
> ‘(slice X Y WIDTH HEIGHT)’
>      This specification together with ‘image’ specifies a “slice” (a
>      partial area) of the image to display. 
> 
> ?

AFAIU, like this:

  ((slice X Y WIDTH HEIGHT) (image . IMAGE-PROPS))

You can see examples of this in image.el and image-mode.el.

> At this point it seems that unsafe display specs are more the
> exception than the rule, so it might make sense to define the
> `enriched-display-prop-safe-p' function by excluding the unsafe
> specifications instead of including the safe ones.  What do you
> think?

I'm not sure.  The display spec can be complex, so to make sure none
of these exceptions sneak through, you will have to recursively unpack
the spec data structure and examine each of the elements, which smells
too similar to emulating 'eval'.  No?

Thanks.