Trac is being migrated to new services! Issues can be found in our new YouTrack instance and WIKI pages can be found on our website.

Version 28 (modified by wehlhard, 17 years ago) (diff)

stuff complete

Issues

  • Design issue: In my design, the Certificate struct has an ptr to a GnuTLS certificate structure to hold its internal data. This has the consequence that the SSL connection system and X.509 handling must both be provided by GnuTLS; if, say, SILC provides the X.509 handling, and GnuTLS the SSL connections, everything grinds to a gruesome segfaulty halt.

Should I address this? The only workaround I can think of is to keep a pointer to the PEM-formatted certificate in the Certificate struct instead, but that will require any consumers of the Certificate to have PEM encoding/decoding and constantly decode it from PEM for every use. (June 19)

  • How to ensure that VerificationRequests? get properly trashed in unusual conditions (such as canceling an SSL connection)? (June 26)
  • Jabber.org presents a cert with a CN of "*.jabber.org". How to check this? (26 June)
    • Update: This is *almost* valid. "foo.jabber.org" is valid with this certificate, but not "jabber.org" itself! (8 July)

Resolved Issues

  • It looks like PKCS12 (the certificate import/export format) is supported by both libNSS and GnuTLS.
  • Jabber "connect with fd" problem solved by porting a change from soc.2007.xmpp (29 May, June 26)
  • Why doesn't a "not accepted" on a certificate cause the connection to fail? I suspect this is caused by auto-reconnect, so it might be necessary to disable the account involved! (26 June)
    • This could be related to Jabber not handling the BAD_CERTIFICATE error code?
    • I think this is resolved...at least, I can't reproduce it any more.. (11 July)

TODO

  • General paranoia
  • Look at how the SILC prpl does its key management, especially the organization of the API used to check certs and interact with the user to verify them.
  • Add some way of passing useful error messages back up out of the SSL interface (23 May)
  • Fix purple_ssl_init in sslconn.c; it doesn't do anything (23 May)
    • Talking to nosnilmot suggests that this ought to just be removed outright (24 May)
  • Figure out libNSS everything. (25 May)
  • Why am I getting single-byte serial numbers from servers? (25 May)
  • Stall the timeouts on the TCP connection while waiting for user input on SSL? (29 May)
  • Worry about ensuring that plugins don't kill in-use ciphers/certschemes when unloaded? (29 May)
  • Adium uses neither GnuTLS nor NSS. Look into extending the OpenSSL plugin (26 June)
  • Guarantee that purple_certificate_verify will not fire its callback until the next return to mainloop. sadrul says to do this with g_timeout_add (June 28)
  • Change the things that purple_certificate_verify does such that it is easy for one verification request to make another. This will involve making a "copy" operator for certificates. (7 July)
  • Disapprove 42fb4d80947518f87ddcaf43bf2675d8496698de (7 July)
  • Reference-count Certificate instances instead of making full copies? (8 July)
  • Refactoring. The certificate interface feels too complicated. (11 July)
  • HIG compliance (17 July)
  • How should a PidginCertificateManager? signal that it *cannot* be displayed? (19 July)
  • Degrade gracefully when the CertMgr subsystem lacks important bits. (3 Aug)

Tasks done

  • Figure out how to get key fingerprints out of GnuTLS (25 May, 25 May))
  • GnuTLS and NSS should probably be configured to use g_malloc and g_free for paranoia's sake (1 June, 26 June)
  • e408398aae606a1aafb857413db4fa9736e374ae should be disapproved. It is hacky and stupid (26 June, 7 July)
  • Why won't gtkcertmgr.h get properly processed by "make docs"? (13 July, 13 July)
    • sadrul is awesome. Typos are not.
  • Work out how to use Glib functions for time checking on certificates. (29 May, 13 July)
    • POSIX for the win.
  • activation/expiration should be made one function in the Scheme, as that's how NSS does it. (13 July, 3 Aug)
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!