Security at Work

At school today, one of my classes took a trip down the hall to a computer lab. Upon logging in, I was faced with a prompt, telling me that my password had expired and that I needed to change it. “Cool,” I thought to myself, “our computer administrator actually cares about security on our school’s systems.” Clicking the “OK” button (which was my only option), I proceeded to the Change Password prompt. And it was here that I realized how dumb our school administrator had been in implementing this required password change.

At the prompt, I quickly realized that I could not use any decent passwords. Trying to use any combination of numbers, letters, and symbols (e.g., *) failed. A message telling me that my new password was invalid was the only feedback I got. Furthermore, I couldn’t log into the machine until I had successfully changed my password. Cutting the symbols out of the password, I continued to try. Again, I was greeted with failure. Were letters the only valid characters? No dice their either. I sat back, unable to change my password and unable to log in. Then it struck me. “I’ve probably got to use my phone number, don’t I?” My school has typically used phone numbers as default passwords in the past, so it seemed a likely solution. Bingo! My password change was successful, and I was finally able to log in.

Of course, using your phone number for a password isn’t exactly a great solution. Obviously, anybody that knows your phone number can log into your account, access all of your files (ignoring the fact that you’d be stupid to store any really sensitive information on a school computer, anyways), but worst of all, they are you for all the administration is concerned. So, for example, if I have a friend who knows my phone number, logged in as me and looked at some pr0n while using my account, there would be more than a little bit of trouble coming my way. Furthermore, I’d have no way of being able to prove my innocence.

With an understanding of the flaws of using my phone number as my password, I went back to try to change my password to something a little bit more secure. I tried a random string of numbers. “Invalid password change,” the screen informed me. Even passwords made of strings of ten numbers, the same number of digits that are in phone numbers, resulted in failed attempts to change my password. The only password that I could use for my school account was my own phone number.

Don’t get me wrong here, I’m all for security. Strong passwords are essential for keeping your information and identity safe from potential theft. Changing your password every so often is a great idea, as it will do nothing but make it harder to hack into your account. However, implementing a required password change and then only allowing users to change their password to a certain thing is retarded. It completely defeats the purpose of not only expiring passwords, but security in general. Even a password of abc123 would be more secure than using your phone number. Mind you, I’m not sure what else I was expecting. Our computer administrator has blocked all common webmail sites, right clicking, and even all image searches on the school computers. When we had a permissions problem one class (a file our teacher had saved on my school’s shared network server had no read privileges for students), he managed to spend a full 45 minutes trying to convert the Word document into different formants instead of just changing the permissions on the file, and never managed to solve the problem. I haven’t used a Windows machine outside of my school’s locked down systems for two years, and I’m pretty sure I could do a better job of being administrator than our IT guy.

The next time I logged in, a dialogue popped up, informing me that my current password will expire in 30 days.



It’s crazy what can be done with ASCII text and a bit of colour. Click on the following examples to see them full size:

If you’re looking to make your own ASCII art, there’s a great tool located at You can feed it images and then take the output ASCII.

LaTeX, Vim, and Line Breaks

Two of the nicer things in life are Vim and LaTeX. Vim’s a powerful, simple, modal editor, and LaTeX is essentially the greatest document preparation system in existance. Put these two things together, and they’re like Reese peanut butter cups; something even better is formed, something that is somehow greater than the sum of its parts.

Line breaks are also incredibly useful, as they vastly increase human readability. It’s very hard to read words that are broken up halfway through by the edge of your screen. Line breaks work around this problem by creating new lines in logical places, such as after words.

Adding line breaks to LaTeX files works beautifully, since LaTeX ignores single line breaks when processing your files. This makes it easy to greatly improve how readable your .tex files are. Vim has an easy configuration command to break lines around words once a certain character number is reached. But it’s inconvenient to reissue the :set tw 80 command every time you open a .tex file, and I don’t want any code to wrap in other files (as would happen if set in the .vimrc). So how can you get Vim to automagically break lines, but only in .tex files?

The answer is suprisingly simple. In your .vimrc, use the line:

au FileType tex set tw=80

That’s all there is to it. This command tells Vim to break lines around words at the 80 character limit, but only in tex files. You can replace the number 80 in the command with any other number of characters you might want to break at.

This just made the superb combo of Vim and LaTeX that much sweeter.

Mmm, awesome!

Git: My (Not Exactly) Quick Reference

I decided to post a few of the scripts and config files I have going on github, making it easier to share files between my machines.  I’m brand new to Git, so I really had absolutely no idea how it worked before I started working with github.  Essentially all of my informaition came from the great introduction to Git, Pro Git, as well as the Git man files. This information is merely compiled into one page here. This post is a quick reference for myself, but if you find it useful, then great! (Note that I work on Linux machines, so this guide is very Linux-centric)



Of course, you have to start by installing Git.  On Arch Linux, my distro of choice, this is as easy as the following:

# pacman -S git

However, this will vary depending on the distro you’re currently using. You’ll almost certainly find Git in your distro’s default repositories, but it’s not there or is outdated, you can grab the source for Git here: Git depends on curl, zlib, openssl, expat, and libiconv, so make sure that those are all installed, too.


Start by setting your name and email address. This is essential, as it is included in every single commit you do.

$ git config --global "Your Name Here"

$ git config --global

Set your prefered editor. This editor will be called when you need to type a message.

$ git config --global core.editor vim

At this time, you might also find it useful to specify a diff tool. I use vimdiff.

$ git config --global merge.tool vimdiff

If you like coloured output, use the following configuration command:

$ git config --global color.ui auto

Make sure that Git will be dealing with line breaks properly.  This should set you up so that every commit converts line endings to LF, so that they are always LF in the repository you’re working with.

$ git config --global core.autocrlf input

You might find it useful to set up a few aliases, such as the following:

This makes it easier to remember the command to remove files from the staging area.

$ git config --global alias.unstage 'reset HEAD --'

Using the command “git last” will give you information about the last commit.

$ git config --global alias.last 'log -1 HEAD'

Pro Git reccomends the following for tab completion in Bash:

Download the Git source code, and look in the contrib/completion directory; there should be a file called git-completion.bash. Copy this file to your home directory, and add this to your .bashrc file:

source ~/.git-completion.bash

If you want to set up Git to automatically have Bash shell completion for all users, copy this script to […] the /etc/bash_completion.d/ directory….


Initilizing a Git Repository

To start using a Git repository, it must be started first. This is as easy as the following command:

$ git init

This starts the git repository skeleton in your current directory, however, nothing is actually being tracked yet. The following goes through the process of adding a file, and then commiting it.

$ git add

$ git commit -m 'Comment about commit'

Clone a Git Repository

Cloning a Git repository will make a copy of the entire repository on your local machine. Note that this is not just a copy of the current working version, but the entire project, including all of the history. Note that in the following example, the portion in square brackets is optional, and merely specifies a custom name for the cloned repository.

$ git clone git://location/of/your/git/repository.git [my_repository.git]

Working with a Git Repository

To check the status of files (untracked, unmodified, modified, staged), use git status.

$ git status

Whenever you want to stage a file, you have to use git add to stage the current version of that file. Once staged, the file will be part of your next commit, as is. Note that if you add a file to stage it, and then change the file again, the version that is currently staged is the version before your last change.

The command

$ git diff

can be used to see what specific changes in files have been made but have not yet been staged. This command accepts arguments. Use —-staged to show changes that have been staged and will go into your next change.

$ git add

If you don’t want git to track some files (even as untracked), use a .gitignore file to list the files. From,

Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.

The rules for the patterns you can put in the .gitignore file are as follows:

  • Blank lines or lines starting with # are ignored.
  • Standard glob patterns work.
  • You can end patterns with a forward slash (/) to specify a directory.
  • You can negate a pattern by starting it with an exclamation point (!).

Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this case a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9]) matches any character between them (in this case 0 through 9) .

Here is another example .gitignore file:

# a comment – this is ignored
*.a       # no .a files
!lib.a    # but do track lib.a, even though you're ignoring .a files above
/TODO     # only ignore the root TODO file, not subdir/TODO
build/    # ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt

The final step is committing your changes once you are happy with what you have staged.

$ git commit

This will call upon your editor to write a comment about the commit. A comment is needed, otherwise the commit will abort. The option -v will tell you what files you are committing.

If you don’t want to bother with the staging area (useful for something like a simple edit of a file), you can simply change your file, and then use the command

$ git commit -a -m 'comment about the commit'

To delete a file, first remove it from the working directory, and then stop tracking it.

$ rm <filename>

$ git rm <filename>

You can use

$ git rm --cached <filename>

to remove a file from your staged area, but keep it in your working tree.

To move a file, use the mv that is built into git:

$ git mv <initial_file> <renamed_file>

Viewing the Commit History

The command

$ git log

is used to view the commit history. It accepts flags. -p will show the diffs of the commits. –n can be used, where n is a number, to limit to n number of entries. —-stat will show some abbreviated stats for each commit. There are many different ways to show the log history. To see all of the options available, check the Git documentation with:

$ man git-log

Undoing Changes

Be careful when undoing things. Git is designed to be fairly failsafe, but you can lose data when undoing changes. You can’t always undo these undos, so proceed with caution.

If you need to change a commit for some reason (say you forgot to add a file into the commit), you can use

$ git commit --amend

to reupload your current staging area and merge it with your last commit.

Say you accidentally move a file into the staging area when you didn’t mean to, or want to unmodify a modified file. Instructions on how to undo changes are present in the output of:

$ git status

Working with a Remote Repository

While you’re working with git, you’ll in all likelyhood have be working with remote repositories. While I’m working with files, I have my local version, and I work with my remote repository on the github servers. To see your remote repositories, use:

$ git remote -v

To add a remote repository and give it a name that you can easily reference, use the command git remote add. In the following line of code, replace the square brackets with their respective fields.

$ git remote add [name_for_repo] [url]

If you want to get more information about a certain remote repository, use the command:

$ git remote show [remote_repository_name]

You can pull information out of remote repositories. The following command will pull any new data that you don’t have into a new branch on your machine.

$ git fetch [remote_repo]

Note that you can set up git pull to somewhat automate fetching new information from remote repositories.

When you want to share your data with others, use git push to push your data upstream.

$ git push [remote-name] [branch-name]

Tagging Things

Tagging is very useful for keeping track of things like release versions. To see all of a project’s tags, use the command:

$ git tag

There are different types of tags that are available for use. Lightweight tags are simply pointers to a certain point in the history of a project. Annotated tags contain information about the tagger, date, the tagger’s email, contain a message, and are checksummed. Signed tags contain a GPG (Gnu Privacy Guard) signature. Annotated tags are generally reccomended. You can create an annotated tag using:

$ git tag -a v[version_number] -m 'comment about version'

If you want to create a lightweight tag, use no flag. To create a signed tag, use the flag -s.

To see information about a tag, use the command:

$ git tag show [tag]

You can tag a commit after the project has moved on. View the history of the commits with a command like the following one, and then use part of the checksum to tag a particular commit.

$ git log --pretty=oneline

0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile

$ git tag -a v1.2 9fceb02

Tags are not by default pushed to remote servers. To do so, you must specify them, much like remote branches.

$ git push origin [tagname]

If there are a large amount of tags you want to push, use the command:

$ git push origin --tags


Local Branches

Branches can be created with the command:

$ git branch [branch-name]

To delete a branch, issue the same command, but with the flag -d.

$ git branch -d [branch-name]

To switch to a previously created branch, use the checkout command.

$ git checkout [branch-name]

Merge you changes with the command merge. Issue the command from the branch you are merging into, and let [branch-name] refer to the branch that you are pulling in for the merge.

$ git merge [branch-name]

Sometimes, merges don’t go smoothly. If you have a problem with a merge, you have two options:

  1. View the output of $ git status The file(s) that barfed during the merge will be listed as “unmerged”. You can manually edit the files to resolve the merge issues. Find the section(s) that Git has changed (it will list what the file is like in both branches at this point of the file), and then edit it down to what you want the end result to be. After you finish, run
    $ git add [filename]
    to stage the file(s), marking them as resolved.
  2. Use a diff tool to assist in dealing with the conflict.
    $ git mergetool
    Once you’ve done so, you can tell the script that you resolved the conflict.

Once you are done with your changes, run

$ git status

to ensure that everything has been resolved. Once you are happy, run

$ git commit

to finalize the merge.

Unlike the branches previously discussed, remote branches exist in remote repositories.


All of the information on this page was pulled from two sources: The wonderful book Pro Git, by Scott Chacon; and the Git man pages. Sections that I’ve pulled directly from the sources are in block quotes and attributed in the surrounding area. Everything else somehow came from one or both of these two sources, but with the surrounding writeup written by me to paraphrase the source.