Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] devel-xorg-modular security fixes

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Javier Vasquez <j.e.vasquez.v AT gmail.com>
  • To: "sm, discuss" <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] devel-xorg-modular security fixes
  • Date: Sat, 14 Dec 2013 13:03:04 -0600

On Tue, Dec 3, 2013 at 8:36 AM, Sukneet Basuta <sukneet AT gmail.com> wrote:
> On 02/12/13 01:57 AM, Javier Vasquez wrote:
>> On Sat, Nov 9, 2013 at 11:41 AM, Remko van der Vossen <wich AT yuugen.jp>
>> wrote:
>>> On 2013/11/09, at 5:29, Sukneet Basuta <sukneet AT gmail.com> wrote:
>>>> I haven't had the the time to work on this in over 2 months, so I'm
>>>> giving up on it. I've attached a git patch that adds a bunch of spells
>>>> to libpthread-stubs' UP_TRIGGERS that should get a working system at
>>>> least. However, the problem is that I can't get the spells to cast in
>>>> the correct order (adding dependencies ends up with cyclical
>>>> dependencies). So you have to keep recasting libpthread-stubs until
>>>> everything compiles okay. This is not a proper upgrade path imo, but I
>>>> couldn't think of anything better given the current limitations of
>>>> Sorcery.
>>>>
>>>> This isn't a complete list either since I gave up adding spells to it
>>>> after a bit and instead focused on trying to get spells to cast in the
>>>> correct order. If the leads decide to merge this, I'll try to eventually
>>>> compile a complete list of spells that need recasting.
>>>
>>> Yes, I think this is the biggest problem we have in Source Mage. libpng
>>> suffers from exactly the same problem, as did the libxcb upgrade we
>>> suffered through some years back. The unnecessary deep linking that is
>>> done by libtool only exacerbates the problem, hence my suggestion to move
>>> forward on --as-needed a while back. But that will only improve matters,
>>> it will not completely solve them.
>>>
>>> I think the only proper way to solve this is to have sorcery collect the
>>> link dependencies from the installed spells, in the case of ELF dynamic
>>> objects, the spells that provide each of the listed DT_NEEDED entries in
>>> the dynamic objects, even if the listed entry is not directly used, as
>>> building anything that links to that object will fail if the dynamic
>>> object in the entry does not exist anymore. Then, when casting anything,
>>> sorcery needs to know about incompatible upgrades, build a tree of link
>>> dependent spells ignoring dependencies in DEPENDS for this tree, and
>>> immediately cast those spells in the correct order. We still have to see
>>> about resolving any cyclic dependencies if there are any, and it should
>>> be seen whether these spells should be cast from the grimoire or from
>>> tablet. Then and only then should sorcery continue casting its normal
>>> queue, meaning that the link dependency triggered queue should be
>>> separate from the normal cast/install queue.
>>>
>>> This would of course mean a big change in sorcery though and given the
>>> lack of time and motivation for any big sorcery work, I don't think this
>>> is going to happen anytime soon.
>>>
>>> Regards, Remko
>>
>>
>> Can a planar list of casts (no matter if some get repeated) be created
>> so that at the end all dependencies issues get solved by casting spell
>> by spell, one at a time? If so, perhaps documenting such list of
>> steps might be a work around...
>>
>>
>
> Hmm, thinking about it, this may be a viable option by chaining
> commands. I don't have the time to work on this currently though. If
> someone else wants to step in (I already made a pretty good list of
> spells above), please do. :)

I'm not using devel-xorg-modular, I'm using test, with several spells
from devel-xorg-modular and some other spells missing from
devel-xorg-modular.

I went through the exercise to cast libpthread-stubs 0.3, gotten from
devel-xorg-modular.

The process was actually quiet smooth compared to the libpng one. The
only fix required from my part was libxft. Both the test versions and
the devel-xorg-modular depend on freetype2, but 2 headers needed by
libxft are used from /usr/include/freetype, which is wrong bacause the
freetype2 headers are found on /usr/include/freetype2. See:

http://www.sourcemage.org/issues/627

After fixing that, I found no problems, other than the need for a 2nd
pass of the spells dependent upon libpthread-stubs, given the fonts
not looking good on gtk+*.

I mixed the casting of dynamically linking dependencies the spell on
devel-xorg-modular had, with casting the spells directly dependent on
libpthread-stubs, with the spells provided by Sukneet, and that worked
out well (2 triggers required). See attachment.

The spells I already had casted, given I moved to gcc 4.7.6 at some
point, and now I'm with gcc 4.8.2 are the ones I mentioned in my last
comment on an old closed bug, but perhaps some additional ones:

http://www.sourcemage.org/issues/530

In essence the libpthreads-stubs looks a cleaner update than the
libpng one, but perhaps it has to do with casting all those spells
1st, :-)

What I'll need to do next will be to set "as-needed" as my LDFLAGS,
and at some point performs "cast -r", but that takes time...

Also I'll need to see what spell to bring from devel-xorg-modular on
top of test. If someone has a list, that'd be great. If not, then
I'll have to script a little bit to at least find out which spells are
newer on devel...

Thanks,

--
Javier.

Attachment: libpthread-stubs.tar.xz
Description: Binary data




Archive powered by MHonArc 2.6.24.

Top of Page