[ Home | Articles | Account | People | Projects | FAQ ] Name: James Henstridge
Member since: N/A
Last Login: 2008-03-29 00:44:08
Homepage: http://www.jamesh.id.au/
Notes:
A GNOME hacker. Author of gnorpm, gnome-python, libglade, pygtk and others. Former maintainer of dia. Contributor to various gnome packages.
[New diary entry] [Planet Gnome] [Planet Ubuntu] [Technorati Profile]
SSL caching on Firefox 3
Since upgrading to Ubuntu Hardy, I’ve been enjoying using Firefox 3. The reduced memory usage has made a lot of other things nicer to use (I don’t feel like I need to buy more memory now). One thing that is nice to see fixed is caching of SSL content.
In previous versions of Firefox, SSL content was never cached to disk with the default settings. While you certainly don’t want all SSL content to be written to disk, a lot of it can be cached without problem. For example, it is important that the CSS and JavaScript for a page be served via SSL to avoid man in the middle attacks (injecting arbitrary active content into a secure page is bad), but there isn’t much harm in caching them to disk: if the attacker can modify the disk cache then SSL probably doesn’t matter much.
Now it was possible to turn on disk caching in Firefox 2 through the browser.cache.disk_cache_ssl hidden option, but it had a serious drawback: the security information for resources was not saved in the disk cache so you’d get a broken padlock if resources were loaded from the cache.
Firefox 3 fixes up the disk cache to record the security information though, so turning on disk_cache_ssl setting no longer results in a broken padlock. But what about all the people using Firefox with its default settings (or those who do not want all SSL content cached to disk)? For these users, the web server can still cause some content to be cached.
By sending the “Cache-Control: public” response header, the server can say that a resource can be stored in the disk cache. Firefox 3 will respect this irrespective of the disk_cache_ssl setting. This should bring Firefox back into parity with Internet Explorer with respect to network performance on SSL web sites.
Psycopg migrated to Bazaar
Last week we moved psycopg from Subversion to Bazaar. I did the migration using Gustavo Niemeyer’s svn2bzr tool with a few tweaks to map the old Subversion committer IDs to the email address form conventionally used by Bazaar.
The tool does a good job of following tree copies and create related Bazaar branches. It doesn’t have any special handling for stuff in the tags/ directory (it produces new branches, as it does for other tree copies). To get real Bazaar tags, I wrote a simple post-processing script to calculate the heads of all the branches in a tags/ directory and set them as tags in another branch (provided those revisions occur in its ancestry). This worked pretty well except for a few revisions synthesised by a previous cvs2svn migration. As these tags were from pretty old psycopg 1 releases I don’t know how much it matters.
As there is no code browsing set up on initd.org yet, I set up mirrors of the 2.0.x and 1.x branches on Launchpad to do this:
It is pretty cool having access to the entire revision history locally, and should make it easier to maintain full credit for contributions from non-core developers.
Psycopg2 2.0.7 Released
Yesterday Federico released version 2.0.7 of psycopg2 (a Python database adapter for PostgreSQL). I made a fair number of the changes in this release to make it more usable for some of Canonical’s applications. The new release should work with the development version of Storm, and shouldn’t be too difficult to get everything working with other frameworks.
Some of the improvements include:
If you’re using previous versions of psycopg2, I’d highly recommend upgrading to this release.
Future work will probably involve support for the DB-API two phase commit extension, but I don’t know when I’ll have time to get to that.
Honey Bock Results
Since bottling the honey bock last month, I’ve tried a bottle last week and this week. While it is a very nice beer, the honey flavour is not very noticeable. That said, the second bottle I tried had a slightly stronger honey flavour than the first so it might just need to mature for another month or so.
If I was to do this beer again, it would make sense to use a stronger flavoured honey or just use more honey. Then again, perhaps it isn’t worth trying honey flavoured dark beers.
One beer I’d like to make again is Chilli Beer. I haven’t seen any commercial equivalent to it, and it was great on a hot summer afternoon. Since there were chilli pieces in the bottles of the last batch, it got hotter as it matured. It is an interesting experience where taking a sip of the beer cools your moth down, but it starts heating up again once you swallow.
Using email addresses as OpenID identities (almost)
On the OpenID specs mailing list, there was another discussion about using email addresses as OpenID identifiers. So far it has mostly covered existing ground, but there was one comment that interested me: a report that you can log in to many OpenID <acronym title="Relying Party">RP</acronym>s by entering a Yahoo email address.
Now there certainly isn’t any Yahoo-specific code in the standard OpenID libraries, so you might wonder what is going on here. We can get some idea by using the python-openid library:
>>> from openid.consumer.discover import discover
>>> claimed_id, services = discover('example@yahoo.com')
>>> claimed_id
'http://www.yahoo.com/'
>>> services[0].type_uris
['http://specs.openid.net/auth/2.0/server',
'http://specs.openid.net/extensions/pape/1.0']
>>> services[0].server_url
'https://open.login.yahooapis.com/openid/op/auth'
>>> services[0].isOPIdentifier()
True
So we can see that running the discovery algorithm on the email address has resulted in Yahoo’s standard identifier select endpoint. What we’ve actually seen here is the effect of Section 7.2 at work:
3. Otherwise, the input SHOULD be treated as an http URL; if it does not include a “http” or “https” scheme, the Identifier MUST be prefixed with the string “http://”.
So the email address is normalised to the URL http://example@yahoo.com (which is treated the same as http://yahoo.com/), which is then used for discovery. As shown above, this results in an identifier select request so works for all Yahoo users.
I wonder if the Yahoo developers realised that this would happen and set things up accordingly? If not, then this is a happy accident. It isn’t quite the same as having support for email addresses in OpenID since the user may end up having to enter their email address a second time in the <acronym title="OpenID Provider">OP</acronym> if they don’t already have a session cookie.
It is certainly better than the RP presenting an error if the user accidentally enters an email address into the identity field. It seems like something that any OP offering email addresses to its users should implement.
jamesh certified others as follows:
Others have certified jamesh as follows:
[ Certification disabled because you're not logged in. ]
FOAF updates: Trust rankings are now exported, making the data available to other users and websites. An external FOAF URI has been added, allowing users to link to an additional FOAF file.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank