msquic VS john-carmack-plan-archive

I referred to sockets as an API design, not to express an opinion on whether you should place your protocol implementations inside or outside the kernel. (Although that’s undeniably an interesting question that by all rights should have been settled by now, but isn’t.)

Even then, I didn’t mean you should reproduce the Berkeley socket API verbatim (ZeroMQ-style); multiple streams per connection does not sound like a particularly good fit to it (although apparently people have managed to fit SCTP into it[1]?). I only meant that with the current mainstream libraries[2,3,4], establishing a QUIC connection and transmitting bytestreams or datagrams over it seems quite a bit more involved than performing the equivalent TCP actions using sockets.

[1] https://datatracker.ietf.org/doc/html/rfc6458

[2] https://quiche.googlesource.com/quiche

[3] https://github.com/microsoft/msquic

[4] https://github.com/litespeedtech/lsquic

The documentation of MS QUIC says it is cross-platform, it should work on Linux, it has a CMake preset for Linux and you can download the prebuilt binary releases for Linux.

Hello HN, my name is Varun, and I am the co-founder of StepSecurity. Here is the backstory about Harden-Runner. We thoroughly researched past software supply chain security incidents. The devastating breaches of SolarWinds, Codecov, and others, have one thing in common – they attacked the CI/ CD pipeline or the build server.

These incidents made it clear that a purpose-built security agent was needed for CI/ CD. While there are numerous agents available for desktops and servers, such as from CrowdStrike and Lacework, none have been tailored specifically to address the unique risks present in CI/CD pipelines.

With the understanding that a specialized solution was needed to secure CI/CD environments, we developed Harden-Runner, an open-source solution tailored specifically for GitHub Actions hosted runners. It can be seamlessly integrated into your workflow by simply adding a step. The agent installation process is also lightning-fast, taking no more than 5 seconds to complete.

Harden-Runner's security agent is designed to closely monitor all aspects of the workflow run, including DNS, network, file, and process events. This allows for real-time identification of any potential security breaches. To prevent incidents like the Codecov breach, where exfiltration of credentials occurred, Harden-Runner allows you to set policies that restrict outbound traffic at both the DNS and network layers. Additionally, we are actively working on implementing further restrictions at the application layer, such as using HTTP verbs and paths, to provide an even more comprehensive security solution.

An excellent example of how Harden-Runner effectively blocks outbound traffic can be found in the following link: https://app.stepsecurity.io/github/microsoft/msquic/actions/.... As you can see, all traffic to unauthorized endpoints is highlighted in red, indicating that it has been blocked; this is because these endpoints are not included in the allowed list defined in the GitHub Actions workflow file, which can be viewed here: https://github.com/microsoft/msquic/blob/aaecb0fac5a3902dd24....

One of the key features of Harden-Runner's monitoring capabilities is its ability to detect any tampering or alteration of files during the build process, similar to the SolarWinds incident. To further enhance security and protect against potential malicious tools or attempts to disable the agent, Harden-Runner includes a disable-sudo mode. This mode effectively disables the use of 'sudo' on the hosted runner, providing an additional layer of protection

Harden-Runner has already been adopted by over 600 open-source repositories: https://github.com/step-security/harden-runner/network/depen.... To fully understand the capabilities of Harden-Runner and how it can protect against past supply chain attacks, please try out our attack simulator GitHub repository at https://github.com/step-security/attack-simulator. I would love to hear your feedback.

https://github.com/microsoft/msquic (QUIC / HTTP3)

I had to laugh at this https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

-----------------------------------------

Yes! Here is the .plan file where Carmack announces its development.

there are a bunch of features in slack beyond the core chat stuff, like:

1. being connected to multiple communities and switching between them instantly

this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack.

2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work

this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive)

3. automatic idleness detection

im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely...

maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want.

4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch

we do use this feature often and it's a really helpful regarding when can we expect a response from someone.

again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos.

5. text search across all channels/rooms

assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too.

6. threads

this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication

7. having threads open on the side, so ppl can track 2 streams of comms at once at least

it would require starting the chat app multiple times and do some window management to see them side-by-side

now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that...

see https://cancel.fm/ripcord/ or http://www.altme.com/what.html

the REBOL 3 programming language even had a quite full featured, text-mode chat built in:

I was impressed by his concise daily planfiles.

https://github.com/ESWAT/john-carmack-plan-archive/tree/mast...

Quake and id Software were pioneering things we just take for granted now.

I remember playing QuakeWorld when it came out, on Linux, over a dial up modem. You had ping times of 200-300ms and it was playable. You have to remember at the time Doom and other games were LAN-only. John Carmack used to keep a .plan file with some really cool details behind Quake/QuakeWorld development. Check out Aug 02, 1996 for some detail behind the netcode[1]. You can read the future of gaming being invented right there.

[1] https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

Perhaps relevant to link to an archive of his .plan files hosted on github: https://github.com/ESWAT/john-carmack-plan-archive/

Instead, you might be interested in looking through John Carmack's .plan archive.

https://github.com/ESWAT/john-carmack-plan-archive/blob/mast... is interesting. It transitions from todo list to a narrative format right after Quake launches :) In subsequent years you see Carmack opine on various high-perf platforms for gamers, and also for Quake level pre-processing (engine licensees had money to spend on productivity)

Chapter 64 onwards of https://www.jagregory.com/abrash-black-book/ is Mike Abrash's detailing of Quake's development.

(tl;dr - Quake was developed on NeXTSTEP + an MS-DOS port of GCC (DJGPP), Quake2 was on Visual Studio + Windows (this was the era of that Carmack giant-monitor photo), there was an in-between period of free updates to the original Quake, like WinQuake, QuakeWorld and glQuake).