pidgin/pidgin

887efbd652d8
certificate: Use public key fingerprint to compare certificates

This fixes an issue with google talk's certificates and gnutls, where the root
certificate in the provided chain is a slightly different version of the one
that is usually present in the certificate stores, but the SubjectPublicKeyInfo
section is the same.

This adds a PurpleCertificateScheme function, compare_pubkeys, and its wrapper
purple_certificate_compare_pubkeys().

This is only implemented for gnutls, since the NSS plugin only uses the NSS
certificate validation code. Even if that path was reachable from a plugin that
doesn't implement this method, it would return FALSE and behave as if this bug
was never fixed.

The gnutls implementation uses the gnutls_x509_crt_get_key_id() function,
which returns a hash of the SubjectPublicKeyInfo section of the certificate.

In gnutls versions older than 3.4.1, this may be a SHA1 hash, but after that
version SHA256 support was added (without much fanfare - the documentation
barely mentions this at all), and we just use the constant for the best known
algo, which for current versions is just SHA256. Older versions ignore that
flag parameter.

The whole comparison is modeled after the private _gnutls_check_if_same_key(),
which checks if both certificates have the same DN ("unique id") and does a
memcmp() of the raw SPKI section. We don't have direct access to the raw SPKI
section but comparing their fingerprints is good enough.
If you plan to use Pidgin, Finch and libpurple from our Mercurial repository,
PLEASE read this message in its entirety!
Pidgin, Finch, and libpurple are a fast-moving project with a somewhat regular
release schedule. Due to the rate of development, the code in our Mercurial
repository undergoes frequent bursts of massive changes, often leaving behind
brokenness and partial functionality while the responsible developers rewrite
some portion of code or seek to add new features.
What this all boils down to is that the code in our Mercurial repository _WILL_
sometimes be broken. Because of this, we ask that users who are not interested
in personally tracking down bugs and fixing them (without a lot of
assistance from the developers!) use only released versions. Since releases
will be made often, this should not prevent anyone from using the newest,
shiniest features -- but it will prevent users from having to deal with ugly
development bugs that we already know about but haven't gotten around to fixing.
If you are interested in hacking on Pidgin, Finch, and/or libpurple, please
check out the information available at: http://developer.pidgin.im
By far the best documentation, however, is the documented code. If you have
doxygen, you can run "make docs" in the toplevel directory to generate pretty
documentation. Otherwise (or even if you do!), the header files for each
subsystem contain documentation for the functions they contain. For instance,
conversation.h contains documentation for the entire purple_conversation_*
API, and account.h contains documentation for the purple_account_* API.
If you have questions, please feel free to contact the Pidgin, Finch, and
libpurple developers by email at devel@pidgin.im or on IRC at irc.freenode.net
in #pidgin. Please do as much homework as you can before contacting us; the
more you know about your question, the faster and more effectively we can help!
Patches should be posted as Trac tickets at: http://developer.pidgin.im