Dumitru =?UTF-8?B?TWnImXU=?= Moldovan <dumol@l10n.ro> wrote:
> --Sig_/DxkmnOd5LCv/.ZhViW3AEIH
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Klemens Nanni <kn@openbsd.org> wrote:
>
> > On Sat, Jun 02, 2018 at 03:25:59PM +0200, Theo Buehler wrote:
> > > I'm too stupid to get a usable full backtrace out of this crash.
> > LDFLAGS in config.mk has `-s'. I already patched it out and contacted
> > upstream. So even with DEBUG set, the binary is stripped while linking
> > already, which is stupid.
> >
> > > I get it with a clean profile on both firefox and iridium when
> > > visiting sylwetka.com.pl. Here's the useful bit:
> > >
> > > #0 _thread_sys_open () at -:3
> > > #1 0x00000f57a7383a3c in _libc_open_cancel (path=0xf57d2658b60
> > > "/usr/X11R6/lib/X11/fonts/TTF/DejaVuSans.ttf", flags=<optimized
> > > out>) at /usr/src/lib/libc/sys/w_open.c:36 #2 0x00000f5821c6eeaa
> > > out>in FT_Stream_Open () from /usr/X11R6/lib/libfreetype.so.29.0
> > > #3 0x00000f5821c10669 in FT_Stream_New ()
> > > from /usr/X11R6/lib/libfreetype.so.29.0 #4 0x00000f5821c1159b in
> > > ft_open_face_internal () from /usr/X11R6/lib/libfreetype.so.29.0
> > > #5 0x00000f5821c114ea in FT_New_Face ()
> > > from /usr/X11R6/lib/libfreetype.so.29.0 #6 0x00000f576263a013 in
> > > _XftLockFile () from /usr/X11R6/lib/libXft.so.11.0 #7
> > > 0x00000f576263ab76 in XftFontOpenInfo ()
> > > from /usr/X11R6/lib/libXft.so.11.0 #8 0x00000f576263b209 in
> > > XftFontOpenPattern () from /usr/X11R6/lib/libXft.so.11.0
> > Missing bits:
> >
> > #9 0x00000a9812b018e3 in drw_font_xcreate (drw=<optimized out>,
> > fontpattern=0xa9a4ae068a0, fontname=<optimized out>) at drw.c:131
> > #10 drw_text (drw=<optimized out>, x=196, y=<optimized out>,
> > w=<optimized out>, h=<optimized out>, text=0xa9ab0686e12 "?????Masa?? i
> > Rehabilitacja Warszawa - Salon rehabilitacji Sylwetka - Iridium",
> > invert=0) at drw.c:337 #11 0x00000a9812b04158 in drawbar
> > (m=0xa9a6f0d9000) at dwm.c:746 #12 0x00000a9812b0723a in
> > propertynotify (e=0x7f7ffffbf4d0) at dwm.c:1258 #13
> > 0x00000a9812b0252d in run () at dwm.c:1397 #14 main (argc=<optimized
> > out>, argv=<optimized out>) at dwm.c:2139
> >
>
> OK, I think I can explain this from the given info??? Conditions:
>
> 1. dwm uses a font for the title bar that lacks a glyph for ??
> 2. browser loads this site which has ?? in the title
> 3. browser changes window title to one that has ??
> 4. dwm wants to render ?? through the underneath libraries
> (FreeType/fontconfig?), but current font doesn't have a glyph for it
> 5. underneath library tries to load another font from disk, one
> that has ??, to render this one missing glyph for dwm.
>
> Very interesting case, indeed! It actually works closely to what the
> user described initially, except uBlock origin is not a factor here,
> from what I can gather.
Nothing surprising here.
If the code has not been verified to restrict itself to the promises it
makes to pledge, then it should not be using pledge.
In base, the programs were simpler and we were able to perform a static
analysis of entire programs, and refactor their operation when needed.
We did that BEFORE making promises about how they work.
But in ports? Seriously, come on. I'm coming to the conclusion that
the ports community is over-optimistic, or don't care about throwing
crashes at their userbase. Yes, it is good to make code more secure,
but a pledge crash of a program doesn't blame the program. It blames
the person who took the shortcut.
No comments:
Post a Comment