MarsEdit 3.5.1 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

When I released MarsEdit 3.5 a few weeks ago, it included some very significant overhaul to MarsEdit’s handling of rich text formatting, including new support for customized formatting macros in Rich Text mode.

Given the large number of changes, I was not too surprised that a few annoying bugs snuck in as well. In particular, it became unreliable to apply some formatting options like heading and block quote in Rich Text mode. I took the opportunity while fixing those things to take care of a bunch of other little gotchas, including some more compatibility tweaks for the forthcoming Mountain Lion 10.8 release.

• Fix the preview window to recognize and substitute template placeholders in the section
• Fix a bug with Squarespace and Expression Engine not prompting for username/password on new blog
• Restore ability to set “Warn when no title” option on Blogger blogs
• Fix a bug that prevented some blog-configuration options from being selected after switching system type
• Restore ability to start a Header or Blockquote before typing content
• Pressing return twice to exit Preformatted works again
• Improve support for future releases of Mac OS X
  • Address an issue with icon view when resizing the Media Manager window
  • Avoid crashes caused by conflicting system libraries

MarsEdit 3.5 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed MarsEdit customers.

Rich-Text Formatting Macros

When MarsEdit 3.0 was released two years ago, it marked a major transformation in the product. Previously the app was completely focused on providing a means to edit blog posts in HTML, Markdown, or other text based markup languages. With 3.0, I added the long-requested “WYSWIYG” rich-text editing that many customers prefer when working with web content.

But given the considerable work to achieve MarsEdit’s rich text editor, there were some loose ends. One of those loose ends had to do with the very powerful formatting macros available in plain-text mode. These formatting macros are completely user-customizable and allow users to add their own markup templates for virtually any kind of purpose, filling in the details with values from the editor such as the selection, the pasteboard, etc. Various complexities prevented this powerful formatting macro concept from being available to users in rich-text mode.

With MarsEdit 3.5, custom formatting macros are finally available in rich-text mode. I have already discovered some edge cases that don’t work perfectly, but for inserting arbitrary HTML snippets or “wrapping” the selected text in the rich editor with a particular style, these custom macros are very useful. Starting with this release, you can also customize the keyboard shortcut for any formatting macros, whether they are built-in or custom.

The possibilities are limitless, but to illustrate with a simple example, imagine you commonly find yourself wanting green text in your blog posts. The following formatting macro will take whatever text happens to be on the pasteboard, and insert it into the edited post with HTML markup for coloring it green:

Lion Full-Screen Mode

Shortly after Lion 10.7 was released, I added nominal support for full-screen mode to MarsEdit. The problem was, it wasn’t very useful for real-world writing scenarios. My mistakes? I merely zoomed the post editor window to occupy the entire height and width of the screen. Most users found this awkwardly huge editor space impossible to work comfortably in, so found themselves avoiding the full-screen mode, even though they liked the idea in concept.

I made a relatively simple tweak for 3.5 that should improve things dramatically. When you enter full-screen mode on Lion, the current width of your editor is preserved, and only the height is zoomed to occupy the full screen space on your Mac. Here’s a shrunken example for the MarsEdit post editor I’m using to write this entry:

Of course, it’s easy to imagine a number of ways that full-screen could be even more improved. Incorporating the preview window optionally into the space, offering to hide the Title and other fields, etc. But this is a step in the right direction.

Tumblr Tweaks

I won’t mince words: as a developer, I have a love-hate relationship with Tumblr. The service is immensely popular but in many regards their API (even the newer one, which I admit I’m not using yet) falls short when it comes to providing the services MarsEdit users expect. For example, it’s extremely frustrating that it remains impossible to upload images apart from photo posts. Over the years since I first added support for Tumblr, I have often wondered how much effort I should bother put in, when the service doesn’t seem too interested in catering to offline editing clients. But that doesn’t excuse the fact that many important features are supported by the API, and I haven’t had time to implement support for them yet in MarsEdit. I’m starting to chip away at those now.

MarsEdit 3.5 supports publishing entries to Tumblr as server-side drafts. I decided to tackle this one now because it’s one of the most frequently requested features from my Tumblr-using customers, and because it’s possible to implement correctly with Tumblr’s API. I tried to tackle “queue” type posts with this release as well, but ran into issues with the API that forced me to put that back on the shelf for now.

I also made some minor adjustments to the post editor UI for Tumblr to prevent some issues with Quote and Chat style posts.

Everything Else

I managed to fit a lot of little fixes and nagging shortcomings for this release. It’s hard to quantify all of those little details with much more than a bullet line in a list, so I’m listing the complete list of changes below. Hopefully you’ll just find this release to feel overall more finished and refined than before, and I hope to continue that trend on into the future.

• Highlighted Enhancements
  • Improved support for Lion full-screen mode
  • Custom Formatting Macros now work in Rich Text mode as well as HTML mode
  • Support for editing Tumblr Draft posts
• Post Editor enhancements
  • A number of improvements to Rich Text editor to address minor formatting bugs
  • Unified Formatting Macro menu for HTML and Rich Text modes
  • Draggging an image to the post editor now causes inserted image to go to expected target location in text
  • Fixed performance issues that could cause very slow typing in some configurations
  • Fixed keyboard-based text selection in the HTML editor to avoid getting stuck on line endings
  • Fix a slight mismatch in background color between Rich and HTML Text editing modes
  • Work around hanging issues with External Editing in some apps
• Tumblr-specific enhancemeents
  • Added support for server-stored Drafts
  • Fixed Word Count feature to work properly with Tumblr Quote and Chat posts
  • Revised Tumblr interface for Chat-style posts to prevent formatting problems
• Other changes
  • Added support for browsing Lightroom 4 libraries
  • New support for unicode characters in URLs
  • Bug fixes for improved Media Manager reliability
  • Fixed an issue where uploaded attachments would fail without prompting for password on authentication errors
  • Added support for authenticated proxy servers
  • Prevent a crash that occurred when working with Blog.de system’s categories
  • Improved XML sanitizing to increase compatibility with malformed blog content
  • Fix a bug that prevented locally added tags from becoming part of the tag-suggestion history

Black Ink 1.5 is now available on the Mac App Store and directly from the Red Sweater Store. This is a free update for licensed Black Ink customers.

I focused again on puzzle printing improvements for this update. Significantly, Black Ink now supports an option to position the puzzle grid on the bottom-left or bottom-right of the page. This is a more natural solving position for many people, because it allows you to keep more of the clues visible while writing answers into the grid.

Here’s a taste of how the printing configuration and preview panel looks in 1.5:

Complete list of changes:

• Support new options for printing puzzle grid at the bottom of the page
• Cleaner printing layout for fit-on-one-sheet printing
• Improve speed of printing puzzles

Tony Arcieri urges developers storing user-sensitive data, such as a passwords, not to use bcrypt (via Michael Tsai) for deriving the encryption key:

The first cipher I’d suggest you consider besides bcrypt is PBKDF2. It’s ubiquitous and time-tested with an academic pedigree from RSA Labs, you know, the guys who invented much of the cryptographic ecosystem we use today.

I was a little fuzzy on the distinction between encryption techniques such as AES, and the technology being discussed here, which is known as a key derivation function. Let’s break it down. With an encryption technique like AES you can use a large (e.g. 128 bits), difficult to guess private key to encrypt and decrypt data. But as a human, you can’t reasonably be expected to type in a random, 128-bit key in by hand when you want to access your data. The key derivation function is the code that takes your relatively easily-remembered password and derives a suitably monstrous, unpredictably random key from it. The quality and uncrackability of that key derivation is what Tony is questioning here.

I don’t know enough about encryption to have my own informed opinion about this. I tend to rely on the collective wisdom of the software industry, or on high-level service providers such as Apple, to suitably safeguard sensitive data in my apps. Tony included Apple’s FileVault full-disk-encryption in the list of technologies that use PBKDF2, which lent the technique an air of superiority in my mind. I know some of the folks behind Apple’s disk encryption, and they are careful, smart engineers.

I rely on FileVault for protection of my documents. But like most folks, I rely on Apple’s Keychain for the protection of passwords. I’m keenly interested to know if the Keychain is as secure as it reasonably can be, because I store not only my own passwords in it, but also e.g. my users’ blogging passwords in their respective keychains.

AgileBits, developers of the popular secure-storage app 1Password, made a conscious decision not to use Apple’s Keychain. They cite a variety of compelling reasons, including Keychain’s alleged use of a somewhat outdated encryption technique called Triple DES. Agile has written extensively about the design of their own keychain, in which they confirm that they are using PBKDF2 to derive their encryption keys.

I’m confident that Apple’s Keychain is secure for all practical purposes, but it is just sort of irksome if they are not adopting the very best protection that Mac-money can buy. Unable to find suitably authoritative documentation on the matter, I took to Apple’s open source for libsecurity_keychain, the library through which the Keychain’s data is managed. My reading of the source code for a function called SecKeyDeriveFromPassword, does show that Apple is indeed using PBKDF2 to generate the key.

On 10.7.3 they are, at least. The SecKeyDeriveFromPassword API was new to 10.7, taking over for the older CSSM_DeriveKey. Perhaps the default behavior of that function did not use PBKDF2. In any case, it sure sounds as if on top of Tony’s urging, FileVault’s use, and 1Password’s adoption of PBKDF2, Apple’s decision to use it as the mechanism in their latest versions of the Keychain only adds to the impression that it’s a fine choice.