/pidgin/main: 71533f0d5dc0: win32: switch to OBS, update and pus...

[Tomasz Wasilczyk]

2013/4/10 Daniel Atallah <datallah at pidgin.im>:
>> I see here some place for improvement of security - at this moment,
>> dlls shipped with Pidgin are secured by providing a full path, but
>> others (Gtk) seems to not. We can protect all of them in the same way.
>
> Hmm... Gtk doesn't appear to be treated differently.
>
> The cases we've been talking about involve dynamic loading (LoadLibrary).
>
> Gtk and friends are linked directly and not explicitly dynamically loaded.
>
> The launcher application (pidgin/win32/winpidgin.c) takes care of
> setting up the environment, including using SetDllDirectory to ensure
> that the Gtk/bin directory is preferred.

Isn't it enough (rely on launcher app) for these dlls, that I've
stripped off the full path? I assume, that attack could be performed
only in case, when specific dll was missing from Gtk/bin folder (but
we actually *provide* them).

> That's Glib, not GTK+ :)

Oops ;)

>> I've already contacted OBS mingw repository maintainer, Fridrich
>> Strba. He's really helpful - he bumped libxml2 to 2.9.0 after about 8
>> hours after my request.
>
> Cool, it's good to hear that he's been so responsive.

Just as update: libxml2 is already updated, meanwhile is patched (it
was probably patched since the beginning), nss&nspr is updated.

>>> pidgin-inst-deps  contains a couple "external" things:
>>>  * There's a NSIS plugin that I wrote to do a SHA1sum calculation on
>>> files it downloads so that they can be compared to the expected values
>>> - the source is in the zip file.
>>>  * The other thing is the crash-reporting library (exchndl.dll).  The
>>> source is here: https://hg.pidgin.im/util/drmingw/.
>>
>> Don't you think they could be compiled just before creating
>> dependency-bundle? This is just a idea, I have no clear opinion about
>> it.
>
> I'm not sure what you're suggesting.  Would this mean that we'd
> compile these as part of the Pidgin packaging process?
> I guess I don't see what's wrong with the current binaries being
> downloaded as part of the build environment being set up.

I don't really know what I am suggesting. Maybe there should be
another script, for compiling dependencies, that /we/ compile by
ourself? Just like your idea for providing script that compiles
everything from the scratch, but only as optional and with priority on
dependencies that no-one would compile them for us.