[openbox] Feh Borderless - Anyone Achieved This In Openbox?

Brian Mattern rephorm at rephorm.com
Mon Jul 29 00:03:48 EDT 2013


The attached patch is the same as the prior, but also includes
initialization of the mwmhints struct, so that no random bits get passed
on to the xserver.

This is the current state of the pull request on github to fix this bug.

Brian


On Sun, 28 Jul 2013, Das wrote:

> Thanks Guns that worked!
> 
> Oh boy I let open a can of worms, LOL...
> 
> So we have a Feh bug do we? If so PLEASE report this also to his Github
> with patch solution! :)
> 
> So the last patch Brian put up; feh-mwmhints2.patch, this is the correct
> solution?
> 
> Thanks...
> 
> On Sun, Jul 28, 2013 at 10:23 AM, Jim Rees <rees at umich.edu> wrote:
> 
> > Brian Mattern wrote:
> >
> >   On Sun, 28 Jul 2013, Jim Rees wrote:
> >
> >   > Brian Mattern wrote:
> >   >
> >   >   The correct fix is attached. On 64-bit machines, X apparently means
> >   >   "long" when it says "32", and NOT 32 bits. So, it actually expects 40
> >   >   bytes of data to be passed.
> >   >
> >   > That doesn't make sense. Openbox has its own definition of mwmhints,
> > and the
> >   > elements are declared as guint, which is an unsigned int. I wonder if
> >   > openbox is doing the right thing.
> >
> >   The manpage for XChangeProperty states:
> >
> >     If the specified format is 8, the property data must be a char array.
> >     If the specified format is 16, the property data must be a short array.
> >     If the specified format is 32, the property data must be a long array.
> >
> >   It may be unintuitive and perhaps a bit silly, but it is what it is.
> >
> >   You can also look at get_all() in openbox/obt/prop.c, which casts the
> >   data to gulong and then copies the value into a guint32.
> >   (get_all() gets called by OBT_PROP_GETA32() in client_get_mwm_hints() in
> >   openbox/openbox/client.c)
> >
> > Ah, that makes sense. A bit silly as you say. Thanks.
> >
> >   >
> >   > Also I'd be much happier if you left the memset in.
> >
> >   The code is correct either way, so I'm ambivalent. But, I'll add it in
> >   for good form.
> >
> > The issue is that it leaks info from whatever is on the stack. Probably not
> > a big deal in this case, but the kind of thing that leads to security
> > problems.
> > _______________________________________________
> > openbox mailing list
> > openbox at icculus.org
> > http://icculus.org/mailman/listinfo/openbox
> >

> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox

-------------- next part --------------
A non-text attachment was scrubbed...
Name: feh-mwmhints3.patch
Type: text/x-diff
Size: 1298 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20130728/d49fa290/attachment.patch>


More information about the openbox mailing list