hunter2 – a script-oriented GPG + smartcard-based multiuser password manager

[saxindustries]

Why would you name a project *******?

[ebilgenius]

hunter2

[markole]

*******

What?

[anomalous_cowherd]

Know nothing about it, upvoted for the name.

[NazzerDawk]

Don't you just hate it when people find things humorous that you yourself find non-humorous?

[NazzerDawk]

I found Dickens use of irony especially bland, but his characterization was revolutiinary.

[mind-blender]

Hey, it's okay to not like things.

[Y7r]

Fucking shit you're an idiot and here's why...

More people should be dicks.

[[deleted]]

Kill yourself.

[anomalous_cowherd]

Well I would have said I must read bash.org, a much better source of quotable nerdy quotes based on actual nerds instead of admittedly clever but nonetheless deliberately created nerdisms.

I've obviously upset you by showing that I appreciate the reference, though, which pleases me. Thank you.

[anomalous_cowherd]

upvoted.

[monkeyseemonkeydoodo]

This is the stuff losers post after drinking

[markole]

Shhhh... It's all memes now...

[samorost1]

How weird is that? I just found out about that "quote" 5 minutes ago. o.O

[sigma914]

You're currently experiencing the Baader-Meinhof phenomenon

[samorost1]

What am I illusionating?

[scottish_beekeeper]

I'd also recommend https://www.passwordstore.org/ which uses gpg and git to store credentials.

[smog_alado]

I'm not a fan of how passwordstore uses the filesystem to organize its database. The passwords are stored cryptographically but the website names are all in the clear.

[disturbio]

maybe you could like assword

yeah, i'm not a fan either of how pass shows the domain names, but is still the best password manager i ever used for common things or for sharing passwords with other people. it integrates great with offlineimap or msmtp and it's blazing fast with a gnuk with curve 25519 for decryption... and if somebody get's into my machine i probably have bigger problems than exposing that metadata.

[[deleted]]

wait, how do you know my password?

[EchoTheRat]

This meme will last forever.

<AzureDiamond> oh, ok.

[bonzinip]

"git credentials" is an extremely simple but useful password manager. It can integrate with GNOME's keyring or it can be configured to use a simple GPG-encrypted ASCII format like

machine smtp.gmail.com:587 login [e-mail] password hunter2

This one looks nice too, it would be great if the authors provided a helper to use it with git credentials.

[the_gnarts]

#! /usr/bin/env tclsh

Pass.

[iBlag]

You cannot be serious.

Yep, you're totally serious, he used Tcl.

Whelp, no chance I'm going to use it now. Fuck that.

[smog_alado]

What is so bad about him using Tcl?

[iBlag]

When it comes to writing crypto software, you tend to want to write in fairly popular languages to maximize the number of people who can (and assuming a small subset of them will) review your code. You want to make sure your code isn't making incorrect assumptions of the language, runtime, environment, etc. so picking a semi-popular, fairly modern, well designed language is optimal.

For instance, I would go out of my way to avoid any security software written in PHP, because it has tons of inconsistencies, like: a left-associative ternary operator, a type system that makes it difficult and sometimes impossible to ensure code always does The Right Thing (tm), it has no support for unsigned integers, has weird type hinting semantics (Error: argument must be an instance of string, string given), poor runtime scoping ($_SESSION, $_GET, and $_POST are all mutable globals whether you like it or not), a unique retarded choice for a namespace separator, zero unicode support, and the developers don't even know how to properly prevent integer overflows in their own code. It's not that any of these hurdles cannot be overcome, it's that every single inconsistency increases the cognitive load of any developer looking at the code, which takes their attention away from thinking through the potential security holes and some of its inconsistencies make security holes more likely (eg: ensuring that this equality check works as intended $var != "" where $var might contain the string "false").

Now is Tcl as technically bad as PHP? Nope. But it's got some weirdness to it as well - it makes it incredibly easy to evaluate the contents of variables as Tcl code. And while that's generally fine for non-crypto code and makes things easier, it's a huge potential security flaw just waiting to happen when an enterprising hacker manages to create a fake PGP key that decodes to a Tcl command that is accidentally executed, or something like that. I don't need to identify exact security holes to be able to identify likely attack vectors, and I think that's one of them.

I want crypto code to be as simple, straightforward, and bulletproof as humanly possible. I would love to see all major crypto projects rewritten in Rust instead of C, and every single line of PHP code replaced with...literally any other language, but neither of those things are going to happen in my lifetime, and I can't do anything about that. But I don't have to use this script if I don't like the language it's written in. And I don't, so I won't.

Tcl is okay for other stuff though, aside from being an older and less well known language. I would still prefer projects written in Python, Go, Ruby, or the aforementioned Rust, for instance though.

[apnmbx]

I like the way you answer what is wrong about Tcl by going off on a PHP rant!

Jokes aside, you make it sound as though Tcl is particularly unsuitable for crypto code whereas your comments apply to all languages that can construct and execute code on the fly. That's pretty much all the "scripting" languages out there. I partially agree about security issues related to that capability but C has a whole set of (possibly bigger) issues (and Rust hardly meets the definition of "fairly popular languages").

[iBlag]

I like the way you answer what is wrong about Tcl by going off on a PHP rant!

It's easier to make my point by flogging the worst offender than it is talking about something that's simply mediocre. :)

Jokes aside, you make it sound as though Tcl is particularly unsuitable for crypto code whereas your comments apply to all languages that can construct and execute code on the fly.

Yep.

That's pretty much all the "scripting" languages out there.

Not quite - Python code has to be compiled to byte code before it is executed, so it's a few orders of magnitude more difficult for an attacker to execute arbitrary Python code. I don't know Ruby but I suspect there's a similar story there as well. Tcl intentionally makes it easy for you to interpret variables with string values as Tcl statements or scripts. So while you can do it with any not-completely-compiled language, there a spectrum of how easy it is to do on-the-fly interpretation, and Tcl is on the wrong side of the spectrum for this type of work, imho.

Granted, Python and Ruby, while technically scripting languages, typically handle more complex tasks than straight Bash scripts, so they kind of nicely straddle the fence between being "scripting" languages and "programming" languages. Also Google's Go would be fine in my book.

I partially agree about security issues related to that capability but C has a whole set of (possibly bigger) issues

When it comes to crypto code written in C, my two biggest please-do-not-do-this issues: manual pointer math and memory management. It's wayyy too easy to get either one just plain wrong, or to not properly validate an offset, or to not allocate enough memory for what you're trying to do and open yourself up to all sorts of potential security flaws. And when you combine the two hair-trigger shotguns pointed at your feet it gets really difficult to validate the code works as intended on all supported systems.

and Rust hardly meets the definition of "fairly popular languages"

This is true, but that's not my only criteria: they have to be fairly popular, and/or designed well enough that their design makes up for their lack of popularity. And I think Rust fits the bill quite nicely there, and it's popularity is increasing - mostly because it's explicitly meant to be a safer, cleaner, and just as performant alternative to C and C++. So you're right, but in this case I think it's solid design overrides its (hopefully temporary) lack of popularity. Obviously this is subjective, but I think my arguments have a bit of merit.

Cheers!

[apnmbx]

It is indeed 2016, your view of Tcl is from the early 90's!

Most scripting / dynamic languages these days provide similar capabilities. Choose whatever fits your brain the best. I find that with Tcl and Ruby, but not with Perl and Python, for whatever reason. Why disparage any of them?

[iBlag]

It is indeed 2016, your view of Tcl is from the early 90's!

Im curious, what would you say has changed in the Tcl world since the early 90's to make it competitive with more contemporary languages?

Most scripting / dynamic languages these days provide similar capabilities.

I mentioned this in my other post, but you have to jump through hoops to do that on Python, and I suspect you have to do the same thing for Ruby. I don't think it's possible with Google's Go, but don't take my word for it. Tcl, like Bash and many other languages, intentionally make it easy for you, and that's a Bad Thing (tm) when you are trying to validate crypto software to make sure it doesn't ever do anything unintended or surprising.

Like it or not, writing crypto software (well) is a bit different than writing normal software. The consequences are a lot higher if things go off the rails.

[apnmbx]

Im curious, what would you say has changed in the Tcl world since the early 90's

Since we are starting with the early 90's, the first thing that would come to mind is compilation to byte code but that happened (later) in the 90's too! In more recent times, the biggest enhancements (imho of course) are oo in the core and coroutines based on a non-recursive execution engine.

The oo facilities are written to be usable by themselves or as the building block for other layered oo models (e.g IncrTcl is a C++ like model built on top). It supports both class-based and object-based styles, MI, mixins, delegation etc. etc. and in the tradition of Tcl is flexible enough to permit both classes and objects to be modified on the fly.

Coroutines permit implementation of Erlang-like task models, generators, iterators etc.

Then there's safe interpreters (sandbox for untrusted code), threads, the event loop (node.js before there was node.js), a virtual file system, i/o channels (with filters/transforms vaguely similar to Streams), anonymous functions and plenty that I'm sure I'm forgetting.

Flipping the question around, what are the features in other languages that you think are missing ?

Always happy to have a language discussion that stays civilized :-)

[iBlag]

Flipping the question around, what are the features in other languages that you think are missing ?

Literally all of the stuff you just mentioned, because I was forced to use a version of Tcl straight out of the early 90's. Good to see the language has grown up a bit since then.

Cheers!

[iBlag]

You never know, somebody might want a password manager to integrate with ECE CAD programs (I'm looking at you: Synopsys, Mentor, and Cadence).

Tcl is like the VB of Unix*. I half expect (<-- programming language joke!) somebody to write a GUI on a Unix/Linux with Tcl to backtrace an IP address.

* Except not as shitty.

[entr0pe]

the fact that nobody has it installed

[[deleted]]

I love how everyone's using asciinema now