The Dropbox Breakin

Much is being made of the supposed Dropbox break in. Several users reported that they started receiving spam at email addresses that were only used with their Dropbox accounts. Dropbox, to their credit, immediately launched an investigation and brought in outside investigators to aid in their analysis.

The results of that investigation pretty much boil down to:

  • Most of the accounts were compromised because users had used the same passwords at other sites that were later compromised, and
  • A Dropbox employee, whose account was compromised in the same way, had stored an internal Dropbox document in the system that contained further email addresses.

The press, of course, was quick to compare this to the LinkedIn exploit that resulted from very poor security practices on LinkedIn’s part. But how, exactly, is Dropbox to blame for this? Yes, they have an employee who did an extremely stupid thing but how are they supposed to guard against users reusing their credentials? All in all, Dropbox was taking security seriously and doing everything right. They have since started offering optional two-factor authentication and a page that allows users to track logins to their accounts.

To my mind, the real blame belongs with the users who couldn’t be bothered to use unique passwords. This does include the Dropbox employee who, one hopes, had been admonished, terminated, or otherwise suffered the application of the clue bat. As I wrote recently, password reuse is endemic and those who are guilty of it deserve no sympathy when the real world exacts its revenge.

And, by the way, let me say again: if you store sensitive data in the cloud you better encrypt it. Dropbox is, of course, responsible for the action of their employees and one hopes that this incident will encourage them to make sure these employees aren’t doing things that endanger their customers. Still, the user is ultimately responsible for safeguarding their data. That means that they should assume that screw ups will happen and should therefore take actions to ensure they aren’t affected when they do.

Posted in General | Tagged | Leave a comment

Tips for Using Emacs Lisp

Nic Ferrier has a nice post entitled Tips on Emacs Lisp programming. The post has been mentioned by many of the Emacs aggregators but it’s a nice post and worth a shout out.

Ferrier takes the position that Elisp is a nice programming language and useful in many situations that are separate from driving the editing environment. That’s a position that I certainly agree with. Emacs provide a rich environment that can make many disparate tasks easy to accomplish.

Ferrier’s tips are not concerned with the minutiae of actually writing Elisp in the way that, say, Xah Lee’s Elisp tutorial is. Rather, he deals with might be called “meta-issues.” How to find example code; how to name your functions and variables in the absence of a module system; autoloads; tests; documentation; writing scripts; and EIEIO for objects.

As I said, this is a nice post and if you (even occasionally) write in Emacs Lisp it’s worth a few minutes of your time. I heartily recommend it.

Posted in Programming | Tagged , | Leave a comment

Prompting for User Input with Elisp

Xah Lee has a nice tutorial on getting user input with Emacs Lisp. Most Elisp programmers are aware of the interactive control strings for this purpose and most of us probably use that for most occasions requiring user input:

(defun test-input-func (msg)
  (interactive "sEnter Message: ")
  (message "Your message was: %s" msg))

The interactive form supports the input of many type of data as documented in the built-in info documentation and also the Emacs Lisp Reference Manual.

The nice thing about Lees tutorial is that he mentions the rarer but sometimes useful functions that also accept user input. These are handy when you need to get data from within a function that is not (necessarily) an input parameter. These functions are:

 
Function Use
read-string Read input as a string
read-file-name Read input as a file name
read-regexp Read input as a regular expression

An additional benefit of these functions is that they support the history mechanism and that read-regexp doesn’t need the escaping that representing regular expressions as strings usually require.

Head on over to Lee’s tutorial for all the details. If you do anything other than very simple Elisp, this is stuff you need to know.

Posted in Programming | Tagged , | Leave a comment

A New PDF Version of SICP

Long time readers know of my love affair with Abelson & Sussman’s Structure and Interpretation of Computer Programs. I regard it as certainly one of the best and arguably the best computer science books ever written. MIT Press, in a gesture of public service long before such things were common, made the book publicly available and, along with the video lectures that Abelson and Sussman gave at HP, it serves as an invaluable resource to anyone with the wit and energy to take advantage of it.

Now, thanks to the efforts of Lytha Ayth and Neil Van Dyke, a new PDF of the book has been derived from the original HTML sources that MIT Press made available. Take a look at this announcement from the SICP site to see what a difference real typesetting makes. For a concrete example of the difference, take a look at Exercise 1.2 from the original HTML source and the new PDF version. The HTML source is unreadable while the PDF is perfect.

It’s really great that this wonderful resource continues to be made available in better and better formats. We all owe those who brought it to us a huge load of thanks.

Posted in General | Tagged | Leave a comment

Building ELPA Packages

I’ve written about ELPA from the user’s viewpoint a couple of times. If you’re an Elisp developer and want to get your project into ELPA or Marmalade, Nic Ferrier has a nice post that details the steps. This is a good resource with details that I haven’t seen anywhere else.

Well worth a look if you’re considering contributing some Elisp code and want to turn it into an ELPA package. I expect that this will become more and more important as people start using the ELPA facility. I know that I’m already trying to get all my add-ons through ELPA and I predict that more and more folks will be doing the same.

Posted in General | Tagged | 1 Comment

Twenty Years of Vim

Ars Technica has a nice article on the twentieth anniversary of that other editor. Worth a read even if you aren’t a vi(m) enthusiast. One fact that I didn’t know—even after years and years of being a vi/vim user—is that the hjkl keys were chosen for cursor navigation because the ADM-3A terminal on which Bill Joy developed vi had arrows on those keys. The fact that they turned out to be an excellent choice for efficiency reason turns out to be an accident of history.

Even though I’ve moved on to the one-true-editor, I was a vi user for a long time and vim was certainly the best of the vi siblings.

Posted in General | Leave a comment

Scheduled Outage

Irreal’s hosting provider has notified me that the site will be down for scheduled maintenance on August 4th, from 12:01am to 4:00am EDT (UTC-0400).

Posted in Administrivia | Leave a comment

Malware Prophylaxis

After last week’s malware outbreak at Irreal I’ve been thinking about ways to prevent another episode. For those who haven’t been following along, someone managed to add a line of obfuscated PHP to the index.php file that gets things going when someone visits the Irreal blog. For the technically inclined, the details are in my Anatomy of an Exploit post.

The number one thing I’ve resolved to do is keep WordPress up to date. Although I can’t be sure, I suspect that the attacker gained access to index.php through a WP vulnerability so it makes sense to keep up with the latest patches. I’d been lax about that because irrational paranoia requires me to back up the database whenever I do an upgrade and that’s a bit of a pain with my setup. It’s not, however, nearly as big a pain as trying to get the site clean and convincing Google that they should stop flagging it as a malware purveyor.

One of the difficulties I had when scrubbing the site was looking for infected files. As it turns out, only index.php had been affected but I couldn’t be sure of that until I’d done a thorough survey of the site looking for the injector signature. To make that easy if I have occasion to do it again, I have a backup of the entire irreal.org site. Most of the files will be static so it should suffice to look for changed files. Most of those will be log files so checking only changed files should simplify things considerably.

There used to be a Linux utility that went through the file system and took an MD5 signature of each file so that you could check for corruption on a regular basis. Following that idea, I can periodically pull a snapshot of the site back to my local network, generate MD5 signatures on it and the my original backup, and diff the results to find files that need examination.

I thought of writing some Elisp to do this but that’s really overkill. All I really need to do is

Ctrl+u Meta+!find -P . -type f -exec md5 {} \;

to get a list of all the files and their MD5 signatures into an Emacs buffer. Then I can compare this against the saved list using Ediff right from Emacs.

I’d be interested in any other idea that readers have to help me keep things secure. Irreal runs on a hosting service so I don’t have much control over site security other than using strong passwords and keeping WordPress up to date. If you’ve got any other ideas, please leave a comment.

Posted in General | Tagged , | 5 Comments

Does Anyone Really Think This Is A Problem?

Oliver Reichenstein over at the iA has a strange post/article positing that nested directories are hard to understand. Reichenstein celebrates the iOS/Mountain Lion approach to file systems in which directories can be at most one level deep (and even that is too much, he believes). Leaving aside his misrepresentation of the actual situation in Mountain Lion, I’m really nonplussed by the idea that traditional file system architecture is somehow unnatural or hard to understand.

Reichenstein claims that multilevel directories are a geek invention that can only be understood by geeks and that even they don’t really understand them. I’m confused because I’ve never had the slightest problem understanding the idea and neither have any of the non-technical people I know. To me, it seems like a natural way to organize data and really isn’t any different, in principle, from an outline, something that we all learned to deal with in elementary school.

So my question, dear readers, is do you find nested directories hard to understand or unnatural? If you do, please leave a comment and let me know what the problem is.

Afterword: After writing this post I came across this post by Thom Holwerda over at OS News that expresses the same confusion over Reichenstein’s article. Like me, he finds the traditional directory architecture natural and useful.

Posted in General | 6 Comments

Syncing With Git Repositories

Last month, I wrote about how I keep my two main machines in sync using git and how, after doing a git pull, I use a bit of Elisp to automate the reverting of my open buffers. After automating the reversion of buffers, I noticed that pulling all my repositories was also a pain. I had been just pulling the repository that I was going to use but that meant it was easy to forget which repositories were up to date and get things out of sync.

I decided to write a quick script to pull all repositories at once. That way I could just run the script when I began work on one of the computers and be sure that everything was up to date. Here’s the pull-repos script:

#! /bin/bash
# -*- mode: sh -*-
REPOS="/Users/jcs/org /Users/jcs/medical /Users/jcs/tax /Users/jcs/.emacs.d"
for r in $REPOS
do
    cd $r
    pwd
    echo "========================="
    git pull
    echo
done

There’s nothing exciting here, of course. Most of the script is involved with outputting information as to what repository is being pulled.

The pull-repos script is already a big time saver but to really automate things I made it callable from Emacs and folded in the revert-all-buffers functionality.

(defun sync-repos ()
  "Pull from git repos and then revert all buffers."
  (interactive)
  (switch-to-buffer "*SYNC*")
  (goto-char (point-min))
  (shell-command "/Users/jcs/bin/pull-repos" "*SYNC*")
  (revert-all-buffers)
  (end-of-buffer)
  (insert (format-time-string "%Y-%m-%d %T\n"))
  (insert "Buffers reverted"))

Now I just call sync-repos and all my repositories are updated and all my buffers are reverted. One step when I first start using a machine: perfect.

Posted in General | Tagged | 7 Comments