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

[Tomasz Wasilczyk]

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.

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.

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

>> 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
- not mixing devel headers used for compilation with runtimes (again:
treating all deps consistently)

> I noticed that libxml2 was downgraded (I know you specifically said it
> was temporary, but it's an example) to a version with known
> vulnerabilities.
>
> The biggest concern for this (and other things) is that we need to be
> able to get security fixes in a timely manner - that's part of the
> reason I want to get a scripted "build everything from scratch" setup.

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.

>> - pidgin-inst-deps - I see no documentation about it
>
> 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.

At this point, not all imported dependencies are proven to be
completely secure. But I'm working on it - as I said above, Fridrich
is pretty helpful with that.