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

[Daniel Atallah]

On Mon, Apr 8, 2013 at 8:10 PM, Tomasz Wasilczyk <tomkiewi at gmail.com> wrote:
> 2013/4/8 Daniel Atallah <datallah at pidgin.im>:
>> The installer actually may or may not write to the HKLM registry
>> depending on the permissions of the user who ran the installation.
>>
>> I think I'd rather keep it simple and not use the registry at all -
>> just make it always work relative to the pidgin dll.
>>
>> This will eliminate a bunch of issues with unexpected behavior when
>> someone tries to run a standalone or devel version of pidgin and
>> starts picking up things out of the installed version.
>> `make install` (or perhaps some other target) should ideally set up
>> the development version so it can run completely in-tree
>
> That's good point, especially the idea of "make install" setting up
> things to run totally independently. But I don't see the reason, why
> "gtk and (some) friends" should be treated differently than other
> dependencies.

You're right, I don't think that they should necessarily be treated
differently either.


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


>> That's actually not really the reason (or at least not the only
>> reason) that we ship old versions of some of those dependencies.
>> The main reason we still run GTK+ 2.16.6 is that newer versions are
>> broken in various ways.
>> Even the latest GTK2 release (2.24.17) has some showstopper issues
>> (e.g. https://bugzilla.gnome.org/show_bug.cgi?id=671538).
>
> Isn't 2.34 / 2.36 the latest GTK2? But you're right, that could be the
> reason for sticking with last secure version.

That's Glib, not GTK+ :)

>>> And another solution: shipping two dependency bundles - one for gtk
>>> and one for others. But, in my opinion, both will get equally frequent
>>> updates (as I said above). I can implement it also.
>>
>> Taking it a step further, would we think about splitting out the
>> dependencies into package-level granular groupings and make the
>> "online" installer evaluate and update each package independently as
>> necessary.  This may be a lot of work though.
>
> I think, this is actually the best idea. Clean and efficient.
>
>> To be honest, I don't foresee us changing the dependencies all that
>> much more frequently than we do now.  Generally, I'd like to avoid
>> changing stuff unless there's a compelling reason to do so (security
>> fix, fix to specific bugs that impact us, major functionality
>> addition).
>
> I have exactly the same opinion - we have no interest in bumping
> versions but security fixes and features that we actually could use.
> My concern is about:
> - not treating gtk differently

I agree that we don't need to treat Gtk differently (as such).

> - not mixing devel headers used for compilation with runtimes (again:
> treating all deps consistently)

This was actually intentional, although we probably don't need to do
it for that reason anymore.
The reason for using old GTK+ headers is that we wanted the binary to
be useable on older versions of Windows (the user would need to supply
a compatible GTK+ though).

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

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

-D