Comment 46 for bug 676972

 On 2010-11-27 03:34, Chow Loong Jin wrote :
> On Saturday 27,November,2010 10:16 AM, Christian Reis wrote:
>> There's something wrong here; I'm wondering if I'm just the only one
>> that has noticed.
>>
>> If you look at what Roel Huybrechts provided as a lucid debdiff, it
>> includes a number of changes to libpurple (for instance the inclusion of
>> x509_ca_get_certs() and a callsite for it ) that simply aren't present
>> in the patch that Chow Jin provided. Now I've just pulled the source for
>> the pidgin package from maverick-updates and the only difference listed
>> there is the certificates. AIUI just the certificates does /not/ solve
>> the issue -- as a few people here have pointed out it still requires
>> removing the certificates manually. If this holds
>> true (and I can reproduce it here) I consider this to be a pretty poor
>> fix for Maverick users in general.
> Hmm, yes you're right. I'm not sure where that extra bit came from though. My
> understanding of the matter was that those who had manually exchanged their
> omega.contacts.msn.com certificates would have to remove them before it would
> work again, whereas those who hadn't would have the fix working perfectly
> without any extra changes needed.

From the many many tests I made with the present Pidgin code, I came
under the impression that the omega.contacts.msn.com in user space is
just a cache. If it matches the certificate to check, the job's done. If
it doesn't Pidgin is prepared for a cache update. But it could no do it
because of the missing intermediate certificates story. That's why two
certificates were added.
Presently, Pidgin must probably alternate between receiving the old and
new certificates and it must do the check by using both the old and new
files.
In practice,
- without the added certificates, Pidgin must wait until whichever
certificate it cached appears again
- with the added certificates, it always succeeds updating, I must have
overcome that a 100 times
As all that is only smart guessing the inside of the black box, I
thought that the best idea is to watch the cache updating. So, I made
10 connections, I saved omega... each time and here's the result :
$ dir *.pem
1723222 -rw------- 1 p p 2303 2010-11-27 08:20 01.pem
1723229 -rw------- 1 p p 2303 2010-11-27 08:21 02.pem
1723230 -rw------- 1 p p 2339 2010-11-27 08:21 03.pem
1723231 -rw------- 1 p p 2339 2010-11-27 08:21 04.pem
1723232 -rw------- 1 p p 2303 2010-11-27 08:22 05.pem
1723233 -rw------- 1 p p 2303 2010-11-27 08:22 06.pem
1723235 -rw------- 1 p p 2339 2010-11-27 08:23 07.pem
1723246 -rw------- 1 p p 2339 2010-11-27 08:23 08.pem
1723247 -rw------- 1 p p 2339 2010-11-27 08:24 09.pem

Just by watching the sizes of the files, it's obvious that Pidgin is
constantly updating its cache itself.
So, there is no need for the user to erase it.
I think there's no use to try to prove that each size corresponds to
either of old or new certificate.
But I can send them to any disbeliever ;-)
Or just two, as I just checked that same size files are the same.

So, I think that the practical effectiveness of the update has been
proven enough in several ways and that, 10 days after the problem
appeared, it's high time to move the update to -update if we want to
beat the legendary 15 days turnaround of errr... other constructors.
Just adding two certificates cannot make it worse in any case, could it.
I think that the code update is another improvement, probably to do
without adding certificates as errr... other constructors do. Probably
very nice but we have no time to wait and it must be postponed to a
later update.

Just make sure that the update pickers don't miss picking libpurple0.
I would change the dependency I spoke of.

TIA × at least the French Gendarmerie size ;-) (not me ;-) )