Skip navigation

Tag Archives: File hosting

Getting Things Done : A Cobbler’s Tale

Starting sometime mid-year in 2011, I began having more ‘stuff’ to do than even my eidetic memory could help with. It’s not that I forgot things, per se, but the ability to mentally recall and prioritize work, family, personal and other tasks finally required some external assistance and I resolved to find a GTD system by the end of January.

Being an OS X user, there are great choices out there (both of those have iOS sister-apps, too). However, I’m not just an OS X user. As I was saying to @myrcurial (and even @reillyusa) the other day, I dislike being locked in to proprietary solutions. Plus, the $120 price tag for OmniFocus (OS X + iPad) seemed like a king’s ransom, especially since I am also an Android user (OmniFocus only has an iOS app) and pay for both Dropbox and various virtual hosts. Believing that I still have some usable skills left, I decided to — as @hatlessec characterized my solution — cobble something together on my own.

Once upon a time, I did maintain a .plan file (when I had sysadmin duties), but really doubted the efficacy of it and finger in the age of the modern web. The thought of machinating SQLite databases, parsing XML files or even digesting bits of JSON seemed overkill for my purposes. Searching through my Evernote clippings, my memory was drawn back to one of my favorite sites, Lifehacker, which has regular GTD coverage. After re-poking around a bit, I decided to settle on @ginatrapani’s @todotxtapps for meeting the following requirements (in order):

  • It uses a plain text file with a simple structure – (no exposit necessary…the link is a quick read and the format will become second nature after a glance)
  • It is Free (mostly) – mobile apps are ~$2.00USD each and if you need more than free Dropbox hosting and want a web interface, there are potential hosting costs. If you count your setup time as money, then add that in, too.
  • It runs on OS X, BSD, Windows & Linux – no platform lock-in
  • It has a thriving community – without being backed by a vendor (like the really #spiffy @omnigroup), a strong developer & user community is extremely important to ensure the longevity of the codebase. Todo.txt has very passionate developers and users who are very active on all fronts.
  • It is very extensible & integrable – I used @alfredapps to give me a quick OS X “GUI CLI” to the todo.sh commands. I built an Alfred keyword for my most used Todo.txt functions along with a generic one to bring up vim in a Terminal.app window for a free-form edit. Alfred’s shell-commands also give me @growlmac integration (so I get some feedback after working with tasks).

    I also integrated it with @geektool. I won’t steal the thunder from other GeekTool/Todo.txt integration posts (like this one). The GeekTool integration puts my todo’s right in front of me all the time on all my desktops.

    By storing my todo directory in @dropbox, it also makes syncing to my web site and mobile devices a snap.

    On my server, I have a simple cron job setup to e-mail me my todo’s at the beginning of the day (again, so it’s in front of me wherever I look).

  • It runs on iOS AND Android – again, no platform lock-in
  • There’s an optional web interface – the one I linked to (there are others) is far from ideal, but it was quick to setup and has no overt security issues. Properly protected behind nginx or apache, you should have no issues if you need to have a web version handy.

So, while the setup is a bit more than just downloading two commercial apps, it has many other benefits and isn’t too much more work if you already have some of the other pieces in place. If you want more info on the Alfred scripts or any other setup component, drop me a note in the comments.

While I’ve read about many GTD solutions and seen many user-stories of how they met their GTD needs, I’d be interested in what tools you use to ‘get things done’…

Dropbox 1.2.0 Experimental Build “Fixes” Security Issue

If you are concerned about the Dropbox design flaw exposed by the dbClone attack, then have we got a link for you!

The intrepid DB devs have tossed up a forum release which purports to fix all the thorny security issues. You can no longer just copy a config file to a separate machine to clone a filesystem and the file itself is now also encrypted. (Forum builds do not automagically download like standard Dropbox updates)

Given the fact that Dropbox did not prompt me for any credentials when I started the new version, I’m still a bit skeptical that it has truly fixed the problem. Given my schedule today, I doubt I’ll have time to poke at it before someone else does, but the thoroughness of this fix does need to be independently validated. The local Dropbox client has to be getting the encryption key/passphrase from *somewhere*, and if it’s not prompting me on start, then it’s stored online or locally and that’s a recipe for another hack.

There is nothing overt in the application bundle (looking on OS X) or quickly discernable from a dump of a few of the app’s .pyc files. Granted, a bit of obfuscation will stop the current hack and dissuade some other sophomoric attempts, but I can almost guarantee that the passphrase (or the algorithm one needs to discern the passphrase) will be found by folks.

The new build replaces your local configuration file with a new, encrypted one (now named config.dbx). I didn’t see signs of either SQLiteEncrypt, SEE, SQLCipher or SQLiteCrypt but haven’t had time to dig more thoroughly. It’s completely possible the Dropbox devs just built an encryption layer over the Dropbox calls themselves (which is not a difficult task).

Please note that forum builds are not necessarily stable and that this is a pretty major architecture change. I had no issues on OS X, but I suspect that any micro-errors in your SQLite config.db may cause some heartache if you do attempt the upgrade. Best to wait for a full production release if you do not have your Dropbox backed up somewhere.

A Fully Operational OS X dbClone

Spent some time today updating the missing bits of the OS X version of the Dropbox cloner I uploaded last night. You can just grab the executable or grab the whole project from the github repository.

The app can now backup/restore of local config, clone dropbox configs to a URL/file and also impersonate a captured Dropbox config.

Use it all at your own risk. As stated in the original post, all comments, bugs, additions, fixes etc. are welcome either here or at github.

dbClone “hack” for OS X

UPDATE: Check out the newer post on additional features.

There has been much ado of late about Dropbox security with one of the most egregious issues being how easy it is to surreptitiously “clone” someone else’s Dropbox by obtaining just one piece of data – the host id – from the Dropbox SQLite config.db.

Moloch built a Windows & Linux impersonation/cloning utility in Python that was/is meant to be used from a USB/external volume. The utility can save the cloned host id to a local file and also has the capability to use a simple HTTP GET request to log data to a “mothership” web site.

Since many Dropbox users use OS X (including me) I didn’t want them to feel left out or smugly more secure. So, I set about creating a native version of the utility.

This release is not as feature-rich as Moloch’s Python script but it won’t take much more effort to crank out a version that duplicates all of the functionality. “Release early. Release often.” as the kids these days are wont to say.

You can find the source at its github repository. When building it or just downloading & running the executable (see below), you should heed the repo’s README and take care to change the following items in the application’s Info.plist property list:

  • MothershipURL – this is the URL of the remote host you want to store the cloned info to. It defaults to somesite.domain/mothership.php to avoid accidentally sending your own Dropbox data to a remote host. PLEASE NOTE that you will need to get the mothership.php script from the original Windows/Linux code distribution as I have not asked for permission to distribute it here. You can grab the original dbClone.rar directly from here: dl.dropbox.com/u/341940/dbClone.rar (I love the irony of it being hosted on Dropbox itself).

    ALSO NOTE that there’s no need to modify the application’s property list if you don’t mind typing in a URL each run. I eventually plan on making this a separate property list file that allows for multiple URLs so you can select it from a drop-down (and still type a new one if you like).

  • LogFilename – just include the filename you want to use when storing the cloned info locally if you do not like the default (it’s the same as Moloch’s – "GroceryList.txt"). It defaults to the top-level of the mounted volume (the original Linux & Windows dbClone was meant to be run from a USB/external volume) or "~/" if running it on your boot drive.

You can use the property list editor(s) that come with Apple’s Developer Tools or use vim, TextEdit, TextWrangler (or your favorite text editor) and modify these lines appropriately:

[code]
<key>LogFilename</key>
<string>GroceryList.txt</string>
<key>MothershipURL</key>
<string>http://somesite.domain/mothership.php</string>
[/code]

If you do use the “backup” option, the current naming scheme is "backup-config.db" and it”s important to note that the program will not attempt to overwrite the file. I may change that behaviour in an upcoming release.

I tested the build on OS X 10.6.7 but the Xcode project is set to build for compatibility with 10.5.x or 10.6.x. Feedback on behaviour on other systems would be most welcome.

If you just want the executable, grab the zip’d app and give it a go.

Any and all feedback is welcome (via github or in the comments).

Backup Workflow

I was trying to convey my backup workflow/setup to @joeday in 140 and it just wasn’t working very well. Twitter – as one might expect – is not exactly the place for detailed technical discussions, but it does provide fertile ground to spark ideas and dialogue. I told @geekshui that I’d blog my setup and that turned out to be just enough of a catalyst to force me to iron out my strategy for rud.is and future (if any) non-cooking/family blogging.

Background

I’m [still] a die-hard OS X user, despite the increasing gatekeeper motif Apple is sporting these days. My main computer is a MacBook Pro which I would stupidly run back into a burning building to rescue. Everything is on it. Everything. I digitize receipts, house our multimedia, spin out VMs like a DJ, create, compose, torrent, rip, zip and hack from it. Consequently, ensuring my data is available is kinda important to me.

I’ve been around computers long enough to have learned some painful lessons from four simple characters: MTBF. Drives break. Electronics fail. It’s an undeniable fact. The only way to recover from these failures is to have a good strategy for keeping your data available.

Strategy #1: Backups

While hard to digest on Twitter, my backup strategy is pretty straightforward. I use Time Machine for OS-managed full system backups. I rotate these between two large (1TB & 2TB) hard drives and I retire one large hard drive each year (MTBF…remember?). This gets me individual file recovery pretty quickly over a decent time period and a bit of hardware piece of mind.

I also have two 2.5″ IEEE 1394 drives that I SuperDupe/CarbonCopyClone images to every time Apple issues a 10.x.y update. Again, I rotate between since I really don’t trust drive manufacturers. I haven’t relied on TrueCrypt for a while (which would make for an ugly workflow) for system volumes, but it’s easy to clone disks that have FileVault protected data as long as you do so from an account that does not use or rely on FileVault data.

Both Time Machine and the drive cloning can occur while I’m sleeping, so no workflow is impacted.

Strategy #2: Dropbox

I have to start by sharing just how much I <3 Dropbox. I don’t use the free service as I grew weary of keeping within the paultry limits. Getting a paid sub to it provides more than just freedom from minutiae. I now get (as long as they have no hiccups) full recovery back as far as I want in the event I do actually lose a file or two. I have Dropbox configured on my MacBook Pro, a home Windows machine and a home Linux box. This means that even if I lose the drive on my Mac, I can get some of my non-sensitive data back from one of the other Dropbox-enabled systems (which is much faster than recovering from backups). It also means that I can get right back to work on a different system – as long as I have not used an OS X-specific program.

I could rant for quite a while about Dropbox, but it should be pretty obvious why this is part of of my backup strategy.

Strategy #3: rsync.net

While Dropbox houses non-sensitive data offsite (again, assuming no service hiccups), there is a subset of my information that I do want housed off-site in the event there is a catastrophic issue with our abode. For that, I have been using rsync.net since it’s inception. They provide outstanding customer support, have a unique view and practices around warrants and fully understand the needs of technical users concerned about availability and privacy.

There are some other things we do to ensure a refresh of the content on media drives that get hooked up to our PS3 or displays, but the the above three steps are how I ensure that I always have access to the data that enables my workflow.