pajswigger

from burp import IBurpExtender, IHttpListener


class BurpExtender(IBurpExtender, IHttpListener):
    def registerExtenderCallbacks(self, callbacks):
        self.callbacks = callbacks
        callbacks.registerHttpListener(self)

    def processHttpMessage(self, toolFlag, messageIsRequest, message):
        helpers = self.callbacks.getHelpers()

sskylar

<ul>
{% capture tags %}
  {% for tag in site.tags %}
    <li data-sort="{{ site.posts.size | minus: tag[1].size | prepend: '0000' | slice: -4, 4 }}">
       <a href="/{{ site.tag_page_dir }}/{{ tag[0] | slugify: 'pretty' }}">{{ tag[0] }} <span>{{ tag[1].size }}</span></a>
    </li>
  {% endfor %}
{% endcapture %}
{{ tags | split:'</li>' | sort | join:'</li>' }}
</ul>

SansGuidon

Basics

generate key in batch mode using a custom profile

gpg --gen-key --batch gpgspecs

create a file with your fingerprint info and display the related information. A fingerprint is used as a robust key identifier

gpg --fingerprint

Best practices

ageis

⚠️ Content below I now consider obsolete. My latest guide is now located here: Technical guide for using YubiKey series 4 for GPG and SSH. Please consult that resource instead.

---

Quick GPG Smartcard Guide

ruanbekker

$ apk add --no-cache curl
$ echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab

$ cat > /etc/cgconfig.conf <<EOF
mount {
  cpuacct = /cgroup/cpuacct;
  memory = /cgroup/memory;
  devices = /cgroup/devices;
  freezer = /cgroup/freezer;

lbrame

Setting up podman rootless containers on Arch Linux

Podman is a container engine that is similar to and fully compatible with Docker that has the peculiarity of not requiring a daemon to run and to allow for rootless containers, which are often deemed safer than privileged containers running as root. Podman is a drop-in replacement for Docker that even supports the same syntax and it has good support from Red Hat.

However, running podman rootless containers on Arch Linux may not be obvious, so I'm writing the instructions I have used to achieve that here.

Podman works using control groups and users from which said containers need to be launched need to be assigned an appropriate range of subordinate user and group IDs. On Arch Linux, these files are not present and they need to be created.

From a root shell:

i3v

#!/bin/bash

# This script is based on https://unix.stackexchange.com/revisions/480191/9 .
# The following changes proved to be necessary to make it work on CentOS 7:
#  * removed disk info (model, size) - not very useful, might not work in many cases.
#  * using "bw" instead of "bw_bytes" to support fio version 3.1 (those availible through yum @base)
#  * escaping exclamation mark in sed command
#  * the ".fiomark.txt" is not auto-removed 

LOOPS=5 #How many times to run each test

nmaupu

#!/usr/bin/env bash

set -e -x -o pipefail

DIRNAME="$(dirname $0)"

DISK="$1"
: "${DEBIAN_RELEASE:=stretch}"
: "${DEBIAN_VERSION:=9.2.1}"
: "${DEBIAN_MIRROR:=http://ftp.debian.org}"

chakrit

TMUX - Single window group, multiple session.

So I have been using tmux for a while and have grown to like it and have since added many many customizations to it. Now once you start getting the hang of it, you'll naturally want to do more with the tool.

Now tmux has a concept of window-group and session and if you are like me you'll want multiple session that connects to the same window group instead of a new window group every time. Basically I just need different views into the same set of windows that I have already created, I don't want to create a new set of windows every time I fire up my terminal.

This is the default case if you simply use the tmux command as your login shell, effectively creating a new group of windows every time you start tmux.

This is less than ideal because, if you are like me, you fire up one-off terminals all the time and you don't want all those one-off jobs to stay running in the background. Plus sometimes you need information fro

scy

Opening and closing an SSH tunnel in a shell script the smart way

I recently had the following problem:

• From an unattended shell script (called by Jenkins), run a command-line tool that accesses the MySQL database on another host.
• That tool doesn't know that the database is on another host, plus the MySQL port on that host is firewalled and not accessible from other machines.

We didn't want to open the MySQL port to the network, but it's possible to SSH from the Jenkins machine to the MySQL machine. So, basically you would do something like

ssh -L 3306:localhost:3306 remotehost