Wednesday, November 21, 2012

IE7 debugging

Cool way to compare IE7-related parsing issues..

http://coding.abel.nu/2012/09/using-a-bit-of-luck-to-track-down-css-parse-errors-in-ie7/

Sunday, November 18, 2012

Gnome Keyring

See this error?
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
It's an issue with Gnome key-ring, possibly this issue with multi-architecture support: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600

Wednesday, November 14, 2012

Using mod_oauth_openid with Google Apps

Because of a recent release on a Jenkins plugin for Google Apps SSO, I wondered whether there was a way to get mod_oauth_openid without prompting a user to choose between Google Apps domains.  The basic approach would have been to set Apache configurations similar to the one described in this previous blog posting except for the following lines:
AuthOpenIDTrusted ^https://www.google.com/a/yourdomain.com/o8/ud
AuthOpenIDSingleIdP https://www.google.com/accounts/o8/site-xrds?hd=yourdomain.com
If you try to make mod_oauth_openid work with the configuration above, chances are you'll see "OP is not authorized to make an assertion regarding the identity".  This issue was encountered by another user in this thread (the Step2 libraries referred are the OpenID Google App discovery extensions that Google refers at https://code.google.com/p/step2/).  Unless a patch is made to mod_auth_openid or the underlying libokele C++ library to support these Google discovery extensions, chances are that you won't be able to use this approach.

The apparent problem is that Google has a special way of dealing with OpenID discovery process:

https://developers.google.com/google-apps/help/faq/auth#what_discovery
It is important to note that the RP must use a slightly different discovery mechanism to support Google Apps accounts, which is covered in depth here. In short, during the OpenID discovery process, RPs must check both (using example.com as theexample domain) https://www.google.com/accounts/o8/.well-known/host-meta?hd=example.com and http://example.com/.well-known/host-meta for discovery information, as the site owners may opt to have Google host this information, rather than host it themselves.
Basically it means that that when a user authenticates on Google Apps, you're given back not only a unique identifier for the user (known as the claimed id), along with a URL. If your domain is mydomain.com, the URL that is returned is http://mydomain.com/openid?id=<id>. In OpenID specs, this URL is expected to be available for you to grab metadata to determine where to inquire about this ID.  If an OpenID library tries to open this URL, chances are that it will 404 and therefore fail the user discovery process.

Google proposes that the users implementing Google Apps SSO look both at https://www.google.com/accounts/o8/.well-known/host-meta?hd=example.com or http://example.com/.well-known/host-meta. Neither of these URLs follow the OpenID spec since one of them requires you to host this metadata, but you also have to deal with digitally signing it too). The approach is summarized in the User Discovery section of the Google OpenID documentation.

The Jenkins OpenID and Python OpenID plugins skip this step and just assumes https://www.google.com/accounts/o8/user-xrds?uri= is the correct URL to use.  Normally the metadata would need to include this <URITemplate> tag, which then gets used to perform the user verification.

https://github.com/jenkinsci/openid-plugin/commit/91beef6857f0d7956ee0ad27ac24744f961ae6c2 
https://github.com/adieu/python-openid/commit/789cc11950e94c09e7c912a34b4e1d1d8f20c62b

More background here: 

http://www.slideshare.net/timdream/google-apps-account-as-openid https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery 

Also, someone else attempted to side-step this issue with Google Apps and mod_auth_openid, but it feels more of a way to circumvent some of the OpenID discovery process:

https://gist.github.com/2635479

Jenkins Plugins updates!

Two improvements for Jenkins users that seem to very promising.

First, the OpenID plugin now has explicit Google Apps support. You now set the domain and the XML configuration automatically sets the OpenID XRDS discovery to rely on a specific domain. You could previously use Google Apps but users were asked to select which domain to use if you were signed in with multiple ones (i.e. your personal and company Gmail account).

Instead of:
https://www.google.com/accounts/o8/id
The Google Apps domain will now set the domain to be:
https://www.google.com/accounts/o8/site-xrds?hd=yourdomain.com
There is an extra Google Apps SSO option now exposed:


Keep in mind that you must use the Google Apps SSO with this new URL.  The reason is that Google App has a special OpenID discovery mechanism that breaks with standand OpenID.  For more details, check out the source code for this plugin.

Secondly, the Cobertura Plugin has support to allow fails on low coverage results as well as ratcheting to improve coverage percentages.

 https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin


See the diff here:

https://github.com/jenkinsci/cobertura-plugin/commit/1cef2b6890bf3388e7e80f12bbe8588035049403

If a change reduces the current coverage, you can now have your builds fail!  There are also extra checkboxes to allow ratcheting to occur, which means that if the coverage is higher than the current bulid, the new metric will be set to that number:

Publishing Cobertura coverage results...
Cobertura coverage report found.

Lines's new health minimum is: 90.8
Lines's new stability minimum is: 90.8

Tuesday, November 13, 2012

Verifying X509 certs and private keys

Using the Chef SSL cookbook and want a way to verify your X509 cert and private key sign correctly?  Here's how you can use M2Crypto and JSON loads to double check....

Adapted from http://note.harajuku-tech.org/m2crypto-signverify-with-x509-rsa-sha-256...
from M2Crypto import RSA
import json

data_bag_1 = json.loads(open("mycert.json", "r").read())

key = str(data_bag_1['key'])
cert = str(data_bag_1['cert'])

pk=RSA.load_key_string(key)
import hashlib
digest = hashlib.sha256( "ABCDEFGHIJKLMN" ).digest()
signature=pk.sign(digest)

from M2Crypto import X509
pub=X509.load_cert_string(cert).get_pubkey().get_rsa()
pub.verify(digest,signature)

Sunday, November 11, 2012

Technology field offices: a new precedent?

"It's an experiment", Catherine Bracy, one of the staff members assigned to manage Obama's first ever technology field office in San Francisco, said to me in early March 2012. Instead of searching for volunteers to make phone calls to battleground states, she was recruiting for engineers. The directive from Chicago was to staff this field office with volunteers who wanted to code for the campaign.

I signed the 10-page document that stated that any services rendered on the campaign's behalf belonged to Obama for America, all work did not entitle us to employee benefits, and anything confidential could not be disclosed.  Essentially, it boiled down to everything you did would be unpaid and wouldn't belong to you. Nonetheless, it also enabled people like myself to get a glimpse into the inner-workings of the Obama campaign and contribute towards the reelection of the President. The expectations were that we'd commit to 5-10 hours a week, which allowed us to still have a full-time job.

"Fastest...turnaround...ever," Angus Durocher joked when I sent back the agreement within 10 minutes of receiving it. Angus had been one of the lead engineers at YouTube before its acquisition by Google in 2006 and left the startup world to work on the Obama campaign, first as the Deputy New Media Director in New Mexico for 2008 and now was tasked as the "one lonely engineer" to staff the Obama Technology Field Office for 2012. He'd be at the field office until the last person left, tuning into the latest Boston Red Sox or San Francisco Giants baseball games while fueled by donuts and apple crisps brought earlier in the week.

I worked on a variety of projects, refining the voting engine that powered the "Runway to Win" contest where the top three submission submitted by amateur designers were sold as T-shirts on the Barack Obama store or building a Romney translation tool that revealed the candidate's more right-leaning positions. Other volunteers were asked to work on projects that illustrated the impact of the American Recovery and Reinvestment Act or Affordable Health Care Act, along with a multitude of other applications. Catherine Bracy and Angus Durocher quarterbacked the product development and testing in San Francisco before handing off the projects to Chicago.

Perhaps one of our most significant contributions from the San Francisco technology office was the introduction of Trip Planner. Designed and built by volunteer Marc Love, Johnvey Hwang, and many other volunteers, it was a travel site that enabled supporters to find and offer housing and rides in battleground states. The thousands of emails asking for volunteers to Nevada from California enabled individuals the option to arrange carpools with this site, a tool that could undoubtedly be improved and enhanced for future presidential campaign cycles.

In 2008 and 2012, the Obama campaign established more than 700 field offices across the country to build a formidable get-out-the-vote operation.  In San Francisco, one was opened primarily focused on technology development efforts, which represented one of the first times members of the tech community were enlisted to create software for the campaign. In the spirit of the campaign's mantra, the response became "Yes We Code!"

Roger Hu is a former Obama delegate to the 2008 Democratic National Convention, and a volunteer from the San Francisco Technology Field Office for the Obama 2012 campaign.

Thursday, November 1, 2012

Using the Franklin U600 Sprint modem on Ubuntu 12.04

Ubuntu 12.04 seems to have support for the Franklin U600 Sprint modem right out of the box. Instead of configuring udev rules to auto-detect the device by issuing a modprobe usbserial vendor=0x1fac product=0x0151 command, Ubuntu 12.04 seems to detect this device automatically using the cdc_acm module:
$ usb-devices

T:  Bus=01 Lev=03 Prnt=11 Port=01 Cnt=01 Dev#= 12 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1fac ProdID=0151 Rev=00.00
S:  Manufacturer=Franklin Wireless Corp.
S:  Product=U600 EVDO Modem 
C:  #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
Lately, I've noticed that sometimes the device fails to be auto-detected after removing it. One thing that appears to work is to remove the module before trying again. One workaround is to remove the module yourself after physically taking out the USB device:
$ sudo rmmod cdc_acm
The cdc_acm driver is used only for 3G access (Qualcomm QSC6085 chipset). The U600 comes with a Beceem (now Broadcom) chipset and Sprint appears to have released a reference guide with patches for Linux 2.6. Instructions for setting up the 4G driver and WiMax certs are also included for Franklin U250, U300, and U600.

You may also need to restart modem-manager because of this bug too: https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/869954
http://osdir.com/ml/networkmanager-list/2010-07/msg00071.html https://mail.gnome.org/archives/networkmanager-list/2012-August/msg00125.html https://mail.gnome.org/archives/networkmanager-list/2012-February/msg00097.html