Latest articles

DAuth v0.6 - SHA-2 and Hash_DRBG

DAuth is a low-level authentication library for D with no external dependencies other than D's standard library, Phobos. It provides a simple-yet-flexible API, so your software can easily incorporate secure, upgradable user authentication based on salted password hashes.

By default, DAuth uses known-good hashing and randomization algorithms (currently SHA-512 and Hash_DRBG), but it accepts any Phobos-compatible hash digest or random number generator. You can have as much or as little control as you need, making DAuth suitable for both new projects and interfacing with any existing hashed-password store.

Links:

New in v0.6:

  • Added SHA-2 (hash digest) and Hash_DRBG (cryptographically secure psuedo-random number generator), and set them as the new hash/RNG defaults. DAuth is only a temporary home for these - the SHA-2 implementation has already been merged into phobos master, and I intend to prepare a pull request for the Hash_DRBG. But they're ready-to-use in DAuth in the meantime.
  • Split DAuth into separate modules (using a "package.d" to preserve "import dauth;")
  • Changed callbacks from functions to delegates.
  • Fixed a few bugs, including an error in the dub package file.

Read more


DAuth - Authentication Utility Lib for D - Initial Release v0.5.1

I've put up an initial release of DAuth: A simple-yet-flexible salted password hash based authentication utility lib for D.

Before you get too excited, know that actual cryptographic algorithms are outside the scope of this lib. Instead, it uses any Phobos-compatible digests and random number generators.

The upside: This makes DAuth fully extensible with plug-in cryptographic algorithms. The downside: It's currently limited to what little exists in Phobos right now (or in any Phobos-compatible third-party digests/RNGs I may not know about).

Full overview, sample code, source and (ugly) API reference are at DAuth's GitHub homepage.

(DUB project name "dauth")

Announcement thread at the D newsgroups is here.

Read more


Google Pulls a Microsoft, Pisses All Over Standards

This one page alone (discovered while searching for why my POP access to Gmail[1] is borderline broken) is sufficient proof that the dumbfucks working at Google have their heads completely up their retard asses, and are hard at work mimicking Microsoft's widely-ridiculed practice of pissing all over standards just for the fuck of pissing all over standards:

https://support.google.com/mail/answer/47948?hl=en

So Google expects people to use a non-standard convention in order to make what I'll call "Google POP3" behave like NORMAL FUCK STANDARD POP3?! Except even that still isn't normal POP3 behavior (unconditionally ignores anything beyond 30 days old whether it's been downloaded or not, and retrieves outgoing messages as if they had been incoming).

And yet, the motherfuckers over at Google have the nerve to pretend to be better than Microsoft? Fuck the whole lot of them. For fuck's sake, it's no secret that many of them came from Microsoft in the first place, so it shouldn't surprise anyone that they are the new Microsoft.

[1] "Uhh, if you hate Gmail so much, why do you use it?" Normally I don't, I run my own mail server. But anytime you do that, you still need an administrative contact address that's separate from your own server and domain. Otherwise, if you hit any registrar or hosting snags (and don't think you won't), then your "official" contact address goes right down with the ship, and now you're really in trouble. "Why not Hotmail or Yahoo Mail?" Uhh, would you use Hotmail or Yahoo without anyone pressing a gun to your head?

Read more


Trivially Make Your Site Work on Mobile? Yes, Please!

Want a super easy way to drastically improve your web site's usability on mobile browsers? Quit using CSS overlay popup windows, ie "pop-ins".

It's bad enough that they've always been a terrible practice on desktop browsers (it's a trivial way to guarantee breaking basic browser functionality like back/forward/linking/etc). But on mobile browsers they completely break scrolling and result in pages that are completely unusable. (<-- Follow that link on a mobile browser and then try any of the "Read more" links)

So get rid of CSS overlay popup windows (pop-ins), replace them will full-fledged pages, and your site will instantly improve on desktop browsers and suddenly become usable on mobile browsers.

Read more


Static Checks vs Templates: Always Instantiate Your Templates

One of the key benefits of static typing is the compile-time checking it enables. Compile your program successfully, and entire classes of programmer errors are guaranteed not to exist - regardless of how thorough your unittests are. (Unittests can't realistically be as thorough as static compiler checks. They're an important supplement to static compile-time checks, but not a replacement for them.)

Unfortunately, templates leave a slight hole in this system of guarantees. By the very nature of templates, the code inside cannot be compiled unless the template is actually instantiated. And if the code isn't compiled, it can't be statically checked (beyond mere syntax checks, anyway).

So you're left with this potential scenario: You write a new template in some library, or make some changes/additions to an existing template, then try out your test project and unittest suite. Everything compiles and runs successfully, so you commit your changes and push to the VCS server. Another coder pulls your work, tries to use your template...and gets compiler errors.

Oops! Your test project, or your unittest suite, never actually used the template! Or maybe it only used one instantiation and never attempted other instantiations that were intended to work. Your user became the first one to actually attempt compiling your code, and became the first to discover it didn't work.

Due to the nature of templates, it's impossible for the compiler to test all possible instantiations of a template to ensure they compile (or don't compile, in some cases) as expected, particularly if the template is part of a library. With sufficient sophistication, it may be possible for a compiler to guess at a few sets of arguments that satisfy your template's parameter constraints and then check that they compile. But even D doesn't currently do that.

The moral of this story: Always instantiate your templates. Make sure you always have at least some dummy instantiations that are expected to work. Here's an example of doing it in D:

struct FooType(T) { ... } private alias test_FooType = TypeTuple!( FooType!int, FooType!string, FooType!char ); void fooFunc(T)() { ... } private alias test_fooFunc = TypeTuple!( fooFunc!int, fooFunc!string, fooFunc!(FooType!int) );

It's better, of course, to unittest them. (Tip: It can often help to use foreach over a TypeTuple of the instantiations you want to unittest.) But at the very least, be sure to have some basic instantiations. It's only a one-liner, after all, and may very well save you some embarrassment.

Read more


Scriptlike v0.6.0

An update to Scriptlike is out. Scriptlike is a utility library to aid writing script-like programs in D.

https://github.com/Abscissa/scriptlike

Changes from v0.5.0 to v0.6.0:

  • Change: Path and Ext are now aliases for the UTF-8 instantiations, and the template structs are now named PathT and ExtT.
  • Change: Removed path() and ext() helper functions to free up useful names from the namespace, since they are no longer needed. Use Path() and Ext() instead.
  • Change: Internally split into separate modules, but uses package.d to preserve import scriptlike;.
  • Change: Rename escapeShellPath -> escapeShellArg.
  • Change: Rename runShell -> tryRun. Temporarily keep runShell as an alias.
  • Change: Rename scriptlikeTraceCommands -> scriptlikeEcho. Temporarily keep scriptlikeTraceCommands as an alias.
  • Enhancement: Added scripts to run unittests and build API docs.
  • Enhancement: Added opCast!bool for Path and Ext.
  • Enhancement: fail() no longer requires any boilerplate in main(). NG link
  • Enhancement: Added run to run a shell command like tryRun, but automatically throw if the process returns a non-zero error level.
  • Enhancement: #2: Optional callback sink for command echoing: scriptlikeCustomEcho.
  • Enhancement: #8: Dry run support via bool scriptlikeDryRun.
  • Enhancement: #13: Added ArgsT (and Args helper alias) to safely build command strings from parts.
  • Enhancement: Added this changelog.
  • Fixed: Path(null) and Ext(null) were automatically changed to empty string.
  • Fixed: #10: Docs should include all OS-specific functions.

Read more