kb is a text-oriented minimalist command line knowledge base manager. kb can be considered a quick note collection and access tool oriented toward software developers, penetration testers, hackers, students or whoever has to collect and organize notes in a clean way. Although kb is mainly targeted on text-based note collection, it supports non-text files as well (e.g., images, pdf, videos and others).

The project was born from the frustration of trying to find a good way to quickly access my notes, procedures, cheatsheets and lists (e.g., payloads) but at the same time, keeping them organized. This is particularly useful for any kind of student. I use it in the context of penetration testing to organize pentesting procedures, cheatsheets, payloads, guides and notes.

I found myself too frequently spending time trying to search for that particular payload list quickly, or spending too much time trying to find a specific guide/cheatsheet for a needed tool. kb tries to solve this problem by providing you a quick and intuitive way to access knowledge.

In few words kb allows a user to quickly and efficiently:

collect items containing notes,guides,procedures,cheatsheets into an organized knowledge base;
filter the knowledge base on different metadata: title, category, tags and others;
visualize items within the knowledge base with (or without) syntax highlighting;
grep through the knowledge base using regexes;
import/export an entire knowledge base;

Basically, kb provides a clean text-based way to organize your knowledge.

GitHub CLI brings GitHub to your terminal. It reduces context switching, helps you focus, and enables you to more easily script and create your own workflows. Earlier this year, we announced the beta of GitHub CLI. Since we released the beta, users have created over 250,000 pull requests, performed over 350,000 merges, and created over 20,000 issues with GitHub CLI. We’ve received so much thoughtful feedback, and today GitHub CLI is out of beta and available to download on Windows, macOS, and Linux.

With GitHub CLI 1.0, you can:

Run your entire GitHub workflow from the terminal, from issues through releases
Call the GitHub API to script nearly any action, and set a custom alias for any command
Connect to GitHub Enterprise Server in addition to GitHub.com

Endlessh is an SSH tarpit that very slowly sends an endless, random SSH banner. It keeps SSH clients locked up for hours or even days at a time. The purpose is to put your real SSH server on another port and then let the script kiddies get stuck in this tarpit instead of bothering a real server.

Since the tarpit is in the banner before any cryptographic exchange occurs, this program doesn’t depend on any cryptographic libraries. It’s a simple, single-threaded, standalone C program. It uses poll() to trap multiple clients at a time.

query-json is a faster and simpler re-implementation of the jq language in Reason Native and compiled to binary thanks to the OCaml compiler. query-json, allows you to write small programs to operate on top of json files in a cute syntax:

I wrote a post over the weekend which said a lot about libraries letting people down, and other people becoming overly dependent on them. There was an aside of sorts in there which mentioned teaching people about all of the things to look out for when you’re writing to a file on a Unix-ish/POSIX-ish filesystem situation. A friend reached out asking if I had a post talking about that stuff, and near as I can tell, I do not.

That brings us to right now. I will attempt to lay down a few things that I keep in mind any time I’m creating files.

Linking-it-all-together asks: I came across this article about the benefits of static linking over dynamic linking. If dynamic linking is slower and doesn’t offer practical benefits then why do most distros still dynamic link? Is this a hold over from the past or is there a reason I’m missing that make distros still use dynamic linking?

DistroWatch answers: I read through the article provided and it does share some interesting statistics on dynamically linked programs versus statically linked programs. The author appears to be making a case against dynamic linking and in favour of static linking, or at least presenting facts which would support such a case. For the sake of this discussion I am going to assume the observations the article’s author makes are accurate and factually correct, at least for their own distribution.

The author addresses some interesting questions, such as how often are dynamically libraries used on the system, which indicates how many resources avoid duplication by sharing libraries. They also explore how quickly dynamic and static programs load and how much larger statically linked programs are compared to their dynamically linked counterparts. The author points out that many libraries on their distribution are not shared by many programs, that statically linked programs can load faster, and that not a lot of bandwidth is saved by using dynamically linked programs.

Reading through the page of observations the author shares, it’s understandable we might wonder why developers continue to favour dynamically linked applications in most situations. Let’s look at some of the specific arguments from the article.