beefhash

It doesn't help that getting a copy of the actual standard costs an arm and a leg[1,2], especially if you want both parts of the 2019 edition.

[1] https://www.iso.org/standard/70907.html

[2] https://www.iso.org/standard/70908.html

You may be glad to hear that OpenBSD has been working on supporting security keys natively in OpenSSH, which should hopefully obviate the need to depend on GPG for hardware token solutions. See for example https://github.com/openbsd/src/commit/094c80e0a523faf92a99f6...

You're allowed to do that, but the standard is making no guarantees: C11, § 6.3.2.3(6) “Any pointer may be converted to an integer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.”

I'd consider pointer scrambling to be a pathological case because of that.

Similarly, C11, § 6.5.11(2) constrains XOR to be only valid on integer types, but not on pointer types, further suggesting that you're not really supposed to be doing this.

Parent said nothing about "turning up with a lawyer". You can get legal advice from a lawyer without just going in guns blazing.

They changed to Apache 2.0 recently, actually.

I think this is a split in terminology, actually.

IRCds such as InspIRCd and UnrealIRCd speak of cloaks in the sense of user mode +x, commonly set on connection, which scrambles an incoming user's hostname/IP address to e.g. hidden-5npgt1.iinet.net.au or hidden-qjia2j.ncp0.j4h4.014d.2804.IP.

Freenode, nota bene the largest IRC network right now, uses cloaks to instead refers to a special format of vHost[1]. It does not offer Unreal-style cloaking.

I imagine this difference in terminology is what's prompted this exchange.

[1] https://freenode.net/kb/answer/cloaks

I've read your post about a brief history select(2) and kind of tried to go down with archaeology as to how the BSD sockets API came to be the way it is (struct sockaddr before struct sockaddr_storage, connect and bind being separate states, read/write v. recv/send), but it's been very hard trying to get complete documentation on the evolution since the first BBN drafts.

Food for extra thought I suppose; there's probably a lot of knowledge and trivia to be gleaned from the historical evolution of the interfaces, and I'd imagine you're in a better position to actually sink your fangs into this.

Incidentally, your post is time travelling and claims being from Dec 6, 2019.

You inherit all the weirdness from UNIX domain sockets, such as having the semantics of SOCK_STREAM, SOCK_DGRAM or SOCK_SEQPACKET (or finding out that your OS of choice doesn't support the one you wanted) depending on which one you picked.

Abstract sockets have no permissions. Not having to deal with the filesystem at all is nice, but having absolutely no security model whatsoever also seems dangerous.

You have the ugly issue of having to deal with handling zeroes in your name, as noted in the article. This can and will break something, somewhere on the first attempt of writing it.

When you want microkernel IPC, you usually tend to want a message-oriented reply-and-receive primitive to main loop around them. Emulating this with sockets is error-prone since send(2) and recv(2) make extremely weak promises about their behavior on error. sendmsg(2) and recvmsg(2), which are necessary to pass kernel objects around (i.e. file descriptors), are very difficult to use.

Sockets are nice because you can select(2) etc. on them, however. I'd expect a replacement would interoperate smoothly with at least those system calls.

Abstract sockets sound, to me, kind of like an attempt to retrofit microkernel-like ports back onto UNIX domain sockets for the lack of a better mechanism. It might be worthwhile to consider giving up on that idea entirely and introduce a new IPC primitive (that must be compatible with D-Bus for it to find any kind of widespread adoption).

My personal tweaks:

body { font-size: 19px; width: 72ch; font-family: Charter; margin: 0 auto; line-height: 1.4; }

and then remove the size= option on the <font> element.

Though not a library, Discord also seems to love using this style for their changelogs.

I'm not a fan.

> If the latter, which open-source developer has died the earliest?

Can we just take a second to appreciate how downright inhumane copyright expiry is? It basically encourages cheering for people to die because of copyright expiry.

This comes up every year on misc@, so allow me to just link you to a thread about it: https://marc.info/?t=156380787000001&r=1&w=2

tl;dr, it's the devil they know and they need no feature that Git or Mercurial provides.

Thanks. That one's on me doing incomplete research.

Still leaves open the question as VM for obfuscation (RE tooling, ease of implementation from scratch) though.

> The existence of an LLVM WebAssembly backend helps.

So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm?

Incidentally, would you consider wasm as a destination language for virtual machines for obfuscation? I.e. is it reasonable enough to implement it all in about a week? Plus I fear like the decompilation/disassembly tooling might be there too soon for it to be a real viable option, but maybe nobody's been working on that yet.

> The best thing to do is to define a "sentinel" to go at the start and end of a sentence. For example, a "$" sign, or a NUL byte.

The $ sign would get in the way if people actually use it in conersation, and maybe other things don't like the NUL byte.

Maybe '\x1F' (ASCII Unit Separator) or '\x1E' (ASCII Record Separator) are better candidates?

> Somehow as I grew older (starting in my mid-30s I suppose), I became more and more aware of how I was affecting other people with my choice of words, and I had less and less reasons to "defeat" people in conversation. When victory is no longer the objective in a discussion, you tend relax, and can choose your words more carefully.

Without trying to invalidate what it is you're saying: Would it be false to say that, you have also realized that how you say things will have consequences on your personal reputation and may be subconsciously taking them into consideration as well?

Mind you, you'll also have to travel out of the country if you're basically anywhere in Europe, where buying anonymous prepaid cards is simply not possible anymore because laws mandate taking and storing the identity of the buyer.

I know this is only tangentially related, but when you're bringing up UNIX philosophy...

> - Store data in flat text files.

Storing encryption keys or the like in flat text files is surprisingly hard, at least in C. I don't think it's even possible to use sscanf(3) without unexpected explosions, and otherwise you get to hand-roll your hex parsing code yourself (Base 64? Get yourself a library).

The man pages that ship with systemd seem very thorough to me. The problem is rather that they're very thorough in the first place. They're a very hard, lengthy read and you kind of require to understand all of it before things begin to make sense.

> 1. Easier case: how to prevent being de-anonymized by curious individuals and specific corporations (e.g., multiple ISP's colluding together may be able to de-anonymize you, but for example a specific company like Google can't).

GitHub is Tor-friendly, so you can piggyback off GitHub pages with Tor/proxies and get something out of that at no cost. Occasionally, they may automatically determine you to be a bot account, but support is responsive and reinstates it within at most days if you seem human enough. Censorship remains an issue, but shoving the pages manually into archive.org should help build some resilience at least.

Maybe mirroring on BitBucket and GitHub will also work.

> 2. Harder case: ensuring anonymity even from state-level actors.

This is a very, very hard problem. Your best bet would probably be compromising a few poorly-secured websites outside the sphere of influence you're trying to hide from, doing this from a public hotspot in a foreign country and then connecting to them only via Tor. Of course, if Tor is enough of a red flag in and of itself, you'll always have to travel to post, which is just as suspicious.

Pick[1] subscribes to a similar philosophy, merging the OS into a database.

[1] https://en.wikipedia.org/wiki/Pick_operating_system

Going by the posts in the forums[1], it's more that BitKeeper has effectively ceased operations in terms of selling its system.

People have noted multiple times that its current build system is fairly hostile to packaging on *NIX, but nobody seems to be putting in the work and the time. I'm somewhat curious about BitKeeper, but not enough to make my first goal to go down into its guts (complete with a custom stdio from NetBSD with modifications!) to make it play nicely with my system.

[1] https://users.bitkeeper.org/t/thoughts-after-a-few-days-with...

On a related note: I've noticed that ffmpeg supports the BCSTM format, which has built-in loop points (unsurprisingly, since it's used for video game music). ffmpeg decodes and stores that information. mpv however doesn't take advantage of that. That's mildly unfortunate.

I'm surprised that microkernel-like IPC still hasn't found its way into any *NIX system. The closest we've gotten is System V IPC, which has never really taken off.

Is this just difficult to design well or are people genuinely okay with socket(AF_UNIX, SOCK_SEQPACKET, 0)?

There aren't enough tutorials and public domain code in the elliptic curve space in general (especially wrt NIST B and K curves).

> No EU or US jurisdiction.

As far as I can tell, they're based in Switzerland. The political pressure if either of them EU cough a bit will probably cause Swiss authorities to fall over immediately. I wouldn't consider myself safe in your position.

While I agree with the notion of making things simple, security theater is worse than no security at all because it makes you feel safe when you may not be.

> Request signature format(crc): [time_stamp]_[md5(time_stamp+secret_key)]

This should probably be an HMAC construction at the very least, and MD5 in general just should be discarded entirely in favor of BLAKE2b, SHA-2 or SHA-3. And ideally, it'd actually validate the rest of the contents as well.

I think we misunderstood each other?

"It" in my post referred to the Rust cargo package in question. The package ships configure.in, but not the generated configure. You do need autoconf for configure.in -> configure. Similarly, it ships Makefile.am, but not the generated Makefile.in for use with configure.

Note how I said "The whole point of autotools is not making your users install them".