hf

Being among the most zealous to worship at the altar of Kernighan and Ritchie, I, nevertheless, over the years, have come to appreciate the positions expressed in this fine, albeit often humdrum, collection.

Concrete examples of the insanity of Unix might by now be largely obsolete (none of the csh- or symlink-related showcases work anymore), but the basic, deep annoyance of the Haters seems to me ever-valid:

  "Unix evolved; it was not designed".

This holds true even in the age of the beautifully engineered surfaces of MacOS and Unity. Underneath, Unix lurks with all its idiosyncrasies and peculiarly half-hearted assumptions and informs all of the interfaces and paradigms above.

No one who ever saw a Genera machine at work or appreciated fully the depth of Smalltalk's world view, will be able to dive into Unix and come back with the same deep sense of enlightenment.

Unix' only redeeming, rather: defining, feature is this: relentless adaptability. Unix, as an ideology and an ever-changing set of tools, works precisely because it refuses to be held to any standard of aesthetics.

Cray's rather famous anti-parallelization quip, "If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?"[0], reminds me somewhat of one of Donald Knuth's statements: "During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX"[1]

[0] https://en.wikipedia.org/wiki/Seymour_Cray#SRC_Computers

[1] http://www.informit.com/article/article.aspx?p=1193856&_

While we are busy dispensing wisdom: Do use

    PermitRootLogin without-password

instead of 'yes' in /etc/ssh/sshd_config if you absolutely must have ssh root access.

Both scenarios you mentioned would, I believe, benefit from using keychain (see below).

Let's suppose I have an account tests@host which runs the tests (scripts) that need to login to an array of machines.

In order for keychain to be helpful here, you need two prerequisites.

1) You need to be able to interactively login to tests@host once after bootup; after that you don't need to touch the machine again.

2) Then, the test scripts need to say

    . $HOME/.keychain/$HOSTNAME-sh

once before executing any ssh command (the line above simply imports the ssh-agent session variables into the current environment).

edit: I removed the Nagios references as other posters rightly point out that there are more endemic ways to collect information with Nagios.

A few commenters do not seem to be aware that it is perfectly possible to use passphrase-protected keys for automated tasks (cronjobs and the like).

The excellent (though unfortunately named) keychain[0] utility provides a ready and powerful abstraction for both ssh-agent and gpg-agent.

[0] https://github.com/funtoo/keychain

What is more, you can specify an abstraction for the tedious double-ssh where you first connect to some internet-facing host in order to gain access to an internal machine:

    Host $ALIAS
        User $USER
        HostName $INTERNAL
        ProxyCommand ssh $USER2@$PUBLIC -W %h:%p

Now

    laptop> ssh jim@public.example.com
    public> ssh dev@myworkstation

becomes

    laptop> ssh work

(I just realized that this slightly confused article seems to accomplish the same by using a convoluted setup of port-forwardings and netcat.)

The situation with beginner-friendly SSH tutorials is, in a much lesser degree perhaps, comparable to the crypto texts: Good will alone does more harm than good.

This treatment ssh does not mention ssh-agent and, more importantly perhaps, implies that there is a certain virtue in having private keys unprotected by sturdy passphrases lying around.

There is not; most emphatically not.

Outstanding!

Although, at first glance, the image-by-image mode of distribution seems obstructive to widespread dissemination (as is the case with similiar publications of the same kind and magnitude[0]), the generous licensing makes more than up for it.

Nothing seems to prevent the Internet Archive from providing additional backbone, possibly outlasting this web presence[1]. (Odd, archive.org has no separate category for images.)

The thought of a comprehensive, high-resolution, Gutenberg-esque archive for Images clean boggles and delights the mind (mine at least).

[0] The BBC's image and British Pathé's video archives come to mind. HN discussion about the last publication of this nature: https://news.ycombinator.com/item?id=7604459

[1] http://www.getty.edu/about/opencontent.html

Seeing as how they seem to be going out of their way to mention Open Content and public domain in one sentence, I would venture to guess that there's nothing standing in the way of compiling a torrent archive.

Redistribution is not adressed explicitly, though (as far as I can see).

This interface paradigm has, I believe, become known as gamification; an example from another domain, language learning, would be Duolingo[0].

Engaging as such applications are with their stimulus of powerful primordial triggers, they all too often transport not just a game's gratifying aspects into the problem domain (todo lists, in this case), but also the gaming mindset, resulting in terribly linear interfaces and data structures.

I do believe that even a serious todo list application, or, as it were, language learning platform, would benefit from similiarly engaging elements, effective by virtue of our cerebral heritage.

Nevertheless, I have yet to see a successful marriage.

A gamified Emacs Org-mode[1], perhaps?

[0] An ingenious platform that ostensibly allows anyone to learn a language by doing bite-sized exercises and translating sentences, while effectively training the proprietary Duolingo translation engine. See http://duolingo.com

[1] http://orgmode.org/

The opening paragraph asserts that simply not publishing ("censoring") such concrete, recipe-like exploits of the deficiencies of our shared infrastructure "won't make practices like those outlined [in the article] disappear"[2].

I am reminded of Steve Kemp's 2014 post »Secure your rsync shares, please«[0], relating how he abandoned a project employing zmap[1] upon discovering numerous openly accessible rsync shares containing sensible information. His closing remarks echo the sentiment of the article under discussion here: "I considered not posting this, but I suspect 'bad people' already know..,"[0]

What can be done? Are we reduced to just securing our friends' and families' infrastructure, all the while standing by idly while others outside of our direct sphere of influence suffer the consequences of naïvety?

[0] http://blog.steve.org.uk/secure_your_rsync_shares__please_.h...

[1] A cleverly-built, fast network scanner, https://zmap.io/

[2] http://danmcinerney.org/how-to-exploit-home-routers-for-anon...

Enticing; depth and vision. Coherence is always tricky, but, to my mind, they pull it off.

To be quite honest: Debian/kFreeBSD is still my version of FreeBSD, but that's just laziness.

An impressive collection to be sure. Slightly hyperbolical, the British Pathé archive puts it thusly:

"This archive is a treasure trove unrivalled in historical and cultural significance that should never be forgotten."[0]

However, I am left wondering why "[u]ploading the films to YouTube seemed like the best way to make sure of that." Perhaps fittingly, there's no clear indication which licence, if any, is applicable.

What could've possibly impeded a parallel upload to the Internet Archive?

[0] https://britishpathe.wordpress.com/2014/04/17/british-pathe-...

As glossarian in residence I cannot but expand the above app-sec acronyms:

* CBC - Cipher block chaining: https://en.wikipedia.org/wiki/Cipher_block_chaining#Cipher-b...

* CFB - Cipher feedback: https://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio...

As evinced by the structural similarity of the diagrams in the pages above, the two are very similar; hence tptacek's characterisation of their combination in encfs as "weird", I presume.

* XTS - "XEX-based tweaked-codebook mode with ciphertext stealing": https://en.wikipedia.org/wiki/XEX-TCB-CTS#XEX-based_tweaked-...

I have to more or less hope this is the encryption mode referenced above. NIST recommends an AES cipher to employ with it.

Resolving all acronyms here seems futile (albeit entertaining), thus I will simply rest.

(This is my last unsolicited reply in this thread, I promise.)

Of course, encfs aims to hit a very specific sweet spot with their emphasis on backup-friendly per-file encryption as opposed to Truecrypt's container approach.

Which is begging the question, naturally.

edit: To wit, whether an alternative exists that would satisfy the encfs use case.

I removed this sentence from my previous comment to parent: From a layman's perspective, I should think the encfs authors came away from that analysis with a feeling of achievement: to have been audited (however quickly) and yet to live.

If the above (grand-parent) is the worst tptacek says about encfs, I would argue that you are in decent shape.

As this surfaced, I was chiefly impressed by the fact that encfs was amenable to such a by-and-by[0] audit: the code-base must be at least somewhat legible.

This "auditability" seems to me a strength worth nurturing.

[0] Where "by-and-by" refers to the usual superhuman app-sec standards in which "10 hours" translate into actual, meaningful work.

I don't want to sound overly enthusiastic, but I do think that this fits the bill 90% of the way. Great presentation[0]; pricing explicit and almost exactly what I would have imagined; and, of course, sane pick-up and delivery. I even hunted around for a spelling mistake to have something on the opposite side of the ledger. No such luck.

Alas, I'm a few thousand miles short of becoming a valued customer.

Now, hopefully, you're wondering about that last 10%: It's point 2 in your "How it works":

> Pack your things carefully and take pictures of the contents.

I'm sure legal would have a word or two to say about that, but: how much would it set me back if you did that, together with providing a rough description of the box' contents? This, then, would appear on my account page's List of Boxes.

The details are devilish, of course, and supreme caution is indicated: you don't want a prominent "take-a-peek" option to adversely affect the trust of your more privacy-conscious clients.

[0] Which, incidentally, doesn't appeal to me, as I am solidly in the tarsnap aesthetics camp, but we both know what to make of that.

Coincidentally, this is something I have researched just last week for my area. I would love to store boxes upon boxes of things that I will need in another two years (eg. baby clothes), will sell eventually, or plain don't want around[0].

Unfortunately, I have come to the conclusion that the concept of self-storage presented here, quite similar in spirit to my local self-storage providers (henceforth: SSPs), is not reconcilable with my use-cases and fundamental needs.

To wit: All SSPs that I found were located on the outskirts of town. "Industrial estate" would describe it well. This calls for car ownership (or rental, at least) and huge transfer volumes.

But I want to spirit away a smallish box every month or so. I would like to carry it (perhaps in a bicycle trailer) around the corner. In short: I want those SSPs to be as ubiquitous as libraries.

Now, are there cities were a system not unlike to the one outlined above exists? If so, are hacker/maker spaces similarly well-distributed?

[0] Books, chiefly by virtue of their tactility, belong solidly into the latter category, as non-intuitive as it may sound: these cellulose blighters are everywhere and frankly cumbersome to circumnavigate by now.

I believe one of the more famous Richards were mentioned in this everlasting classic:

Richard P Feynman, who, on having picked a certain lock, complained that "[t]he trouble with playing a trick on a highly intelligent man like Mr. Teller[0] is that the time it takes him to figure out from the moment that he sees there is something wrong till he understands exactly what happened is too damn small to give you any pleasure!"

The volume »Surley, You're Joking Mr Feynman!«[1] contains many, at times only seemingly so, light-hearted reminiscences in similar spirit.

[0] Edward Teller (1908, Budapest – 2003), a Hungarian-US nuclear physicist known colloquially as "the father of the hydrogen bomb"; see https://en.wikipedia.org/wiki/Edward_Teller

[1] https://en.wikipedia.org/wiki/Surely_You%27re_Joking,_Mr._Fe...!

Vacillating between floating away on my recently-inflated feeling of self-worth and trying to keep you engaged on a very uneven playing field (as in my not knowing Adam from Eve, so to speak), I'll simply opt for another Thank you.

While by no means as well-formatted, the following list contains the output of my now-redacted script: http://pastebin.com/NT2TKRTM

For the uninitiated: LTO stands for Link-time optimization and happens when the compiler merges/links all separately-compiled object files into one (executable or library).

Although it seems obvious that this might be a good idea, why would it

1) use exorbitant amounts of memory; and

2) be "pretty awesome" instead of, say, mildly useful?

edit: And both questions satisfactorily answered in the time it took me to peruse the preamble of https://en.wikipedia.org/wiki/Interprocedural_optimization

Thank you!

A stamp of approval if ever there was one. Thank you.

What, however, hinders adoption as a "working man's" TLS library? Neglecting performance and variety of cipher support, would or should anything prevent me from using Tiny TLS to secure channels between "inner circle machines" (that talk to a set of well-known participants)?

Undoubtedly these excellent books call for a unique presentation. I, however, would like to see simple text-only list companion to go along with it. Turns out, this is not just a matter of grep'ing through the source: the only actual "text" are the link URLs.

I wrote a script[0] to create the list for amazon links at least:

    # Script redacted - I think HN isn't happy
    # with my scraping.  Fair enough.

The list contains 44 entries -- to much to post here, I'm afraid.

[0] Using the `mojo` cli tool for ad-hoc HTML parsing from http://mojolicio.us/

Absolutely astounding: I have been looking for this book ever since I pored over it in the Wolfson Reading Room in Manchester Central Library 5 years ago. I didn't take down the authors' names, though, referring to it as "that yellow mathematics book" then and ever since.

I credit that book with much if not all my mathematical insight.

Thank you.

(Just seeing that cover leaves me all tear-eyed, reminiscing over that wonderfully irresponsible time.)

Trevor Perrin (of TACK fame) wrote TLS Lite in Python.

I submitted a link to TLS Lite a few days ago, but, alas, showed poor judgement in timing:

https://news.ycombinator.com/item?id=7564740

Direct link: http://trevp.net/tlslite/

I'm actually rather anxious to hear the knowledgeable crowd discuss this fine project.

Leaving all those unsavoury associations of perfecting surveillance en masse aside: Are they quite sure their transmission channels are strictly uni-directionnal?

I didn't know about fuzzers before this whole imbroglio -- not denoted as such, at least.

If you know `crashme` you already know one fuzzer, which "intended to test the robustness of Unix and Unix-like operating systems by executing random machine instructions." See https://en.wikipedia.org/wiki/Fuzz_testing

As a good app-sec'er you seem to need to be deeply steeped in fuzzer lore. Matasano: "We'll have you write a fuzzer. Everyone here writes fuzzers." http://www.matasano.com/careers/

(I'm obviously not replying to tptacek, just highlighting a bit. ... And basking in the good glow, yes.)

The commit message contains a rather succinct, albeit drastic description-cum-definition of Heartbleed:

> [A] 64K Covert Channel in a critical protocol.