Passphrases are considered easier to remember for humans and harder to crack for machines, famously explained in this comic:

The challenge then is to have a good word list to pick from. There are various measurements on how many words one person would use which could be as low as a thousand. Note there is a huge difference between recognize and use.

Passphrases and dices

In a recent Toot exchange ospalh pointed me to Diceware, a method to use dice rolls and a word list to determine a passphrase. Usually one uses the regular 6 sides dices and 5 dices, which lets you pick from a 7776 member word list. The EFF published a version using the 20-sided dice from Dungeon and Dragons as well as various word lists.

Wordlists

An attacker who doesn't know that they are dealing with a passphrase, using conventional cracking methods stands little chance to decipher the phrase. However as the defender you must assume, they know your word list, so it is imperative to keep it long, while maintaining the odds to remember (in any case you can use some extra brain). SOme of the word lists you can find online:

• Arnold Reinhold's Diceware list, 1995, 7776 entries
• EFF list from 2016, 2016, 7776 entries (introduced here)
• Fandom generated word lists by EFF for the 20 side dice
• Game of Thrones, 2018, 4000 entries
• Harry Potter, 2018, 4000 entries
• Star Track, 2018, 4000 entries
• Star Wars, 2018, 4000 entries

Math.random() to replace dices

Let's roll (pun intended) our own passphrase generator. To make it a little more fun these are our constrains:

• passphrase has 5 elements: 4 words and one 6 digit number
• the number appears at a random position
• elements are separated by a - (for readability, in active use you might just filter them out)

SO you drank the cool-aid, like me, and use GitHub Actions to build your projects and GitHub pacckages for your private containers, maven produced Jars, npm modules. Soon your honeymoon is over and you hit the storage limit of your account.

You need to clean up

Looking at the packages you will notice, that they are all there, all the version, in case of containers even the untagged ones. The root of the problem is equally the solution: a GitHub Action to delete package versions. The package is very flexible and well documented, outlining several scenarios how to put it to use

Things to watch out for

You have to decide when you want to put it to use:

• on schedule, like every Friday
• manual, pressing a button
• on each build, when you add a new package

I also experienced that {{ secrets.GITHUB_TOKEN }} wouldn't work when the package you target is private, even when it is in the same repository. Once you know, it's not a big deal, just create a PAT and add it to the repository's secrets. You might want to add workflow_dispatch to all triggers, so you can test run them anytime.

GitHub Actions are rapidly becoming my favorite CI environment. Their marketplace has an action for everything. Sometimes it takes a little trial and error before things work smoothly. This is one of that stories.

Authentication is everything

Imagine the following scenario: you have developed a set of private TypeScript (or JavaScript) packages and have successfully deployed them to the private GitHub npm registry under the name @myfamousorg/coolpackage - where myfamousorg must match the repository owner (org or individual).

Now you want to use them in your application. That application shall be packed in a Container and made available in GitHub's private registry. All that automated using GitHub Actions.

You will need a PAT (or two)

In GitHub, head to the Personal access tokens / Tokens (classic) section of your developer settings in profile. You need to create tokens that allow you to handle packages.

There are two places where you want to enter that token:

• In https://github.com/[your-org]/[your-repo]/settings/secrets/actions create a key GIT_NPM_PACKAGES and copy your PAT there. You can pick any name, you will need it in the GitHub action later
• In ~/.npmrc, your global settings for npm in your home directory. Don't put the info in the .npmrc in your git project.

prefix=/home/[your username]/.npm-packages
@myfamousorg:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=[here goes the token]

The prefix property allows you to run `npm install -g [package] without admin access.

Objects I need a lot of objects. When dealing with APIs there is one fundamental question to answer: how much data do you want to retrieve?

The old school answer: let's page results, 25 at a time. Then infinite scrolling came along and changed expectations.

I got some chunk for you

One way to operate is for the server to send all data, but using Transfer-Encoding: chunked (RFC 9112) in the header and deliver data in several packages, aptly named chunks. A client can process each chunk on arrival to allow interactivity before data transmission concludes.

However this requires adjustments on both sides. The server needs to send data with a clear delimiter, e.g. \n (newline) and the client needs to process the data as a stream

The usual way won't work

We typically find code like this:

fetch(url)
  .then((resp) => resp.json())
  .then((json) => {
    for (let row in json) {
      addRow(json[row], parentElement);
    }
  });

fetch hides a lot of complexity, we need to handle when we process a chunked result as it arrives.