Hacker News Reader

> http://dwm.suckless.org/ -- "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions."

The worst thing about that attitude is that the suckless programs I tried are full of bugs and usability problems. I actually liked the idea of building simplified core programs, without the bloat and bc stuff of the environment around them, and thus opted to use st with a multiplexer. But if the result is that one has a terminal where you can't copy stuff properly because it does not handle linebreaks, or where you can't use ssh properly because the moment you scroll all text gets distorted, that is not excellence, it's just bad. And if they had more users they maybe would find those bugs, and get the help they seem to need.

And the whole "we are cool, we configure in source code" is just lazy. It's not like they gain anything from that, the spared lines of code pale in comparison to the effort needed to organize the configuration at distro level.

Also, st with a multiplexer (any multiplexer) has much more code complexity than any decent modern terminal. And less features.

Way to go, suckless.

> And the whole "we are cool, we configure in source code" is just lazy.

Right. A little config file parsing library does not harm (and can be just copied into the project) but goes a long way for user experience.

Look at icewm, one of my favourite software projects. Yes, it's written in 60K lines of C++, but it's rock solid, fast and flexible. The configuration mechanism is powerful and an example of "no bullshit" design.

I just wish icewm had a more active project. I reported a bug and never got feedback, it also was never fixed. But yes, apart from that it is a great WM, and especially the configuration is what makes it great. My choice as well.

That's precisely the reason that I use spectrwm instead of dwm. Making your program unnecessarily difficult to configure to "keep the newbies away" is just plain assholery.

> Installation uses HTTP to fetch a boot volume image.

This is a problem with all of the suckless software and it, well, sucks.

What's wrong with HTTP? I think the OpenBSD team made it clear that HTTPS does nothing for security (At least the integrity portion) of downloading stuff (which is why signify is a thing). By explicitly using a non-secure channel for transport you make it explicit that integrity must come from some other channel.

Except… There is no other channel. Suckless doesn't sign their releases, nor the image download. Nor is anything in git signed.

Integrity, schmintegrity ¯\_(ツ)_/¯

The other channel: read the source code yourself before compiling.

This actually possible with most suckless projects since they are just a couple of hundred lines of C...

Are you familiar with the Underhanded C Contest? It's possible to maliciously tamper with C code such that you definitely wouldn't spot it with a cursory glance over, and possibly even with careful study.

Counterpoint: most underhanded C successes look like incompetence instead of malice, but still look "wrong"

…to someone who spends a lot of time writing C code.

Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads, and that the lines of code in C often correlates directly to complexity of the solution being expressed, this also assumes that an attack vector would be something obvious upon reading the code, and not hidden as a subtle bug which is hard to spot.

> Ignoring the fact that this implies you have to be a programmer that knows how to read C to verify the integrity of the downloads

Don't ignore it, that's the practically the point. This is the perfect example of "don't trust me, trust the code".

From http://dwm.suckless.org/

> Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions.

> This is the perfect example of "don't trust me, trust the code".

But it's not that. It's "don't trust me, trust the code as long as you're part of the select group of people that can read and understand the code given the language we use, which by the way happens to be well known to be hard to vet for subtle logic errors, which because of the nature of the language often result in segfaults (at best), or remote code execution (at worst)." Why not write it in brainfuck? They'll only change their audience by a minuscule amount compared to the original audience they could have appealed to, and they will be even more "small and elitist".

I originally translated "This keeps its userbase small and elitist. No novices asking stupid questions." as "We're a tight knit group of assholes, and if you didn't take the same path in life we did there's no point in talking to you." It may be unfair to assume that's their intention, but I think it is fair to say that's what they are doing in practice.

The stali source includes, among other things:

* a full checkout of libressl: http://git.sta.li/src/tree/lib/libressl

* a full checkout of expat: http://git.sta.li/src/tree/lib/expat

* two full /bins: http://git.sta.li/rootfs-x86_64/tree/bin http://git.sta.li/rootfs-pi/tree/bin

Emphasis on "most suckless projects".

The point was that you can verify the integrity by reading the source code. The actual limits to this depend on many things.

> > Installation uses HTTP to fetch a boot volume image.

> This is a problem with all of the suckless software and it, well, sucks.

If you serve things over HTTP its easier to daisy-chain it in a PXE -> iPXE kind of setup. HTTPS is not supported by most boot-ROMs.

Keep your boot-image server on site and local and HTTP isn't a real world issue.

1) dl.sta.li is not on my site, and probably not on yours.

2) That's still suboptimal. You're giving each host on your LAN the ability to interfere with any newly-provisioned server. This is a perfect and hard-to-detect way for an attacker to pivot from "RCE on some random webapp" to "advanced persistent threat".

> > Installation uses HTTP to fetch a boot volume image.

> This is a problem with all of the suckless software and it, well, sucks.

may you please elaborate on why you think fetching boot images over http is a bad idea ? fwiw, a large number of networking gear boot their line-cards with image fetched over http e.g. csco's asr-5000 etc.

> networking gear

As someone unfamiliar with that domain, this just raises more questions for me. Is there some secondary layer of code-signing/validation that happens? Is the image host always within the local network and the connection assumed trustworthy?

> Is there some secondary layer of code-signing/validation that happens? Is the image host always within the local network and the connection assumed trustworthy?

some more information: basically most of the these routers etc. are 'chassis' based e.g. asr-5k is a 14u (iirc) device. depending on architecture, these generally have a bunch cards which end up doing most of the work e.g. session processing, forwarding traffic, running your routing protocols etc. etc. most of the session-processing cards don't really have any non-volatile storage media.

ok, now, two of these (for redundancy purposes) are management cards. these cards are not involved in any session processing, and provide 'shell' access to the device. these are generally used to configure the device, run diagnostics etc. etc. management cards have non-volatile storage media, which end up storing various boot images.

now, when a chassis is powered on, management cards are booted up first, using one of the stored images (depending on configuration). other cards (non-management) get their boot images over an internal network via http (e.g. in case of asr-5k).

tldr-mode: yes, the 'network' is trustworthy, and images are present locally (in most of the cases). though it is possible to boot management cards (if your read the above longish explanation) via images over tftp/scp etc. which can be as secure / insecure as you want :)

edit-001: lemme know if you need some more information, and i can see how i can make things clearer.

>* http://sta.li/filesystem -- /.git goes unmentioned. (-:

This was an important point to me.

I've never used suckless software but one of the first concerns I had with stali was upgrading. Apparently initiating an upgrade is simple using git but what happens if an upgrade fails due to its size?

I assume we're upgrading the entire system over git, and in this case that means many very large binary files.

I'm of the philosophy that no security measure will get rid of the need to contiunally patch and upgrade your software.

> The actual installation steps of the doco are "TODO".

Building a kernel and such can be done like this:

http://sta.li/build

I assume that's how that part of installation works. They could have documented that more nicely, though...

(Also, I use dwm. It works out of the box, using it on a stock Arch system is as simple as compiling, installing, and adding it to .xinitrc. And configuration has been made extremely simple also. It's not obvious at all, but it works for the particular niche I fit into.)