Friday, September 26, 2014

Shellshock Bash Exploit in Windows

Searching for bash.exe in Windows, I found several instances of Bash, all of which were vulnerable to the Shellshock exploit. Anyone who develops programs or web applications in Windows may have one or more instances of Bash. Anyone who uses Git in Windows almost certainly will have at least one.

First, I used the Windows File Explorer to search each disk drive for instances of “bash.exe”.

Then, using some advice from Scott Simpson at, I ran the following commands:

cd <directory containing bash.exe>
bash-3.1$ env x='() { :;}; echo vulnerable' bash -c "echo done
done running

I also tested “sh.exe” the same way, in case it happened to be just a copy of “bash.exe”.

Here are the places where I found “bash.exe” on my development machine. You may find similar ones on yours.

1.) C:\Program Files (x86)\Git\bin\bash.exe
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)
    C:\Program Files (x86)\Git\bin\sh.exe
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)
2.) C:\DevKit\bin\bash.exe
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)  
3.) C:\MinGW\msys\1.0\bin\bash.exe
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)
    GNU bash, version 3.1.17(1)-release (i686-pc-msys)
4.) C:\Users\<user>\AppData\Local\GitHub\PortableGit…\bin\bash.exe
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)
    GNU bash, version 3.1.0(1)-release (i686-pc-msys)

Every one of these turned out to be vulnerable, even though most had been installed recently. I haven’t yet found a Windows version of “bash.exe” patched to prevent the Shellshock exploit.

In practice, my system probably isn’t actually vulnerable to this particular exploit since I don’t normally run any server that executes CGI scripts, plus my firewall prevents incoming requests on the ports used by my servers in development mode. It’s only a development machine, not a production one.

An additional precaution is that none of the paths in my default Windows PATH variable permit bash.exe to be run. You easily can test this on your own machine: Start the Windows command console, cmd.exe. and type “bash”. If it runs, probably not a good thing. If  it fails to run, so much the better.

There is a patch available for other operating systems that is discussed here:

Thursday, September 18, 2014

Git Cheat Sheet

Here are just a few Git commands that you will want to know if you are going to use Git to manage source file versions.

git help
Gets a list of all the git commands.

git help <command>
Gets help for the given command.

git init
Initializes a directory with a local repository so that you can start using git there. No need to use this command if you are going to clone an existing remote repository (see below).

git remote -v
Lists remote repositories for current project.

git clone <repository> <target-directory>
Gets a copy of the source code from the given repository and puts
it in the given directory. An example repository would be 
The <target-directory> is optional. If you omit it, git will put the cloned code in a subdirectory named after the repository (e.g., ‘node-redis-queue’ in the above link).

git pull –no-commit origin
Gets the latest changes from the given remote repository and merges them with the  local source code. “—no-commit” specifies to leave the changes uncommitted so that you can examine them with “git diff”. By default the changes automatically are committed.

git status
List staged files and all other changed files.

git add <filename>
Stage the given file, which means it is ready to commit.

git commit -m "My comment"
Commit the staged files to the local repository.

git commit -am "My comment"
Adds and commits all modified files to the local repository. Ensure you have your .gitignorerc file set up correctly before using this shortcut.

git commit --amend
Need to fix the mistake you made in the comment for the latest commit? This brings up your default editor, where you can change the comment in the first few lines, save and then exit the editor.

git checkout <file-name>
Gets the latest copy of the given file out of the local repository and may overwrite the file of the same name in your working directory. You can use this to discard local changes you no longer want, provided you haven’t yet staged or committed them.

git reset <file-name>
Need to discard some local changes that you’ve already staged (e.g., via git add) but not yet committed ? This is how to do it.

git reset --hard
Need to discard all local changes whether you have staged them or not ? This is how to do it.

git checkout -b <branch-name>
Create a branch with the given name and switch to that branch.

git checkout <branch-name>
Switch to the code in the given branch, which must already exist. Very fast. But ensure you have committed your current code changes before switching.

git push --set-upstream origin <branch-name>
Use this the first time you push some code changes to your new branch. It creates an upstream branch. It sets up the branch to track the remote branch from origin.

git push origin <tag-name>
Pushes the local changes (optionally identified by the tag) up to the remote repository identified by origin. The tag-name is optional.

git push –tags origin master
Pushes the local changes and all tags up to the remote repository identified by origin and makes them part of the master branch.

git merge -X theirs <branch-name>
Merges the given branch into the current branch, preferring changes from the given branch. If “-X theirs” is omitted, then preference is given to the current branch.

git fetch origin master
git reset --hard origin/master

git pull origin master
Want to throw away your already committed local changes in the local master branch? The first command fetches the commits from the remote repository. The second command positions your working copy to the tip of the master branch. All your local commits are discarded. The third command ensures you really have all the latest master code. Of course, you can substitute a different branch name for ‘master’. Doesn’t disturb the other branches in your local repository.

git push --tags
No tags in your remote repository? Then, use this command to push all of them there.

git tag -l
Lists the tags in the local repository.

git tag <tag-string>
Tags the files in the local repository with the given tag.

git tag -d <tag-string> <optional-file-name>
Deletes the given tag (optionally from the given file).

git log <file-name>
Lists all commits in the local repository. The file-name is optional. If present, then you get the log just for that file.

git show <branch-name>~<n-back>:<file-name>
Shows the state of the given file <n-back> commits back. For example:
git show master~1:package.json
shows the previous revision of the file package.json in the master branch.

git show <tag-string> – <file-name>
For example:
git show v0.1.3 -- package.json
which is similar to
git diff v0.1.2 v0.1.3 -- package.json.
but also shows commit comments, which is quite useful. The file name may be omitted. For example,
git show v0.1.3

git diff <branch-name>
Compares the current branch to the given branch.

git diff <branch-name>~<n-back>:<file-name> <file-name>
Need to compare a given file with a revision previously commited? For example,
git diff
specifies to compare the revision 3 revisions back with the current local version of

To compare two previously committed revisions, one would do something like:
git diff

git diff <branch-name>~<n-back>:<file-name> <file-name>
Need to compare a given file with a revision previously commited? For example,
git diff 
compares the revision 3 revisions back with the current local version of

To compare two previously committed revisions, one would do something like:
git diff

git diff <tag> – <file-name> 
Compares the given file revision having the given tag with the current local version of the file. For example,
git diff v0.0.3 -- package.json
compares the package.json file having tag v0.0.3 with the current local version of

To compare two previously committed revisions having different tags, one would do something like:
git diff v0.0.2 v0.0.3 -- package.json

git update-index --chmod=+x <file-name>
Do you find after a deploy that git did not have the correct permissions for one of your files? You can change the executable permission this way. Use “+x” to set execute permission or “-x” to remove it.

Saturday, August 30, 2014

Using JSHint with the Jasmine test framework

If you develop JavaScript code and use the Jasmine test framework to test your code, you probably have found that you get a lot of warnings in the test specs (such as blahBlahSpec.js) when checking your code with JSHint.
It turns out there is a fairly simple way to turn off all those warnings that relate to globals introduced by Jasmine.  The predefined globals can simply be added to the .jshintrc config file under the "predef" option. For example:
  "bitwise":     true,
  "camelcase":   true,
  "curly":       true,
  "immed":       true,
  "latedef":     true,
  "newcap":      true,
  "noarg":       true,
  "noempty":     true,
  "quotmark":    "single",
  "undef":       true,
  "unused":      true,
  "strict":      true,
  "debug":       true,
  "evil":        false,
  "node":        true,
  "predef": [

The .jshintrc file can reside in the top level of your project or in a parent directory, since JSHint will search up the directory tree for that file.  Happy code checking!
1. Introduction to the Jasmine test framework.
2. JSHint configuration documentation.

Monday, May 26, 2014

Windows 8–Strange but Useful

A few days ago, my desktop computer motherboard died. Since a new computer cost only a little more than a new motherboard, it seemed practical to buy a new one. I put my old video card into the new computer (first big mistake) because it had dual ports and thus could support two monitors. The new computer, which came with Windows 8 installed, mostly worked and the video looked really good, but with some strangeness: on bootup, it could take five or ten minutes for the screen to become visible, though it clearly finished booting much earlier; and also Microsoft Flight Simulator X, an older game, couldn’t successfully do any DirectX to the display. DirectX is required in order to see the animation of the game. Reverting to the integrated display adapter that came with the computer fixed these problems and, conveniently, it also supported two monitors.

But, what is really strange about Windows 8 is its user interface. I know I’m not the first person to write about this, but it needs to be said. Several decades ago, Microsoft developed a Windows user interface guidelines document, which contained many good ideas. Among them, if I recall correctly, were three really useful ones:

  • Expose all important functionality somewhere in the interface (e.g., menu item, icon, or other widget.
  • Never implement hidden features – that is, features that require some non-obvious way to get to them.
  • Minimize the number of steps it takes to perform a given function.

Windows 8 violates both of those in quite a number of ways. I don’t have time to go into all of them, but here are a few examples:

  • The start screen has many items on it and may be much wider than the physical monitor screen. In a non-touch screen configuration, one traverses the Start screen (e.g., to see stuff out of view off to the right) by scrolling using the mouse wheel. Nothing on the screen says to use the mouse wheel for this purpose.
  • In the Start screen, there is a down arrow, the purpose of which is entirely obscure to a new user. If one clicks it, a list of all install apps (I think) may be seen. This arrow is not really evident unless the user moves the mouse pointer over the Start screen.
  • There is a useful menu of functions (Search, Share, Start, Devices, Settings) that one only sees by moving the mouse pointer to the upper right or lower right corner of the Start screen.
  • It can take three clicks and several mouse wheel scrolls to run an application that one has not pinned to the Start screen.
  • Many Windows 8 apps don’t show an ‘x’ in the upper right corner, so it’s not evident how to close a program. One closes a program by clicking the ‘x’. However, the ‘x’ only is visible if the mouse pointer is moved to the top edge of the app window. A very non-obvious feature.

Well, I could go on, but you get the idea. Certainly, I eventually will get used to these quirks, but I wonder what happened to Microsoft’s user interface guidelines. Did they change them?  Did they abandon them? Did they simply fail to refer to them? The result is an interface that many users find displeasing and frustrating.