While NaCl/Sodium does simplify the crypto aspect in particular, it's dangerous to assume that it entirely solves the broader problem of writing secure code. Implementing anything securely is hard enough before involving crypto that the level of expertise required doesn't change all that much. (Most catastrophic vulnerabilities in security software aren't directly in the cryptographic implementations.)
Even using NaCl, one needs to understand enough of what's happening under the hood to properly reason about the security of the whole system they've built.
Am I allowed to be concerned that this is C code that opens up random files to be decrypted, slurps a 32 bit integer directly out of the file, passes that value to malloc, and then just a few lines later loops memcpy'ing into that buffer?
That's, like, 5 minutes worth of looking, most of it spent working out how to get from main() to the part of the code that actually starts taking attacker-controlled inputs; we're about 10 lines into the code that handles those inputs. Is that a real vulnerability? Hell if I know, but I'm scared of this code.
Which is not to say I don't like it. There's a small utility function in there I'm stealing! The author is clearly smart and I hope this was an interesting project for them. But I don't recommend using this for real --- and I think neither does the author.
You are allowed to be concerned. I probably read too much into your comment. But I think you all understand my point. I was concerned that some mortals might be scared off from experimenting with NaCl. "Experts only."
Some years ago, there was another fellow who wrote a set of NaCl utilities that were very simple, UNIX filters. While I was "scared of the code" because he's not a renown cryptographer (does he need to be?), I was thankful for a simple, working example. There really weren't any publicly available at the time.
I really appreciate when people share these self-learning projects.
That's a nice way to put the fallacy. That one is so common it needs its own name and Wikipedia page with list of hacked products that used the fallacy. Anyone already do that with a link?
On my end, I always tell them any system or scheme is to be assumed vulnerable until proven otherwise through analysis and pentesting. If they doubt that, I show them plenty of stuff made by pro's and associated CVE's. Then ask if their people were better and with more budget for security. Usually a no...
I've written my fair share of vulnerable code throughout the years. Two key indicators for me: Do they learn from their mistakes? Are they proactive at preventing mistakes?
I wasn't actually commenting on this project in particular or whether or not the author happens to be an expert (tptacek may have more to say about that), just on the idea of NaCl as a replacement for expertise.
NaCl/libsodium solve a low-level problem that even very few talented engineers with years of software security experience can be expected to get right on their own.
Using these features should still be done under the guidance of someone who knows what they're doing. There's a larger number of developers who can use libsodium than there are developers who could replace it on their own.
In a sense, NaCl/libsodium can be viewed as a "replacement for expertise" that is so rare it's nigh-nonexistent. (To wit: these libraries were created by multiple authors.) Rather, it places the capability to build solid application-layer crypto into the hands of mere mortals.
That doesn't obviate the need for good mortals. :)
"tmux was supposed to provide [of] additional value"
Are you sure?
Could it be the author just wanted a BSD licensed screen alternative or some other reason(s)?
"The keybindings are different" argument seems quite silly since you can easily change them to whatever you want. It's like when people say they will not use Lua because indices start at 1 instead of 0.
tmux may be thought of as an alternative, not a replacement.
Whether that's correct is an open question.
Example: If I start a build world in a screen window, then detach and later I want to get a "screen shot" or "screen grab" of the output without re-attaching, how do I do that?
Also, tmux's "clipboard buffer(s)", e.g., tmux loadb, tmux lsb, etc., seems a little more versatile than screen, but I'm open to suggestions from screen users how to do these things in screen.
Here's what I use in tmux for the Example:
cat tt
case $1 in
""|-b|-E|-S|-t)
tmux capturep $@
exec tmux showb $@
;;
*)exit
esac
I propose a new project: lessutils.
You post about some program that you use for some simple task that's not among the "standard UNIX utils". (ed, sed, AWK, lex, etc.)
Then we show you how to do the same task with only the standard utils. (i.e. no install needed) -- inevitably someone shows us how to do it in AWK and makes all feel stupid. :)
If we are successful, you get to eliminate one more dependency from your system, not to mention reducing attack surface.
Yes.
letsencrypt.sh is a nice case study, spending a lot of effort to parse json with essentially bash & grep. It works now but is full of assumptions ("this array of hashes will not contain [ anywhere").
There is nothing in POSIX that's well suited to manipulating json in the way that jq is.
Unless the programs are setuid, is that a real problem? I mean, anyone who can call one of these utilities with some arguments can also call "sh -c ...", no?
My point is that if you have a meter-wide hole in your parachute (sh and other interpreters you can call to execute any code you want), also having small rips in the fabric probably doesn't really matter - if you have to rely on it, you're screwed anyway.
