view share/ca-certs/Makefile.am @ 23995:85bed17fe5c1

The variable we use to keep track of the watcher of the ssl connection should be unsigned. This isn't really a problem in Pidgin, where we use glib's mainloop and GIOChannels because glib starts assigning the handle IDs sequentially starting from 1. But if an eventloop implementation ever returns a handle ID greater than the largest possible signed integer (2,147,483,647) then we won't be able to remove the watcher because purple_ssl_close() in sslconn.c only removes it if inpa > 0, and since it interprets inpa as a signed value then handles over 2,147,483,647 appear as negative numbers. I stumbled upon this when playing around with libevent, which can use epoll. My implementation generated a random handle ID which was sometimes greater than 2,147,483,647. I don't believe this breaks binary compatibility. And I don't think it breaks source compatibility, but I guess it might depend on what compiler you're using.
author Mark Doliner <mark@kingant.net>
date Thu, 04 Sep 2008 18:04:29 +0000
parents fd646e79cccf
children 7ed27ecdab51
line wrap: on
line source

CERTIFICATES = \
		CAcert_Root.pem \
		CAcert_Class3.pem \
		Equifax_Secure_CA.pem \
		GTE_CyberTrust_Global_Root.pem \
		Microsoft_Secure_Server_Authority.pem \
		StartCom_Free_SSL_CA.pem \
		Verisign_RSA_Secure_Server_CA.pem \
		Verisign_Class3_Primary_CA.pem \
		VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem

if INSTALL_SSL_CERTIFICATES
cacertsdir =	$(datadir)/purple/ca-certs
cacerts_DATA =	$(CERTIFICATES)
endif

EXTRA_DIST =	\
		Makefile.mingw \
		$(CERTIFICATES)