If you are doing Selenium testing using Chromedriver2 0.8 and are having problems with self-signed SSL certificates, this is a known problem and will be fixed in a subsequent release. In the meantime I found that using the Chromedriver 26.0.1383.0 still worked without problems for Chrome 27 and also did not have this SSL certificate regression in it.
Category Archives: Programming
Mercurial and safely storing passwords
Mercurial allows for tying in keyring configuration for those of us who do not want to store passwords in plain-text in our .hgrc files or constantly using SSH.
First install the Python keyring library by running pip install keyring. After that is installed, checkout https://bitbucket.org/Mekk/mercurial_keyring/ and add to $HOME/.hgrc the following:
[extensions] mercurial_keyring = ~/path/to/mercurial_keyring/mercurial_keyring.py |
Next up, configure your repositories, e.g. in the case of Bitbucket I use:
[auth] bitbucket.prefix = bitbucket.org/asmodai bitbucket.username = asmodai bitbucket.schemes = https |
Mercurial keyring will automatically decide on the best keyring to use. On a FreeBSD system with no Gnome or other systems providing a keyring, if you do not specify a specific keyring, the system will use the file ~/.local/share/python_keyring/keyring_pass.cfg. This keyring file stores the passwords encoded in Base64 in plain-text. This is not quite what you would want from a security point of view. You can configure which backend store to use by editing ~/.local/share/python-keyring/keyringrc.cfg. To get a plain-text file with encrypted keys use the following configuration:
[backend] default-keyring=keyring.backend.CryptedFileKeyring |
This will create the file ~/.local/share/python-keyring/crypted_pass.cfg after initializing the backend store with a password. Look at the documentation for keyring on what other configuration options are available.
Note: make sure the PyCrypto dependency is installed with the _fastmath module. This in turn depends on the gmp library.
Separating multiple SVN projects into individual Hg repositories
If you have a Subversion repository setup with multiple top-level projects and their typical branches/tags/trunk setup and want to migrate these to individual Mercurial (Hg) repositories, you can do this with the convert extension.
First you need to enable convert in your .hgrc by adding a section like the following:
[extensions] convert = |
Next, if needed, create a plain-text file, e.g. author-map.txt, containing SVN username to Hg author mappings, e.g. asmodai=Jeroen Ruigrok van der Werven<email@address.tld>.
Next run Hg as follows:
hg --authors author-map.txt --config convert.svn.branches=project/branches --config convert.svn.tags=project/tags --config convert.svn.trunk=project/trunk path/to/svn/repository path/to/destination/hg/repository
This will start a SVN to Hg conversion, picking up only the changes and commit messages applicable for the various paths you gave for the branches, tags, and trunk, effectively splitting off this project from the main SVN tree into its own Hg repository.
Do note that for large SVN repositories this might not be the most efficient conversion way forward. In that case converting once from SVN to Hg and then split off Hg into many Hg repositories might be faster. Will adjust this post when I write that up.
Eclipse and TestNG
I was playing around with Eclipse and TestNG, the thing you need/want to do is, after you have installed testng via de Eclipse market place and restart Eclipse to go to the project build path.
So right click the project and select from the popup menu Build Path » Configure Build Path...
In this window, make sure you have selected the Libraries tab in the right-hand side of the window.
Next select Add Library... and from the resulting window that pops up select TestNG (or JUnit).
When you select Next or Finish (depending whether you picked TestNG or JUnit), you will then see TestNG under the JRE System Library entry as another library entry. If you expand this you see the testng.jar being included and pointing to the right jar file that’s in Eclipse’s plugins directory.
When you now press OK you should see the imports getting resolved.
You will need to remove any external jar dependencies for TestNG or JUnit of course, because it’s double and will most likely lead to problems.
Now, when you go to Run » Run Configurations... you see a TestNG (JUnit) entry. When you select that entry and create a new configuration underneath it, it should already resolve everything you need (classes, packages, and so on).
Oh, do keep in mind that you will have to mark the test folder as a source folder for it all to work. Right click the folder, select Build Path » Use as Source Folder.
TortoiseHG and wildcard certificates
Having resolved recent SSL certificate issues with Mercurial/TortoiseHG, I now encountered a similar issue with the wildcard certificate for *.google.com where getting a clone would result in a "SSL: Server certificate verify failed" error.
One way around this issue is to add the fingerprint for this certificate to your configuration. Currently for *.google.com this is 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8 and one way to get this from a Unix command line is with openssl s_client -connect code.google.com:443 < /dev/null 2> /dev/null | openssl x509 -in cert-code -fingerprint -noout -in /dev/stdin | tr "[:upper:]" "[:lower:]". This corresponds with Chrome’s certificate view’s thumbprint field, you just need to add colons.
Right click in Explorer, select TortoiseHG » Global Settings and then click Edit File and add the following:
[hostfingerprints]
code.google.com = 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8
This should make Mercurial/TortoiseHG work, at least until the certificate expires and you need to update it with the latest fingerprint.
TortoiseHG and non-standard SSL certificates
For my own development I use Mercurial and TortoiseHG for my version control system. I also use, at the moment, a CAcert certificate to use HTTPS with my repositories. I am not sure what changed when, but apparently the certificates now get verified. So this causes obvious problems trying to push or pull due to "SSL: Server certificate verify failed" errors.
To make this work on a Windows 7 machine with TortoiseHG in stalled, first download the CAcert root PEM certificate and place it some permanent directory. Next open the TortoiseHG global settings (right click somewhere in Explorer and select TortoiseHG » Global Settings). In the window that opens click the Edit File button. If it does not exist yet create a section similar to this:
[web]
cacerts = C:\path\to\cacert-root.pem
Press Save and OK and any push and pull action with HTTPS URLs should work as they ought to.
Unbound unable to read root zone
After upgrading various ports on my FreeBSD system and days later a full world and kernel, a reboot showed me that unbound didn’t start. The system reported that:
error: reading root hints /usr/local/etc/unbound/named.cache 88: Empty line was returned
It turns out that from ldns 1.6.13 to 1.6.14 there is an API change that caused problems for unbound. After upgrading ldns you also need to recompile unbound to pick up on these changes. If you do not, you will run into the problem above.
Detecting keyboard layout used on Windows
[code lang="c"]//Pseudo C/C# code:
int localeId = GetKeyboardLayout(0);
// The low word contains a Language Identifier for the input language
// and the high word contains a device handle to the physical layout
// of the keyboard.
localeId &= 0xffff; // mask off high word to get the locale
// identifier
switch (localeId) {
0x040c:
0x080c:
0x1009:
useAzertyMapping();
default:
useQwertyMapping();
}
[/code]
Relevant links:
GetKeyboardLayout()
Default Input Locales
Locale IDs assigned by Microsoft
JetBrains IntelliJ IDEA and Monokai
I’m a fan of the Monokai colour scheme for my source code editing and thus set up it whenever I can in the IDEs I use.
For JetBrains’ IntelliJ IDEA I use Long Cao’s Monokai colour scheme. Grab the XML file and drop it, on Windows, in your %HOMEPATH%\.IntelliJIdea11\config\colors directory. Restart IDEA and the Monokai colour scheme ought to be present in the dropdown box under File » Settings » Editor » Colors & Fonts » Scheme Name.
Setting up Eclipse 4.2 as I like it
Download Eclipse 4.2 Classic 64-bits version from the Eclipse website. Extract the contents to a location, such as C:\Eclipse. Adjust the eclipse.ini in that directory according to my post in order to pin it to the taskbar.
Next, within Eclipse, go to Window » Preferences » Install/Update » Available Software Sites » Add... and add the following URL under something like “4.2-M builds”: http://download.eclipse.org/eclipse/updates/4.2-M-builds. After adding you can hit Reload to reload the information from the website. Exit all windows through pressing OK. Then follow up by going to Help » Check for Updates and you will most likely get an Eclipse SDK update right away. Accept the licensing terms and wait until it downloaded and installed everything and restart Eclipse.
Go to Help » Install New Software... » Work with, select the Juno entry and from the resulting list of software select General Purpose Tools » Marketplace Client followed by Next » Next, accept the license and Finish. Restart Eclipse when done. Now under Help is an entry called the Eclipse Marketplace.
Open the Eclipse Marketplace and search for and install the following: “code recommenders”, “MercurialEclipse”, “mylyn” (not selecting the Bugzilla connector). It might ask if it is OK to install unsigned content, acknowledge it.