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

[Daniel Atallah]

On Thu, Apr 11, 2013 at 10:26 PM, Tomasz Wasilczyk
<tomkiewicz at cpw.pidgin.im> wrote:
> 2013/4/10 Daniel Atallah <datallah at pidgin.im>:
> 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).

Assuming recent Windows versions, I think that your assessment is
correct - if an absolute path isn't used, an issue would only exist if
the dll was missing from the expected location based on how the
launcher works.

I think we should still use the full paths everywhere, in order to do
the right thing for other libpurple clients.

Currently we only use partial paths to load functions out of
"dnsapi.dll", "ws2_32.dll" and Apple Bonjour SDK's "dnssd.dll".

Of these, I think only "dnssd.dll" is potentially problematic -
"dnsapi.dll" and "ws2_32.dll" should be "known dlls" that can't be
overwritten (at least on recent Windows versions).
Actually we don't need to dynamically load functions out of dnsapi.dll
anymore - the relevant functions are supported by Windows 2000 and
newer, so we can use them directly - I'll update the code.

We probably can and should load "dnssd.dll" with a full path based on
CSIDL_SYSTEM.

>>>> 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.

Yeah, that's probably a good idea.

Such a thing could be the starting point for a full dependency
building set of scripts if anyone ever had the time / motivation to do
so.