Forem: Peter Benjamin (they/them)

Tmux Toggle-able Terminals in Split Panes or Floating Windows

Peter Benjamin (they/them) — Thu, 31 Aug 2023 19:50:59 +0000

Toggle-able Terminal in Tmux

For Vim, Neovim, Helix, or any terminal-based editor

Introduction

(Neo)Vim users are likely familiar with the integrated :terminal. Any time
you need to compile a program or start a long running process, the
:terminal is always near-by.

Popular plugins, like vim-floaterm
and toggleterm.nvim add some nice
ergonomics, like floating windows and key mappings for toggling the terminal.

I have been a long-time user of the integrated terminal until I started
encountering long text outputs, like URLs, that the integrated terminal
hard-wraps them mid-word, instead of soft-wrap.

This meant that what should have been a one-step task of clicking a URL
or copy-pasting text into a Vim buffer has now become a multi-step process of
fixing text by removing line returns. Doing this over-and-over, especially for
large outputs (e.g. logs) gets very tedious very quickly.

Let's explore how we can accomplish a similar experience as vim-floaterm and
toggleterm.nvim, but leveraging tmux instead.

Getting Started

Tmux is a powerful utility. You can configure it using ~/.tmux.conf
configuration file and you can even drive it from within itself (see man tmux
for usage details). For example, tmux split-window will split the current
tmux window into 2 vertical panes.

At a high-level, what we need to accomplish is this:

Bind ctrl-\ to be the keyboard shortcut for toggling the terminal in tmux.
If the current window has only 1 pane, pressing ctrl-\ should create a new pane for the terminal.
If the current window has 2 panes, pressing ctrl-\ should toggle the terminal pane.

First Iteration

Let's set up the key binding to either create a new split or to toggle based on
the current number of panes, like:

bind-key -n 'C-\' if-shell '[ "$(tmux list-panes | wc -l | bc)" = 1 ]' {
  split-window
} {
  resize-pane -Z
}

Explanation:

bind-key -n: this allows us to define keybindings that do not require the tmux prefix or modifier key (ctrl-b by default)
if-shell '<condition>' { true } { false }: this allows us to evaluate some condition and execute the 1st-block if true, otherwise execute the 2nd block.
[ "$(tmux list-panes | wc -l | bc)" = 1 ]: we list the current panes, count the lines, pipe it through a calculator. If we only have 1 pane, then we run split-window to create a new pane, otherwise we leverage the zoom feature to maximize the current pane (i.e. the pane that has the cursor) to fill the entire tmux window (thus hiding the other pane).

This is already a great start. For some, this might be all that you need.

The experience looks like this:

Toggle the terminal with ctrl-\
Move the cursor to the next pane with ctrl-b + o, or ctrl-b + <down> arrows, or even focus the pane with the mouse (if you configure set-option -g mouse on).
When done with the terminal pane, focus the main pane and hit ctrl-\

Having to manually focus tmux panes introduces a bit of friction.

Let's improve this.

Second Iteration

For an experience closer to toggleterm.nvim, where ctrl-\ toggles and
focuses the terminal, then ctrl-\ again hides the terminal and returns the
cursor to the main pane, we need to tweak the second branch (i.e. the
resize-pane logic) to make it a little smarter, like:

bind-key -n 'C-\' if-shell '[ "$(tmux list-panes | wc -l | bc)" = 1 ]' {
- split-window
+ split-window -c '#{pane_current_path}'
} {
- resize-pane -Z
+ if-shell '[ -n "$(tmux list-panes -F ''#F'' | grep Z)" ]' {
+   select-pane -t:.-
+ } {
+   resize-pane -Z -t1
+ }
}

Explanation:

tmux list-panes -F '#F': this lists panes in a custom format. The #F tells tmux to print the "pane flags". Zoomed panes have a Z flag.
If there is a zoomed pane (i.e. the terminal pane is hidden), then we switch focus (via select-pane) to the previous one (i.e. -t:.-).
Otherwise, there is no zoomed pane (i.e. the terminal split pane is shown), so we zoom into pane 1 (via resize-pane -Z -t1).

This is it. We have implemented the core functionality to be able to toggle
terminals with a few lines of tmux configuration.

But, there is still room for improvement. For those who prefer floating
terminal windows, this is for you.

Third Iteration

Let's toggle the terminal in a floating window. Because of the added bit of
complexity here, let's abstract the functionality into a reusable shell script
that we can extend further as needed.

Tmux has a popup feature. In the most basic scenario, you can run tmux popup inside a tmux session (or ctrl-b + :, then type popup and hit
<ENTER>) and a floating window will appear with a terminal shell. However, I
was not able to find a way to toggle this popup window. So, we will combine
pop-ups with tmux sessions so we can detach and attach as the toggle mechanism.

Create a file called it tmux-toggle-term somewhere in your $PATH
(e.g. ~/.local/bin) with the following content:

#!/bin/bash

set -uo pipefail

FLOAT_TERM="${1:-}"
LIST_PANES="$(tmux list-panes -F '#F' )"
PANE_ZOOMED="$(echo "${LIST_PANES}" | grep Z)"
PANE_COUNT="$(echo "${LIST_PANES}" | wc -l | bc)"

if [ -n "${FLOAT_TERM}" ]; then
  if [ "$(tmux display-message -p -F "#{session_name}")" = "popup" ];then
    tmux detach-client
  else
    tmux popup -d '#{pane_current_path}' -xC -yC -w90% -h80% -E "tmux attach -t popup || tmux new -s popup"
  fi
else
  if [ "${PANE_COUNT}" = 1 ]; then
    tmux split-window -c "#{pane_current_path}"
  elif [ -n "${PANE_ZOOMED}" ]; then
    tmux select-pane -t:.-
  else
    tmux resize-pane -Z -t1
  fi
fi

Explanation:

We expose the floating window behind a FLOAT_TERM flag
If FLOAT_TERM string is not empty, then we check the session name. If session name of popup exists, then we detach, otherwise we attempt to attach. If attach fails, then we create a new session.
If FLOAT_TERM string is empty, then we fallback to split panes with the same logic as before.

Next, update your ~/.tmux.conf to replace the previous config from the 1st or
2nd iterations with this:

# for splits
bind-key -n 'C-\' run-shell -b "${HOME}/path/to/tmux-toggle-term"

# or, for floats
bind-key -n 'C-\' run-shell -b "${HOME}/path/to/tmux-toggle-term float"

Tip: (Neo)Vim users who enjoy using the integrated terminal with buffer
completion in insert-mode to avoid copy/paste can still accomplish a similar
with https://github.com/wellle/tmux-complete.vim or
https://github.com/andersevenrud/cmp-tmux

Conclusion

In this post, we have seen how we can accomplish so much with so little.

I hope this inspired you to find ways to make your workflows more efficient and
productive.

FZF + JQ = Interactive JQ (+ a vim bonus)

Peter Benjamin (they/them) — Sat, 20 May 2023 03:09:38 +0000

Problem

Do you frequently query an API and get back a large JSON payload, like:



$ curl https://jsonplaceholder.typicode.com/todos
[
  {
    "userId": 1,
    "id": 1,
    "title": "delectus aut autem",
    "completed": false
  },
  ...
]

So you pipe it to jq, but wish you could interactively query the data?

You may be familiar with some utilities that provide this interactivity, like jqp, but these come with their own downsides, namely subtle bugs due to the re-implementation of the original JQ in language X, but also they are additional dependencies you have to track and install for your platform architecture and OS/distribution.

Solution

Here is a hack (err... ✨ pro-tip ✨) to get JQ interactivity for “free” (as long as you have fzf on your machine):



$ echo '' | fzf --print-query --preview "cat $JSON_FILE_ON_DISK | jq {q}"
$ echo '' | fzf --print-query --preview "cat <(curl $API_URL) | jq {q}"

How does this work?



echo '' | fzf --print-query --preview "cat $JSON_FILE_ON_DISK | jq {q}"
^^^^^^^   ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  [1]          [2]                          [3]

When running fzf, by default it will prompt you to fuzzy search through a list of files in your current working directory. So, we suppress this by echoing an empty string into fzf.
--print-query is an optional flag that will print out the query we typed upon hitting Enter.
--preview flag is what enables all of this. We are using fzf's previewing capability to cat out JSON content, pipe it to jq, injecting our query as jq arguments via {q} placeholder, and we see the results in fzf's preview window.

Further Improvements

We can improve this further by creating a shell script in our global $PATH to turn it into a quick handy utility.

For example, assuming this script is named fjq:



#!/bin/bash

echo '' | fzf-tmux -p '80%' --print-query --preview "cat ${1} | jq {q}"

We can now use this like:



# interactive jq on a single JSON file
$ fjq file.json

# interactive jq on a directory with multiple JSON files
$ fjq /path/to/*.json

# interactive jq on-the-fly
$ fjq <(curl https://jsonplaceholder.typicode.com/todos)

Voila! Interactive json querying with just jq and fzf.

Vim Tip

A semi-interactive experience can be achieved (without FZF) by leveraging Vim's :! and :help filter to filter contents of Vim buffers through an external program and write the output back into Vim's buffers, like:



$ curl https://jsonplaceholder.typicode.com/todos | vim -

# inside vim ...

:%! jq .[].completed
:%! sort | uniq -c

We can even use our previous script for full JQ interactivity:



:! fjq %
" or
:%! fjq %
" or 
:0read ! fjq %

And so on.

Conclusion

We've seen how terminal programs and shell utilities can be composed to create powerful workflows.

We took 2-3 tools that already exist on our system and achieved 80% of what other tools try to accomplish by reimplementing jq in Go, Ruby, Rust, Python, Node.js ...etc.

This is not to say you should not reach for these extra tools, but, in many cases, learning how to leverage existing tools enables you to solve more problems than what these tools were created for.

Happy hacking! 😄

Open Local Files and Line Numbers in GitHub and GitLab From Shell or Vim

Peter Benjamin (they/them) — Wed, 25 Aug 2021 08:17:20 +0000

Update
Problem
Solution
- Git Subcommand
- Vim Command
Conclusion

Update

I have contributed this solution to git-extras.

Now you can enjoy this feature without having to implement & maintain a custom script.

To integrate this new feature with Vim, add the following snippet to your vimrc:

" GitBrowse takes a dictionary and opens files in the browser at the remote URL.
function! GitBrowse(args) abort
  if a:args.filename ==# ''
    return
  endif
  let l:remote = trim(system('git config branch.'.a:args.branch.'.remote || echo "origin" '))
  if a:args.range == 0
    let l:cmd = 'git browse ' . l:remote . ' ' . a:args.filename
  else
    let l:cmd = 'git browse ' . l:remote . ' ' . a:args.filename . ' ' . a:args.line1 . ' ' . a:args.line2
  endif
  execute 'silent ! ' . l:cmd | redraw!
endfunction

command! -range GB call GitBrowse({
      \ 'branch': trim(system('git rev-parse --abbrev-ref HEAD 2>/dev/null')),
      \ 'filename': trim(system('git ls-files --full-name ' . expand('%'))),
      \ 'range': <range>,
      \ 'line1': <line1>,
      \ 'line2': <line2>,
      \ })

Problem

I frequently need to share links and URLs to files in GitHub/GitLab repositories with colleagues.

Traditionally, I did this manually by launching a browser, navigating to the repository and file, then selecting the line numbers in question, and finally copying the permalink or the link of the current branch.

Because this process takes several minutes, it was enough to cause significant context switching and breaks me out of the flow, causing me to lose my train of thought (relevant comic).

One feature I appreciated in vim-fugitive was the :Gbrowse command on a buffer or a range (i.e. :Gbrowse on a visual selection) that would open the current file and line number directly on GitHub.

I wanted to implement this feature in my minimal vim setup, but I also wanted to be able to use this in a shell without vim.

In this blog post, I will walk you through the process of implementing this solution one building block at a time.

Solution

I had an idea of the experience I wanted.

I wanted to be able to call git commands from the shell, like:

# open local repo in GitHub (GH) / GitLab (GL)
$ git browse

# open a file from local repo in GH/GL
# $ git browse <filename>
$ git browse README.md

# open a file & line number from local repo in GH/GL
# $ git browse <filename> <line_number>
$ git browse README.md 1

# open a file & select range of lines from local repo in GH/GL
# $ git browse <filename> <line_from> <line_to>
$ git browse README.md 1 5

And I wanted to be able to call the same functionality within vim, like:

" open current file & line under cursor in GH/GL 
:Gbrowse

" open line range from vim in GH/GL
:1,5Gbrowse

With that rough specification in mind, let's dive into the implementation.

Git Subcommand

If you didn't know, git allows you to define your own custom subcommands as long as the file name starts with git- prefix and the file is located in your $PATH.

With this information in mind, we can start by creating a file called git-browse located in ${HOME}/bin (assuming ${HOME}/bin is in your $PATH)

git-browse file will be a straight forward shell script:

Define shebang and expected inputs:

   #!/usr/bin/env bash

   filename="${1}"
   line1="${2}"
   line2="${3}"

Get some additional data we will need, like branch name, remote name, and remote-url:

   branch=$(git rev-parse --abbrev-ref HEAD 2> /dev/null)
   remote=$(git config branch."${branch}".remote || echo "origin")
   giturl="$(git remote get-url "${remote}")"

I always use HTTPS for git URLs, but if you use SSH, then you would want to convert git@* to https://*. Also, remove the trailing .git in the HTTP URL:

   if [[ $giturl = git@* ]]; then
     giturl=$(echo $giturl | sed -E -e 's/:/\//' -e 's/\.git$//' -e 's/.*@(.*)/http:\/\/\1/')
   fi

   url="${giturl%.git}"

Now we craft the URL with filenames and line numbers based on the domain (GH & GL have slight nuances):

   # GitLab Example: https://gitlab.example.com/group/repo/-/blob/commit_or_branch/path/to/filename#L1-2
   if [[ "${giturl}" =~ gitlab ]]; then
     if [[ -n "${filename}" ]]; then
       commit_hash="$(git log -n1 --format=format:"%H" "${filename}" 2>/dev/null)"
       # append '/-/blob' + commit hash or branch name + '/<filename>'
       url="${url}/-/blob/${commit_hash:-${branch}}/${filename}"
       if [[ -n "${line1}" ]]; then
         # append '#L<LINE1>'
         url="${url}#L${line1}"
     if [[ -n "${line2}" ]]; then
           # append '-<LINE2>'
       url="${url}-${line2}"
     fi
       fi
     fi
   fi

   # GitHub Example: https://github.example.com/org/repo/blob/commit_or_branch/path/to/filename#L1-L2
   # Mostly the same as above, except:
   #   - no '/-/'
   #   - '#L1-L2' instead of '#L1-2'

Lastly, open the crafted URL:

   hash open 2>/dev/null && open "${url}"
   hash xdg-open 2>/dev/null && xdg-open "${url}"

Don't forget to chmod +x ${HOME}/bin/git-browse

Now, these commands should work

$ git browse
$ git browse README.md
$ git browse README.md 1
$ git browse README.md 1 5

And that is half the battle!

TLDR

#!/usr/bin/env bash

filename="${1}"
line1="${2}"
line2="${3}"

branch=$(git rev-parse --abbrev-ref HEAD 2> /dev/null)
remote=$(git config branch."${branch}".remote || echo "origin")
giturl="$(git remote get-url "${remote}")"

# base url
url="${giturl%.git}"

# craft gitlab URLs
if [[ "${giturl}" =~ gitlab ]]; then
    if [[ -n "${filename}" ]]; then
        commit_hash="$(git log -n1 --format=format:"%H" "${filename}" 2>/dev/null)"
        url="${url}/-/blob/${commit_hash:-${branch}}/${filename}"
        if [[ -n "${line1}" ]]; then
            url="${url}#L${line1}"
            if [[ -n "${line2}" ]]; then
                url="${url}-${line2}"
            fi
        fi
    fi

# craft github URLs
elif [[ "${giturl}" =~ github ]]; then
    if [[ -n "${filename}" ]]; then
        commit_hash="$(git log -n1 --format=format:"%H" "${filename}" 2>/dev/null)"
        url="${giturl%.*}/blob/${commit_hash:-${branch}}/${filename}"
        if [[ -n "${line1}" ]]; then
            url="${url}#L${line1}"
            if [[ -n "${line2}" ]]; then
                url="${url}-L${line2}"
            fi
        fi
    fi
fi

hash open 2>/dev/null && open "${url}"
hash xdg-open 2>/dev/null && xdg-open "${url}"

Vim Command

I never imaged I would be saying this, but this is the easy part!

All we need is a Vim command that accepts a range and executes the correct shell command that we implemented above, like:

command! -range Gbrowse execute 'silent ! git browse ' . expand('%') . ' ' . <line1> . ' ' . <line2> | checktime | redraw!

Breakdown:

command! -range allows us to pass a line range, like :1,5Gbrowse, or visual selection. See :help :command-range for more info.
Gbrowse is the name of the command.
execute '...' is going to execute whatever string we pass. See :help :execute for more info.
silent prevents vim from prompting Hit ENTER to continue. See :help :silent for more info.
!git browse is calling the external git subcommand we defined above.
. expand('%') concatenates the current buffer path & name to the previous string. See :help expand() for more info.
' ' . <line1> . ' ' . <line2> concatenates start of range and end of range to the previous string. For example, :1,5Gbrowse translates to !git browse <filename> 1 5. See :help <line1> and :help <line2> for more info.
| checktime | redraw! refreshes the screen and redraws the buffer, otherwise after silently executing an external command, you may see a blank screen in vim.

Demo

For a demonstration of this in action:

Conclusion

What I absolutely love about this is the demonstration of the Unix Philosphy in action. This post illustrates how disparate tools can be composed and used together to create powerful and ergonomic workflows with very little effort.

I hope you enjoyed this post and found some of it useful for your workflows and needs.

If you liked this guide, you may find more useful/interesting things in my vimrc and/or in my custom git subcommands.

For more interesting git subcommands, checkout git-extras.

As always, happy hacking! 🤘🏽

Print Git Status in Your Tmux Statusbar

Peter Benjamin (they/them) — Wed, 18 Aug 2021 04:14:15 +0000

Problem
Solution
- Bash Function
- Git Alias
- Tmux
Conclusion

Problem

I recently wanted to show git branch and status information of the project I am wokring on in tmux statusbar.

We can use one of the many open source projects to achieve this (see the Conclusion for honorable mentions), but I prefer a minimalist approach for simplicity and portability.

Naturally, I know I can invoke any shell command from my .tmux.conf using the #(<shell command>) syntax.

For example, set -g status-right '#(echo "hello world")' will print hello world in the right corner of your tmux statusbar, which is located at bottom by default.

But, doing something like set -g status-right '#(git branch)' didn't work. This is because the command is running in a different shell context, like running sh -c "git branch". The current directory is simply not passed to the sub-shell command.

Furthermore, git branch only prints the branch name. We need a custom bash function to print symbols indicating if there are modified files, staged files, stashes, and/or untracked files.

Solution

Similar to how you can print any information in a .bash_prompt via custom bash functions, so too can we implement a function that is invoked as a git sub-command via aliases.

Bash Function

The function we will use for this is borrowed from jessfraz/dotfiles.

If we simply join all the lines and escape the double-quotes, it looks like this:

prompt_git() { local s=''; local branchName=''; if [ \"$(git rev-parse --is-inside-work-tree &>/dev/null; echo \"${?}\")\" == '0' ]; then if [ \"$(git rev-parse --is-inside-git-dir 2> /dev/null)\" == 'false' ]; then if [[ -O \"$(git rev-parse --show-toplevel)/.git/index\" ]]; then git update-index --really-refresh -q &> /dev/null; fi; if ! git diff --quiet --ignore-submodules --cached; then s+='+'; fi; if ! git diff-files --quiet --ignore-submodules --; then s+='!'; fi; if [ -n \"$(git ls-files --others --exclude-standard)\" ]; then s+='?'; fi; if git rev-parse --verify refs/stash &> /dev/null; then s+='$'; fi; fi; branchName=\"$(git symbolic-ref --quiet --short HEAD 2> /dev/null || git rev-parse --short HEAD 2> /dev/null || echo '(unknown)')\"; echo \"(${1}${branchName} ${s})\"; else return; fi; }

Git Alias

Now, you can put this one-liner into a git alias in your .gitconfig or ~/.config/git/config, like this:

[alias]
    prompt = !"prompt_git() { ... }; prompt_git"

Tip: alternatively, you can copy/paste the bash_prompt function into a shell script file prefixed with git-, like git-prompt, placed somewhere in your $PATH. This allows you to call it as if it were a standard git subcommand as well, like git prompt.

Note that we invoke/execute the function after defining it.

To test this, simply run:

$ git prompt

It should return the branch name and indicators based on your status, like:

(branch +!$?)

Tmux

Now, we can easily call a git command to show this information, but we also need to pass a -C flag with a path to the repo in question. Fortunately, tmux gives us the path of the current pane in a special variable called #{pane_current_path}.

So, our status bar configuration in tmux may look like:

set -g status-right '#(git -C #{pane_current_path} prompt)'

Bonus Tip

Did you know tmux has 2 different "status bars"?

I like to put any global information, or information that does not change between panes, in my status-right. This includes date, time, cpu, and memory.

Any pane-specific information, I prefer to put it in my pane-border-format. This includes current working directory and git status information.

Example:

set -g status-right-length 200
# show [prefix] when activated/pressed + mem/cpu load + date/timestamp
set -g status-right "#{?client_prefix,#[reverse][prefix]#[noreverse],}  #(tmux-mem-cpu-load --interval 1) [%A %Y-%m-%d %l:%M %p]"

set -g pane-border-status top
set -g pane-border-format ' #{pane_current_path} #(git -C #{pane_current_path} prompt) '

Conclusion

If you are a minimalist like me, I hope this helps you configure and customize your tmux to best suit your needs, workflow, and productivity.

If you were hoping to discover tools or utilities to conveniently configure tmux, then I would like to leave you with some honorable mentions:

gitmux: a binary that you can simply download, configure, and execute in your .tmux.conf. No runtime dependencies needed.
powerline: a fully-featured statusline utility for vim, tmux, and more. Requires python.
tmux-git: a tmux plugin.

For more inspiration, feel free to browse my dotfiles.

Thank you for reading.

Happing hacking!

How To Get Make Target Tab Completion in Vim

Peter Benjamin (they/them) — Sun, 08 Aug 2021 04:26:09 +0000

Problem
Solution
Improved

Problem

If you use make frequently, you may be aware that you can tab complete targets in bash. For example, $ make cl<TAB> ins<TAB> may autocomplete to clean then install.

In vim, however, if you type :make <TAB>, by default, vim attempts to autocomplete file names.

This blog post will show you how you can get vim to autocomplete <TAB> with target names from your Makefile instead.

Solution

I recently came across this StackOverflow question, How to list all targets in make?, in which the answer is bash's completion logic:

make -qp |
    awk -F':' '/^[a-zA-Z0-9][^$#\/\t=]*:([^=]|$)/ {split($1,A,/ /);for(i in A)print A[i]}' |
    sort -u

This will print out a newline-delimited list of possible targets from the Makefile in your current working directory.

With this set of commands, we can write a custom vimscript function that executes them and returns the output as completion candidates for a vim command:

function! MakeCompletion() abort
    return systemlist('make -qp | awk -F'':'' ''/^[a-zA-Z0-9][^$#\/\t=]*:([^=]|$)/ {split($1,A,/ /);for(i in A)print A[i]}'' | grep -v Makefile | sort -u')
endfunction

command! -nargs=* -complete=customlist,MakeCompletion Make !make <args>

This alone is a great accomplishment. If you type :Make <TAB>, you can cycle through all the possible make targets!

However, you may notice that if you type part of a target name and hit <TAB>, vim will ignore the partial input and cycle through from the beginning of the list.

Improved

If you read :help :command-completion-customlist, you will discover that the function can take 3 arguments:

The function arguments are:
    ArgLead     the leading portion of the argument currently being completed on
    CmdLine     the entire command line
    CursorPos   the cursor position in it (byte index)

So let's modify our MakeCompletion() function to support filtering results based on ArgLead:

function! MakeCompletion(A,L,P) abort
    let l:targets = systemlist('make -qp | awk -F'':'' ''/^[a-zA-Z0-9][^$#\/\t=]*:([^=]|$)/ {split($1,A,/ /);for(i in A)print A[i]}'' | grep -v Makefile | sort -u')
    return filter(l:targets, 'v:val =~ "^' . a:A . '"')
endfunction

command! -nargs=* -complete=customlist,MakeCompletion Make !make <args>

Now, when you type :Make cl<TAB> ins<TAB>, it will successfully auto-complete to :Make clean install.

I hope you find this short vim tip helpful.

For more vim goodies, check out my vimrc.

Happy hacking!

A Workflow for Cloning and Launching Git Repositories in New tmux Windows

Peter Benjamin (they/them) — Sun, 25 Jul 2021 16:02:28 +0000

Overview
The Setup
Bonus
Summary

Overview

One thing I really like about Visual Studio Code is the ability to clone a repo and open it in the editor with little-to-no friction in 3 quick steps:

In the Command Palette, select: > Git: clone
Enter the repo to clone
Select the directory to clone into

Then Visual Studio Code launches a new editor in the repo and I'm ready to go.

I want to have a similar experience in my terminal-based development workflow.

The Solution

At a high-level, my current solution is to invoke a bash function that prompts the user for the repo to clone and directory to clone it into, then run vim on the repo in a new tmux window.

Here is the implementation as a bash script:

git-clone-tmux() {
    local repo=""
    local directory=""
    local clone_path=""

    repo="${1}"
    directory="${2}"

    [ -z "${repo}" ] && read -e -p "Repo: " repo
    [ -z "${directory}" ] && read -e -p "Directory: " -i "${HOME}/Work" directory

    if [[ "${repo}" =~ ^github ]] || [[ "${repo}" =~ "${GH_HOST}" ]]; then
        clone_path="${directory}/${repo}"
        gh repo clone "${repo}" "${clone_path}"
    elif [[ "${repo}" =~ ^gitlab ]] || [[ "${repo}" =~ "${GL_HOST}" ]]; then
        clone_path="${directory}/${repo}"
        glab repo clone "${repo}" "${clone_path}"
    else
        clone_path="${directory}/$(basename ${repo})"
        git clone "${repo}" "${clone_path}"
    fi

    tmux new-window -c "${clone_path}" -n "${clone_path}" vim .
}

What happens when you run $ git-clone-tmux?

[ -z "${repo}" ] && read -e -p "Repo: " repo
- If ${repo} is empty, then prompt user interactively
[ -z "${directory}" ] && read -e -p "Directory: " -i "${HOME}/Work" directory
- If ${directory} is empty, then prompt user interactively
if [[ "${repo}" =~ ^github ]]
- If ${repo} starts with github, then use gh to clone the repo
if [[ "${repo}" =~ ^gitlab ]]
- If ${repo} starts with gitlab, then use glab to clone the repo
otherwise, assume ${repo} starts with https://
tmux new-window -c "${clone_path}" -n "${clone_path}" vim .
- Launch new tmux window, setting the working directory to the newly cloned repo, and run vim .

Bonus

You can create a git alias so that you can call this function as if it were a git subcommand.

Just run the following:

$ git config --global alias.clone-tmux '!/usr/bin/env bash -ic git-clone-tmux'

Or add the following to your git config file:

[alias]
    clone-tmux = !/usr/bin/env bash -ic git-clone-tmux

Now, you can run git clone-tmux <repo> <dir> or git clone-tmux for interactive prompting.

Extra bonus: shell tab completions work on git aliases too!

Summary

This is, by no means, the most elegant script, but it works for me needs.

I hope you enjoyed reading this article and I hope it inspires you to find ways to streamline and improve your workflow and productivity!

For more git alias goodies, check out my .config/git/config dotfile.

For more bash function goodies, check out my .functions dotfile.

Happy hacking!

Interactive Fuzzy Finding in Vim without Plugins

Peter Benjamin (they/them) — Sun, 25 Jul 2021 03:11:02 +0000

Overview
The Setup
Bonus
Caveat
Summary

Overview

FZF is a great command-line fuzzy-finder and there is fzf.vim plugin that integrates with Vim to provide features, like :Files to fuzzy search over files and :Rg to fuzzy search over text using ripgrep.

Recently, however, I have been experimenting with a plugin-free Vim setup and while :find is sufficient for some use-cases, I found myself quitting vim and running fzf to find deeply nested files in new or large projects.

There has to be a simple way to integrate a command-line program with a command-line editor, right?

The Setup

This setup is simple and it leverages a feature in vim called quickfix.

The flow is:

Call fzf
Format the output to make it compatible with errorformat
Write the results to a temporary file
Load the results into Vim's quickfix list with :cfile or :cgetfile, so that we can navigate through the results with :cnext/:cprevious or :copen
Clean up temporary file

Here is what the final vimscript looks like:

function! FZF() abort
    let l:tempname = tempname()
    " fzf | awk '{ print $1":1:0" }' > file
    execute 'silent !fzf --multi ' . '| awk ''{ print $1":1:0" }'' > ' . fnameescape(l:tempname)
    try
        execute 'cfile ' . l:tempname
        redraw!
    finally
        call delete(l:tempname)
    endtry
endfunction

" :Files
command! -nargs=* Files call FZF()

" \ff
nnoremap <leader>ff :Files<cr>

A quick breakdown:

let l:tempname = tempname()
- Generate a path to a temporary file and store it in a variable.
- See :h tempname()
execute 'silent !fzf --multi ' . '| awk ''{ print $1":1:0" }'' > ' . fnameescape(l:tempname)
- Call fzf with --multi to allow for selecting multiple files
- Pipe to awk to append :1:0 to fzf results to make them errorformat-compatible.
- Note: you can drop this awk command if you set errorformat+=%f in your vimrc, but I found %f to capture a lot of false-positives from other programs' outputs and therefore :cnext/:cprevious don't function on these false-positive results.
- Finally, direct the results into the temp file
execute 'cfile ' . l:tempname
- Load results from temp file into quickfix list and jump to the 1st result.
- Note #1: you may use :cgetfile to only load results into quickfix list without jumping to the 1st result.
- Note #2: you may replace :cfile/:cgetfile with :lfile/:lgetfile to use location list instead of quickfix list. Location lists are window-specific, whereas quickfix lists are global. So if you prefer to have different set of results per vim window, then use :lfile/:lgetfile.
call delete(l:tempname)
- Clean up by deleting the temp file
command! -nargs=* Files call FZF()
- Invoke FZF() function when we call :Files in vim
nnoremap <leader>ff :Files<cr>
- Normal-mode mapping so that we can trigger this flow with <leader>ff

Bonus

While :set grepprg=rg\ --vimgrep is again sufficient for most of my use-cases, those who have used :Rg in fzf.vim will appreciate the interactive fuzzy grepping experience and the ability to preview results before opening files in vim.

Well, here is a similar experience with pure vim (obviously, fzf and rg binaries are still required):

function! RG(args) abort
    let l:tempname = tempname()
    let l:pattern = '.'
    if len(a:args) > 0
        let l:pattern = a:args
    endif
    " rg --vimgrep <pattern> | fzf -m > file
    execute 'silent !rg --vimgrep ''' . l:pattern . ''' | fzf -m > ' . fnameescape(l:tempname)
    try
        execute 'cfile ' . l:tempname
        redraw!
    finally
        call delete(l:tempname)
    endtry
endfunction

" :Rg [pattern]
command! -nargs=* Rg call RG(<q-args>)

" \fs
nnoremap <leader>fs :Rg<cr>

This offers the same experience where:

:Rg without arguments will load all text into vim and allow users to interactively type and preview results before selecting files
:Rg [pattern] will pre-filter results to just ones that match [pattern] before passing them to fzf for further fuzzy searching.

Caveat

In my testing, I found one major caveat that did not impact me too much, but it is still worth calling out here:

Executing shell commands in vim with bangs, like :!fzf, is not meant to be interactive (at least, not out of the box). This could be a problem in GVim/MacVim. The vim docs mention the following workaround:

On Unix the command normally runs in a non-interactive shell. If you want an interactive shell to be used (to use aliases) set 'shellcmdflag' to "-ic".

Setting shellcmdflag=-ic could incur a time penalty, depending on your shell startup/initialization times.

Summary

Vim is extremely versatile and customizable.

With some knowledge of vim concepts (e.g. quickfix, :cfile/:lfile) and a little bit of (vim & bash) scripting, you can achieve a richer experience and pleasant integrations to enhance your productivity in a way that suits you and your workflow.

I hope you enjoyed this post and I hope it inspires you to develop and share your productivity tips and tricks in vim.

Happy hacking!

Search For GIFs Without Leaving Your Terminal

Peter Benjamin (they/them) — Thu, 31 Dec 2020 20:48:55 +0000

Problem

Have you ever wanted to search for GIFs from the terminal?

Perhaps it's just me, but I do a lot in the terminal, from writing code and debugging programs to searching and browsing the web (via ddgr + !bangs).

When I am reviewing Pull Requests (via gh or glab), I often like to post a funny GIF as a comment when I'm approving the PR (hopefully to leave the collaborator with a smile).

Initially, I did this by going to a site, like giphy.com, then searching for a GIF, then several clicks later, I got a GIF URL that I can copy/paste into the terminal. This obviously broke my workflow.

Solution

The second iteration of this used ddgr, a command-line interface for DuckDuckGo. Using the !gif or !giphy bang (e.g. ddgr --no-prompt '!gif yay') did save me a few steps as it takes me right to Giphy's search results where I can get a GIF URL with a few clicks. However, because this still requires a browser, it doesn't work for all the times I work on remote development servers (e.g. GCP Always Free Compute Engine, Raspberry Pi ...etc).

I needed a different solution that was completely in the terminal.

I couldn't find a dependency-free^* CLI utility that really suit my needs. So, I decided to write a dependency-free CLI utility that allows you to search for GIFs from giphy.com and return a URL.

And it fits in a tweet.

Here it is:

$ giphy() { [ -z "${1}" ] && return 1 || curl -fsSL https://giphy.com/search/${1} | rg -oP "(?<=gifs: ).*?(?=,$)" | jq ".[$(echo $(( $RANDOM % 25 )) )] | .images.original.url" | tr -d '"'; };

Let's break it down:

[ -z "${1}" ] && return 1 || ... : this is kind of a ternary operation in Bash. If the 1st argument is empty, then return non-zero exit code, otherwise ...
curl -fsSL https://giphy.com/search/${1}: this is pretty straight-forward. We use curl to query the site.
rg -oP "(?<=gifs: ).*?(?=,$)": this uses Positive Lookbehind (?<=...) and Positive Lookahead (?=...) Regular Expressions (see this for more info) to match the text that is between gifs: and , at the end of the same line in the HTML response. This is where we have a JSON list of 25 GIFs from the 1st results page.
jq ".[$(echo $(( $RANDOM % 25 )) )] | .images.original.url": here we use jq ".[] | .images.original.url" to parse the JSON list and get at the URL we need. The $(echo $(( $RANDOM % 25 )) ) is a Bash way of picking a random number between 0 and 25. Another way we could do this is shuf -i 0-25 -n 1 (see shuf manual pages for more info).
tr -d '"': finally, we trim the double-quotes from the URL.

That's it. Now, we can compose this utility with other tools to spread smiles, like $ gh pr review --approve --comment -b "![yay]($(giphy yay))"

Conclusion

This is why I love the terminal. It gives me the freedom and flexibility to creatively solve a problem and re-use it in composable ways. Check out this blog post for additional reading on the merits of CLIs.

I am, by no means, a Bash or Regular Expressions expert and I am sure there are many opportunities for improvement here. So, feel free to leave your ideas, thoughts, suggestions for improvements, or GIFs in the comments section below!

Also, contributions are welcome on the GitHub repo: https://github.com/pbnj/giphy-cli

Happy coding!

Footnotes

^* My Bash one-liner is not 100% dependency-free. It requires curl, rg for a consistent grep utility between macOS & Linux, & jq for command-line JSON parsing. Most GIF CLI utilities I found required system dependencies and entire development toolchains (e.g. ffmpeg, python3, dotnet, ...etc).

Unit Test Your Configuration Files

Peter Benjamin (they/them) — Thu, 20 Feb 2020 10:32:59 +0000

Infrastructure as Code. Photo courtesy: @Bass Emmen

Originally published at https://pbnj.dev

Overview
Getting Started
- Dockerfile
- Kubernetes
Next Steps

Overview

The era of Infrastructure-as-Code (IaC) has unlocked tremendous developer
productivity and agility features. Now, as an Engineer, we can declare our
infrastructure and environments as structured data in configuration files, such
as Terraform templates, Dockerfiles, and Kubernetes manifests.

However, this agility and speed of provisioning and configuring infrastructure
comes with a high risk of bugs in the form of misconfigurations.

Fortunately, we can solve this problem just as we can solve for other bugs in
our products, by writing unit tests.

One such tool that can help us unit test our configuration files is
conftest. What is unique about
conftest is that it uses
Open-Policy-Agent (OPA) and a policy
language, called
Rego to
accomplish this.

This might appear difficult at first, but it will start to make sense.

Let's explore 2 use-cases where we can test our configurations!

Getting Started

First, some prerequisites:

conftest:
- macOS: brew install instrumenta/instrumenta/conftest
(Optional) opa:
- macOS: brew install opa

Dockerfile

Let's say we want to prevent some images and/or tags (e.g. latest).

We need to create a simple Dockerfile:

FROM kalilinux/kali-linux-docker:latest

ENTRYPOINT ["echo"]

Now, we need to create our first unit test file, let's call it test.rego, and
place it in a directory, let's call it policy (this is configurable).

package main

disallowed_tags := ["latest"]
disallowed_images := ["kalilinux/kali-linux-docker"]

deny[msg] {
        input[i].Cmd == "from"
        val := input[i].Value
        tag := split(val[i], ":")[1]
        contains(tag, disallowed_tags[_])

        msg = sprintf("[%s] tag is not allowed", [tag])
}

deny[msg] {
        input[i].Cmd == "from"
        val := input[i].Value
        image := split(val[i], ":")[0]
        contains(image, disallowed_images[_])

        msg = sprintf("[%s] image is not allowed", [image])
}

Assuming we are in the right directory, we can test our Dockerfile:

$ ls
Dockerfile      policy/

$ conftest test -i Dockerfile ./Dockerfile
FAIL - ./Dockerfile - [latest] tag is not allowed
FAIL - ./Dockerfile - [kalilinux/kali-linux-docker] image is not allowed

Just to be sure, let's change this Dockerfile to pass the test:

# FROM kalilinux/kali-linux-docker:latest
FROM debian:buster

ENTRYPOINT ["echo"]

$ ls
Dockerfile      policy/

$ conftest test -i Dockerfile ./Dockerfile
PASS - ./Dockerfile - data.main.deny

"It works! But I don't understand how," I hear you thinking to yourself.

Let's break the Rego syntax down:

package main is a way for us to put some rules that belong together in a namespace. In this case, we named it main because conftest defaults to it, but we can easily do something like package docker and then run conftest test -i Dockerfile --namespace docker ./Dockerfile
disallowed_tags & disallowed_images are just simple variables that hold an array of strings
deny[msg] { ... } is the start of the deny rule and it means that the Dockerfile should be rejected and the user should be given an error message msg if the conditions in the body (i.e. { ... }) are true
Expressions in the body of the deny rule are treated as logical AND. For example:

  1 == 1                    # IF 1 is equal to 1
  contains("foobar", "foo") # AND "foobar" contains "foo"
                            # This would trigger the deny rule

input[i].Cmd == "from" checks if the Docker command is FROM. input[i] means we can have multiple Dockerfiles being tested at once. This will iterate over them
The next 2 lines are assignments just to split a string and store some data in variables
contains(tag, disallowed_tags[_]) will return true if the tag we obtained from the Dockerfile contains one of the disallowed_tags. array[_] syntax means iterate over values
msg := sprinf(...) creates the message we want to tell our user if this deny rule is triggered
The second deny[msg] rule checks that the image itself is not on the blocklist.

Kubernetes

Let's say we want to ensure that all pods are running as a non-root user.

We need to create our deployment

$ mkdir -p kubernetes
$ cat <<EOF >./kubernetes/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80
EOF

Now, we need to create our unit test:

$ mkdir -p ./kubernetes/policy
$ cat <<EOF >./kubernetes/policy/test.rego
package main

name := input.metadata.name

deny[msg] {
  input.kind == "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot

  msg = sprintf("Containers must run as non root in Deployment %s. See: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/", [name])
}
EOF

And, let's run it:

conftest test -i yaml ./kubernetes/deployment.yaml
FAIL - ./kubernetes/deployment.yaml - Containers must run as non root in Deployment nginx-deployment. See: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

This is a bit more straightforward:

Get the metadata.name from the input (which is the Kubernetes Deployment yaml file)
Create a deny rule that is triggered if:
- input.kind is Deployment and
- securityContext.runAsNonRoot is not set
Return an error message to the user that containers must run as non-root and point them to the docs.

Next Steps

So, where to go from here?

The Rego language is vast and it can take a bit to wrap your head around how it
works. You can even send and receive HTTP requests inside Rego.

I recommend reading the docs to learn more about Rego's capabilities:

I also barely scratched the surface with conftest in this blog post. The
repository has a nice list of
examples that you should
peruse at your leisure. conftest even supports sharing policies via uploading
OPA bundles to OCI-compliant registries, e.g. conftest push ...,
conftest pull ....

Lastly, if you have any questions, the OPA community is friendly and welcoming.
Feel free to join the #conftest channel in
OPA Slack.

Happy coding!

Effective Security Programs

Peter Benjamin (they/them) — Wed, 01 Jan 2020 08:36:33 +0000

This article was originally published on https://pbnj.dev.

Overview
Culture
- Listen to Your Users
- Hold Office Hours, Community Meetings, Events
- Create a Security Champion Program
Engineering
- Invest in Tooling, APIs, Services
- Contribute to Engineering
- Practice What You Preach
TLDR

Overview

As we approach the end of a year and a decade, I decided to write down my reflections on my experiences in the Information Security (InfoSec) field.

This is also, in part, coming from someone (me) who has struggled with how security gets done at most places and nearly quit the field (on more than 1 occassion) due to so many bad (at best) and toxic (at worst) security teams and cultures out there.

It all boils down to this: Security is a service & you are a service provider.

To unravel this, let's explore what effective and successfull Security programs look like from a culture and engineering perspectives.

If you want the Too-Long; Didn't Read version, skip to the TLDR section.

Culture

Information Security is not only a technical problem, it is also a people problem, specifically, security people. Our perceptions and reputations preceed us, and they're not the good ones either.

We often come off as anisolated, egotistical, self-absorbed bunch with a god complex.

So, how can we fix our perception and reputation?

Listen to Your Users

Our job is to enable developers and operations teams to do their work securely and effectively.

As such, how do we expect to help them without listening to them, without understanding their business needs, without asking them how we can help them better?

Before you walk into the office, thinking you're a hero about to save the day, stop and check your ego at the door:

Ask your users what is their biggest problem or challenge when it comes to security?
- If the answer is knowledge, then invest in education.
- If the answer is management, then work with project management and leadership to demonstrate the business value of paying down technical debt and improving software quality (hint: security is a subset of quality).
- If the answer is technology, then invest in developer-friendly tooling.
- If the answer is culture, then look in the mirror and try to see why your users avoid you like the plague.
Ask your users for their feedback on your work. What is working well? What is not working well? How would they suggest/recommend you improve? You'll be surprised by what they say, one way or another.

Hold Office Hours, Community Meetings, Events

Most engineers love to learn new topics and concepts, so they could share with their teams or improve their work.

Hold weekly, bi-weekly, or monthly lunch-and-learn sessions or office hours to dive into a topic of their choosing.
Put on a quarterly or bi-annually Capture-The-Flag (CTF) competition or a hack-a-thon around enabling, improving, or automating security engineering (who knows, you might even find a few engineers with a knack or a passion for security who might want to join your team?).

This doubles as a means to build or improve relationships with your users.

Create a Security Champion Program

Not only is security a niche field, it is also a thankless job. Yet, I have always noticed 1 or 2 engineers on every product development team that always go above and beyond their work to improve security in their projects, however small of an improvement it is.

Create a Security Champion program to designate engineers as primariy security points of contact, to recognize them for their work, and to form a support group of sorts for engineers who have to carry this mantle. Give them the space to share their challenges and their learnings with each other and with you. It's not easy being under constant pressure from project management to deliver on customers' priorities within tight timelines and do extra-curricular activities.

This Security Champion program also doubles as a bi-directional channel of communication between Security and Product Development teams that reinforces the first point I made, i.e. listening to your users.

Engineering

As mentioned before, product developers are under project management pressures to deliver within tight timelines and deadlines. If all we are doing is piling on, we are failing.

Engineers, on product development teams or operations teams, are often closest to the product than InfoSec teams are. They likely know more about potential security concerns or vulnerabilities in their products than we do.

You giving them a security report generated from a vulnerability scanner is the least helpful thing you can do.

Invest in Tooling, APIs, Services

It is our job to enable our users to do their work securely and effectively.

This means we should be making their lives easier, not harder.

There is absolutely no reason we should be requiring our users to fill out forms and submit tickets to get their work done. Instead, we should be enabling them to be self-sufficient.

For example:

If you require a threat model, provide tooling to automate generating threat models. If no tooling exists, or if existing tooling is insufficient, build the right tooling for your business.
If you require security standards or benchmarks to be followed, provide tooling to automate the scanning or analysis of possible misconfigurations.

Here are some folks who are much smarter than I on the subject:

Contribute to Engineering

Remember that security report generated from a vulnerability scanner?

Here are some crazy ideas, what if you:

Validate the finding(s), weed out the false-positives, measure and assess the risk of each finding against the realities of the product and business needs, then work with the respective team(s) to remediate the issue, or even contribute the fix yourself?
Contribute security unit tests to prevent that bug from recurring?
Offer to peform security code reviews if engineers are working on sensitive/critical parts of the system (e.g. user input, certificate management)?
Contribute additional security checks in CI pipelines?

Yes, most of these tasks would require you to operate closely with your users... As if you're actually one of them; an engineer on their team, but with a security background.

Now, you finally understand what DevSecOps and Shift Left truly entail!

Practice What You Preach

If you require threat models for every service, then start with your own.
If you require security bugs to be remediated within an SLA, then start with your own bugs.
If you don't or you can't, then you are in no position to tell engineers to do that work.

Plain and simple.

TLDR

The short version of my rambling is this:

Security is a Service. You are a Service Provider.
Fix your culture
- Listen to your users. Ask them what they need. Ask them for their feedback on your work.
- Hold office hours, community meetings, events to build/improve relationships with your users.
- Create a Security Champion program to designate engineers as security points of contact, to recognize their efforts, and to allow them to share knowledge with each other and with the security team (going back to listening to your users).
Enable engineers to do their work securely and effectively
- Automate manual processes. Don't introduce friction.
- Contribute directly to engineering teams.
- Practice what you preach.

Demystifying STRIDE Threat Models

Peter Benjamin (they/them) — Sat, 08 Dec 2018 08:40:38 +0000

Introduction
What is a Threat Model?
What is STRIDE?
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privileges
Summary
Additional Resources

Introduction

Software is eating the world. As a result, the repercussions of software failure is costly and, at times, can be catastrophic. This can be seen today in a wide variety of incidents, from data leak incidents caused by misconfigured AWS S3 buckets to Facebook data breach incidents due to lax API limitations to the Equifax incident due to the use of an old Apache Struts version with a known critical vulnerability.

Application Security advocates encourage developers and engineers to adopt security practices as early in the Software Development Life Cycle (SDLC) as possible ¹. One such security practice is Threat Modeling.

In this article, I offer a high-level introduction to one methodology, called STRIDE, and in a future article, I will demonstrate this process using an existing open-source application as an example.

What is a Threat Model?

Here is the obligatory Wikipedia definition:

Threat modeling is a process by which potential threats, such as structural vulnerabilities, can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view. The purpose of threat modeling is to provide defenders with a systematic analysis of the probable attacker’s profile, the most likely attack vectors, and the assets most desired by an attacker.

With that out of the way, the simplest explanation in English is this:

Threat Models are a systematic and structured way to identify and mitigate security risks in our software.

There are various ways and methodologies of doing threat models, one of which is a process popularized by Microsoft, called STRIDE.

What is STRIDE?

STRIDE is an acronym that stands for 6 categories of security risks: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges.

Each category of risk aims to address one aspect of security.

Let's dive into each of these categories.

Spoofing

Spoofing refers to the act of posing as someone else (i.e. spoofing a user) or claiming a false identity (i.e. spoofing a process).

This category is concerned with authenticity.

Examples:

One user spoofs the identify of another user by brute-forcing username/password credentials.
A malicious, phishing host is set up in an attempt to trick users into divulging their credentials.

You would typically mitigate these risks with proper authentication.

Tampering

Tampering refers to malicious modification of data or processes. Tampering may occur on data in transit, on data at rest, or on processes.

This category is concerned with integrity.

Examples:

A user performs bit-flipping attacks on data in transit.
A user modifies data at rest/on disk.
A user performs injection attacks on the application.

You would typically mitigate these risks with:

Proper validation of users' inputs and proper encoding of outputs.
Use prepared SQL statements or stored procedures to mitigate SQL injections.
Integrate with security static code analysis tools to identify security bugs.
Integrate with composition analysis tools (e.g. snyk, npm audit, BlackDuck ...etc) to identify 3rd party libraries/dependencies with known security vulnerabilities.

Repudiation

Repudiation refers to the ability of denying that an action or an event has occurred.

This category is concerned with non-repudiation.

Examples:

A user denies performing a destructive action (e.g. deleting all records from a database).
Attackers commonly erase or truncate log files as a technique for hiding their tracks.
Administrators unable to determine if a container has started to behave suspiciously/erratically.

You would typically mitigate these risks with proper audit logging.

Information Disclosure

Information Disclosure refers to data leaks or data breaches. This could occur on data in transit, data at rest, or even to a process.

This category is concerned with confidentiality.

Examples:

A user is able to eavesdrop, sniff, or read traffic in clear-text.
A user is able to read data on disk in clear-text.
A user attacks an application protected by TLS but is able to steal x.509 (SSL/TLS certificate) decryption keys and other sensitive information. Yes, this happened.
A user is able to read sensitive data in a database.

You would typically mitigate these risks by:

Implementing proper encryption.
Avoiding self-signed certificates. Use a valid, trusted Certificate Authority (CA).

Denial of Service

Denial of Service refers to causing a service or a network resource to be unavailable to its intended users.

This category is concerned with availability.

Examples:

A user performs SYN flood attack.
The storage (i.e. disk, drive) becomes too full.
A Kubernetes dashboard is left exposed on the Internet, allowing anyone to deploy containers on your company's infrastructure to mine cryptocurrency and starve your legitimate applications of CPU. Yes, that happened too.

Mitigating this class of security risks is tricky because solutions are highly dependent on a lot of factors.

For the Kubernetes example, you would mitigate resource consumption with resource quotas.

For a storage example, you would mitigate this with proper log rotation and monitoring/alerting when disk is nearing capacity.

Elevation of Privileges

Elevation of Privileges refers to gaining access that one should not have.

This category is concerned with authorization.

Example:

A user takes advantage of a Buffer Overflow to gain root-level privileges on a system.
A user with limited to no permissions to Kubernetes can elevate their privileges by sending a specially crafted request to a container with the Kubernetes API server's TLS credentials. Yes, this was possible.

Mitigating these risks would require a few things:

Proper authorization mechanism (e.g. role-based access control).
Security static code analysis to ensure your code has little to no security bugs.
Compositional analysis (aka dependency checking/scanning), like snyk or npm audit, to ensure that you're not relying on known-vulnerable 3rd party dependencies.
Generally practicing least privilege principle, like running your web server as a non-root user.

Summary

So, STRIDE is a threat model methodology that should help you systematically examine and address gaps in the security posture of your applications.

In a future article, we'll take an application and go through this process so you can get a feel for how this works.

If you would like to propose an application for me to threat model next, feel free to drop suggestions in the comments below.

Additional Resources

Footnotes

1: https://www.youtube.com/watch?v=YGJqpQy79no&WT.mc_id=shehackspurple-blog-tajanca

Updates

Add more mitigations against tampering.
Add more mitigations against information disclosure.

What Genres Do You Listen To?

Peter Benjamin (they/them) — Wed, 21 Nov 2018 06:11:56 +0000

I enjoyed reading the following article by a fellow Dev.to'er:

Favourite albums to listen to while coding

Hussein Al Hammad ・ Nov 18 '18

#music #productivity

And I wanted to share with the community what I listen to.

I have different modes for when I'm coding, hacking (e.g. bug bounties), working (e.g. writing emails), or just doing mind-numbing chores.

The following is what I jam to for each of those modes.

Coding

No distractions. No lyrics. Soft tracks are ideal, but not too soft that I would fall asleep during late-night coding sessions.

Genres that meet these criteria: Chill Step, Deep House, Liquid Trap

Spotify playlists:

Hacking

Get pumped and get in the mood 😈 with upbeat jams. Fast, electronic beats with sick bass drops are ideal. Lyrics are fine too.

Genres that meet these criteria: Drum and Bass, EDM, Trap, Dubstep, Nightcore

Spotify playlists:

Working

Upbeat, poppy, but not-too-fast tracks hits the spot for this category.

Genres that meet this criteria: ePop

Spotify playlists:

Chores

Podcasts, actually. Word? 🤓

Wait. Hear me out.
Because of the inherent nature of chores, I don't need focus on the minutiae of the task. Instead, I take these opportunities to catch up on the many technical/coding/engineering podcasts.

Genres that meet these criteria: Podcasts

Spotify actually has podcasts you can listen to, but I will shamelessly plug my collection of awesome-podcasts 😅

Miscellaneous

Every once in a while, I get a craving for something entirely new and different, but they still tend to fall within broader categories.

Genres that meet these criteria: Synthpop, Remixes, Hip Hop, but with a twist 👩‍🎤👨‍🎤

Spotify playlists:

Women Wa Bas! - Arab women in one playlist
Arab Hip-Hop
Arab X - Global cross-overs with/by Arab artists
Arab Raggae
Hacking - Synthpop
Synthpop / Electronic / Dark Wave
Pop / Rock Remix
Remixes Of Popular Songs
K-Pop Daebak
K-Pop Rising
JPop / Anime

I love getting exposed to new music, so what do you listen to?

Forem: Peter Benjamin (they/them)

Tmux Toggle-able Terminals in Split Panes or Floating Windows

Toggle-able Terminal in Tmux

Introduction

Getting Started

First Iteration

Second Iteration

Third Iteration

Conclusion

FZF + JQ = Interactive JQ (+ a vim bonus)

Problem

Solution

How does this work?

Further Improvements

Vim Tip

Conclusion

Open Local Files and Line Numbers in GitHub and GitLab From Shell or Vim

Table of Contents

Update

Problem

Solution

Git Subcommand

TLDR

Vim Command

Demo

Conclusion

Print Git Status in Your Tmux Statusbar

Table of Contents

Problem

Solution

Bash Function

Git Alias

Tmux

Bonus Tip

Conclusion

How To Get Make Target Tab Completion in Vim

Table of Contents

Problem

Solution

Improved

A Workflow for Cloning and Launching Git Repositories in New tmux Windows

Table of Contents

Overview

The Solution

Bonus

Summary

Interactive Fuzzy Finding in Vim without Plugins

Table of Contents

Overview

The Setup

Bonus

Caveat

Summary

Search For GIFs Without Leaving Your Terminal

Problem

Solution

Conclusion

Unit Test Your Configuration Files

Table of Contents

Overview

Getting Started

Dockerfile

Kubernetes

Next Steps

Effective Security Programs

Table of Contents

Overview

Culture

Listen to Your Users

Hold Office Hours, Community Meetings, Events

Create a Security Champion Program

Engineering

Invest in Tooling, APIs, Services

Contribute to Engineering

Practice What You Preach

TLDR

Demystifying STRIDE Threat Models

Table of Contents

Introduction

What is a Threat Model?