Why you might want to use a "CLI-only" password manager, and how to do it.

pass, or "the standard unix password manager" as it is described on its website, is an open source, simple, easy to use password manager written in bash that uses GPG and git under the hood. Here we'll take a look at how pass can be used to share secrets within a team, and why it may be preferable to other options.

gpg + git + bash = pass

First I'd like to show the basics of how pass works. This assumes that you have a GPG key, and have pass installed. pass uses a "password store", just a directory (usually ~/.password-store), to store your passwords. To get started you must first initialize your password store:

From here we can generate a password and push it (it will automatically be committed when created):

Then we can print the password, or copy it to the clipboard:

And finally list the existing passwords and created files:

Here we see that pass has created two files:

 .gpg-id - A file that tells pass which gpg keys should be used to encrypt the passwords in this directory (and child directories)

 foo.gpg - The password we just generated, as a gpg encrypted file, encrypted with the gpg keys found in .gpg-id

And that's it! These are just normal files in a local directory, and if we wanted to we could just decrypt our password with gpg --decrypt ~/.password-store/foo.gpg. pass has more features, but these are the basics you'll need to start using it.

Why use pass?

pass is in my opinion a great option for managing passwords and secrets, because it is so simple and transparent. While pass provides a clean command line interface for users to interact with, the fact that the password store itself is a git repo containing GPG encrypted files makes it easy to be used on machines without the pass program itself installed, such as a CI/CD system, using just normal tools most machines already have. Using git under the hood also comes with the benefits developers are already used to, such as version control, branching, and the ability to make pull requests to add changes in a structured way. To add a new team member, they can create a pull request adding their GPG key id to the .gpg-id files where they want access and adding a link to their public key, then anyone who already have access can add them by checking out their branch, importing their GPG key, and pushing a commit after running xargs pass init < .gpg-id.

The fact that pass is so simple and "CLI-first" makes it flexible and easily integratable into other applications, which is a major reason why why I find it so useful for managing secrets in general, not just passwords. These properties are useful for avoiding putting *.env files with decrypted secrets all over your computer, or accidentally leaving some sensitive data in your bash history.

To demonstrate this, I would like to share two use cases where I "daily drive" pass in combination with other tools.

Example 1: Terraform variables

Terraform will often need sensitive input variables, for example API-keys. As the Terraform documentation describes, one way to provide these sensitive variables is through environment variables prefixed with TF_VAR_. To avoid leaving keys in our bash history or in local files which might be accidentally added in git, we can put our environment variables in pass like this:

Then before running any Terraform command, we can simply run eval "$(pass env/terraform-test)" to load our variables into the environment.

Example 2: Ansible vault password

Ansible has a concept called Ansible Vault which is a way of keeping sensitive data used in your ansible scripts encrypted, and decrypting them only when running your scripts. Ansible supports fetching the encryption passwords through custom scripts called clients, and here we'll look at how easy it is to set up an Ansible Vault that fetches the encryption password directly from pass. First we need to create a simple "client":

We can then generate our encryption password and create our vault file:

We can then automatically fetch the password from pass by using the --vault-id your-vault-id@pass-client.sh argument when using for example ansible-playbook or ansible-vault commands in the future.
 To get less verbose commands, you can add vault_identity_list = your-vault-id@pass-client.sh to your ansible.cfg file to avoid having to add the argument each time.

Using pass to share secrets in a team

People tend to see problems in terms of the solutions they themselves can deliver. For designers, this means that when a user problem or need arises we by default frame it as a problem we can solve with design. Say your customers want to save more money but they struggle setting aside money every month. How can we help them? As a digital product designer the answer is clear: this is a usability issue. The feature is too hidden or hard to use, so we need to make it frictionless to set up an automatic transfer to savings.

However, getting a person to do something (i.e. change their behavior) is much more complex than this. There are many factors that influence behavior (like saving money), interplaying with each other in unexpected ways. The COM-B model makes it easier to see this interplay by organizing factors into three major groups: Capability, Opportunity, and Motivation. According to COM-B, all of these needs must be met for a person to perform a certain behavior.

Unfortunately, because we are so focused on the problems our discipline can solve (for designers: creating the physical ability and opportunity) we miss the full picture of what is required for behavioral change. We cover one factor, but forget the rest – often leading to a frustrating lack of results.

So what can we do about it? As designers, we know how much the framing of a problem influences the way that we fix them. The questions we ask during research directly informs how we understand the problem, what issues we find, and what changes we suggest. Therefore it is important to ask questions that give us a full understanding of the barriers that block a user from behaving in a beneficial way. Take time during user interviews to ask about all the major factors from COM-B that can influence your target behavior. Continue to ask questions that reveal usability and communication issues… but also ask if they have social support. Maybe there is a salient emotional response, or a cognitive block like lack of concentration.

While improving information hierarchy or reducing clicks are often helpful measures, they aren’t always going to deliver results when your goal is actually behavioral change. Sometimes the answer is a policy change, or a marketing campaign. Behavioral change is complex and often requires a multidisciplinary approach. On the other hand, we as digital product designers have a unique position – we sit closest to insight on our user’s actual behavior. The key then lies in our ability to understand what is truly blocking the user from our target action, and letting this inform what changes we suggest to our teams and organizations. By taking a behavior-informed approach and using tools like the COM-B in our user interviews, we have a much higher chance of creating value and positive change for our users.

COM-B: Change your user's behavior by asking the right questions.

Vi hadde aldri møtt kvarandre før, og no sat vi her. Det var våren 2021, Trondheim var kald og grå, og koronapandemien var i full sving. Prosjektet var det største vi hadde hatt til no. Og det var heildigitalt.

Bachelorprosjektet til informatikk på NTNU er ei gruppeoppgåve der ein jobbar med ekte problemstillingar og kundar. Vår kunde sat i Austerrike, og eg og fire andre skulle vidareutvikle ein eksisterande web-applikasjon. Gjennom prosjektet fekk eg erfare kor viktig det er å jobbe kontinuerleg, ikkje berre med kode, men med sjølve samarbeidet i gruppa. Resultatet vart det beste gruppearbeidet eg har opplevd i skulesamanheng. Eg vil påstå at tre ting var spesielt viktig for at gruppearbeidet vårt vart vellukka: Daglege evalueringar av eiget samarbeid, små innsjekkar gjennom dagen og digitale rom der vi kunne samlast.





Ein digital møtestad

Vi valde Discord som kommunikasjonskanal for gruppa. Discord er ein plattform litt som Zoom eller Teams, men i motsetnad til dei opprettar ein ikkje møter, men møterom. Der Zoom og Teams er retta mot bedrifter er Discord utvikla for at vennar skal kunne prate medan dei spela i lag.



Den opphavlege grunnen til at vi valde Discord var lydkvalitet og samtaleflyt. Sidan Discord ikkje vart laga for møter med ein tydeleg leiar vart det lettare å halde naturlege samtalar der. Andre tenester vi prøvde hadde ei forseinking frå nokon starta å prate til stemmen deira kom gjennom, noko som gjorde samtalane oppstykka og hakkete. 



Den største fordelen med Discord vart likevel ikkje lyden, men høvet til å lage virtuelle rom. I Discord sine stemmekanalar kunne vi snakke saman med og utan video. Vi kunne også berre «henge» i kanalen, med muta mikrofonar, slik at vi lett kunne få tak i kvarandre ved skru på mikrofonen og snakke.



Vi brukte ulike rom til ulike delar av arbeidsdagen. To grupperom vart nytta til parprogrammering, i eit møterom hadde vi meir formelle møter og innsjekkar. «Loungen» vart eit arbeidsrom og ein sosial møteplass. Rommet AFK dukka også opp etter kvart. Hit gjekk folk om dei var borte frå tastaturet sitt ei stund, til dømes for å lage seg enno ein kopp med te. Dette rommet gjorde det lett å halde oversikt over kven som faktisk var lyttande på ein kanal, og det spara oss for mange småfrustrerte «Hallo, er du her? Vi kan ikkje høyre deg."



På eit tidspunkt oppdaga vi fordelar ved at alle sat saman i Loungen når vi jobba kvar for oss, heller enn å gå i kvar sine rom. Når vi sat saman kunne folk stille opne spørsmål til gruppa om dei trong hjelp, i staden for å måtte oppsøke den dei trudde var best skikka til å svare. Terskelen for å få hjelp vart senka og breidda av teamet vart meir inkludert i kva dei andre jobba med.



Kombinasjonen av å flytte seg mellom rom og å sjå og høyre kvarandre skape ei kjensle av å vere i lag. Det var dagar der eg gløymde at eg enno ikkje hadde møtt dei andre fysisk. Språket vårt avslørte den felles kjensla av rom gjennom kommentarar som «Stikk du innom grupperom 1 og hentar dei andre til innsjekk?»



Innsjekkar. Masse av dei.



Vi kalla det mini-stand-up eller innsjekkar. Dei likna stand-upen vi hadde på starten av kvar arbeidsdag, men var enno meir kortfatta: makslengda var ti minutt. Vi gjekk runden og alle svara på spørsmåla «Kva har du gjort sidan sist?» og «Kva skal du gjere vidare?». Svara vart notert i ein tabell så vi kunne sjå framgangen vår. Tabellen haldt også styr på kor langt vi hadde kome på runden, i tilfelle avsporingar, og sikra at ingen vart gløymd. Mot slutten av innsjekken avtalte vi tidspunkt for neste innsjekk, oftast klokka ti-på-neste-heile-time. Etter kvar innsjekk var det pause – ein utmerka motivator til å halde møtet kort.



Innsjekk kvar time høyrest kanskje litt mykje ut, og i ein fysisk arbeidsdag kan eg vere einig. Det er vanskeleg nok å kome i flyt i opne kontorlandskap om ein også skal verte avbroten i tide og utide. Når alle er digitale er opplevinga mi annleis. Sjølve arbeidet vert gjerne meir fokusert, fordi ein ikkje har fysiske forstyrringar rundt seg. Det sosiale møtepunktet vert eit etterlengta avbrekk, og pausen etterpå ei god påminning om å strekke litt på beina.



At vi jobba i timesbolkar førte til at vi naturleg braut ned oppgåvene våre i mindre delar. No fekk ikkje berre ferdige features merksemd og ros, men også hjelpefunksjonar og delkomponentar. Dette gav meistringskjensle og synleggjorde framgang. Om nokon stod fast på ei oppgåve vart det ofte oppdaga her, og ein kunne få hjelp av andre i gruppa. Vi erfarte også at innsjekkane stilte oss til ansvar for eigen bruk av tid – det var lettare å ikkje forsvinne inn i Facebook når ein snart måtte fortelje gruppa kva ein hadde gjort sidan sist.



Dagleg mini-retrospektiv

Mot slutten av kvar arbeidsdag hadde vi eit kort retrospektiv der vi såg på korleis dagen hadde gått. Vi sette av fem til ti minutt til å noterte ris og ros og kome med forbetringsforslag. Der morgonen sin stand-up fokuserte på arbeid og produkt, vart dette ein stad der vi heller fokuserte på sjølve teamet. Vi bygga ein kultur der vi ikkje låste oss til ei løysing, men heile tida leita etter måtar å gjere ting betre på.



Forbetringsforslaga vart henta opp att på starten av neste arbeidsdag. Nye idear kunne prøvast ut, justerast eller forkastast. Vi trengte ikkje bruke ein heil sprint sitjande fast i prosessar som ikkje passa oss. Slik kom vi fram til korleis vi kunne gjere innsjekkar effektivt, korleis vi best kunne bruke Discord, og vi kunne stikke hol på gryande irritasjonar før dei vaks til konfliktar. Eg trur opplevinga av prosjektet ville vorte ei heilt anna om vi ikkje hadde teke oss tid til å heile tida evaluere oss sjølve.



Ei slags avrunding

Alle team er ulike. Vi var eit lite team av uerfarne utviklarar på heimekontor. Eg trur desse løysingane fungerte så godt i gruppa vår fordi vi forma dei sjølv. Ingen tvinga oss å ha innsjekkar kvar time, det var vår greie, ei erfaring som knyta oss saman. Frå start av brukte vi mykje tid på byggje ein gruppekultur gjennom å prate og verte kjend. Den uformelle forma til Discord gjorde dette lettare, saman med dei mange møtepunkta vår gjennom dagen.



Sidan vi var uerfarne tok vi heile tida høgd for at folk kom til å trenge hjelp. Vi jobba med å fange det opp tidlegast mogleg, så folk ikkje stod fast på ei oppgåve og mista motivasjonen til å fortsetje. I rundane våre på stand-up og innsjekk sikra vi at alle vart sett og høyrd fleire gonger dagleg. Dette er alltid viktig når ein jobbar i team, men kanskje enno meir når samfunnet er stengd ned.



Gjennom å heile tida jobbe med å forbetre prosessen vår unngjekk vi å setje oss fast i ein tankegang om at "Heimekontor kjipt, men det er berre sånn det er. Det går sikkert snart over." Vi fann heller ein måte å utforske fordelane med heimekontor, som til dømes at det var lett å veksle mellom å jobbe i fred og å vere sosial. Sjølv om dette ikkje var det mest spennande semesteret i studietida mi ville eg absolutt ikkje vore forutan erfaringane frå dette prosjektet.



Når vi no er på veg inn att i ein periode med meir bruk av heimekontor vil eg kome med ei oppfordring: test ut Discord (det skalerer bra). Bruk litt ekstra tid i teamet på å jobbe med samarbeidet. Våg å prøve ut nye ting, det er slik ein snublar over dei beste idéane. Det er berre teamet sjølv som veit korleis dei jobbar best i lag, så gje dykk sjølv rom til å finne det ut.

Då gruppearbeidet vart digitalt

ASP.NET Core is not supported on Heroku. Read how I didn't care about that and made it work anyways (and all the hoops involved).

Recently, I started a hobby project that I for once was determined to finish. And that within a strict timeline too: NamR, an app to register baby names and compare them with your significant other’s. (Disclaimer: it's a Norwegian app designed by a developer for personal use. You have been warned).

As a .NET developer, and a notorious non finisher of hobby projects, I wanted a simple, clean and, most importantly, free way of running my app. Almost everyone I know that don’t see themselves as a .NET developer recommends Heroku for these very reasons, so I though I'd give it a try.

However, .NET is not supported on Heroku 😢. Though there is a way to do it anyway: Containers 🐋

With various assurances that a containerized .NET app will indeed run on Heroku, I decided to try it out. But as you might have guessed, completing this task wasn't as straightforward as those assurances assured. And that's why I'm writing this blog post.

The quirks of running .NET in a container on Heroku

NamR’s architecture is as simple as:

A .NET 5 Web Application with a Blazor Web Assembly front-end running on a free Dyno.

A Postgres database using the Heroku Postgres add-on.

Since this blog post is all about how I got the app running, I will not go into more details about the app itself, nor how to set things up in Heroku (they have plenty of documentation for that purpose).

The rest of this post will refer to (and show) examples from NamR's code. Feel free to have a look.

Before deploying I wanted to have a functioning application that talked to the database running locally. After that, I went ahead and created my Dockerfile and pushed the image to Heroku so that I could start working through the hoops necessary to make it run.

The port problem

The first quirk is how Heroku dynos handle ports when running containers. Normally when you run a container you specify port mappings and such in the Dockerfile. In Heroku, your container needs to support being assigned a random port through the $PORT variable. For a .NET app, that means you need this in your Dockerfile:

But wait, there’s more! You also have to configure Kestrel, .NET’s default web server, to listen on this port:

With that out of the way, you should be able to reach your app on Heroku so that you can behold the error message it displays in all its glory. But hey! At least this proves that you have configured the port correctly. Because the error message is coming from the application itself, and its telling you that it cannot access the database.

Next problem: connecting to the Heroku Postgres database.

Heroku provides connection details for the database as an URL via an environment variable: DATABASE_URL. But EF Core will not eat connection details in any other format than a connection string like this one (more properties exist):

To fix that, you need to tweak your Startup to handle translating the DATABASE_URL to a connection string:

Migrate the database

Another issue is how to handle migrations. Personally, I prefer to run migrations locally using a command line tool like dotnet ef, and in various environments this should be done during deployment. However, in this case I decided to just run migrations during application startup:

What about HTTPS?

You may now visit your app. Open a browser and type in "yourappname.herokuapp.com" and witness the beautiful 404 you're greeted with. That’s right. There’s one more thing: HTTPS redirect.

This is usually something you get out of the box with the code provided in a .NET Web App template, but in a container on Heroku you need to handle this a little different (this may also apply behind other forms of reverse proxies):

Why you ask? You shall find the answer in Heroku’s documentation:

Under the hood, Heroku router (over)writes the X-Forwarded-Proto and the X-Forwarded-Port request headers. The app must check X-Forwarded-Proto and respond with a redirect response when it is not https but http.

That is what the code above does. And then finally, we redirect to https using a 307 status for internal redirects 🔐.

And that’s it! You should now be able to focus on developing (or procrastinating) your awesome hobby project. Best of luck!

Running an ASP.NET Web Application on Heroku

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

10-Dec

Today's posts

Using pass to share secrets in a team

COM-B: Change your user's behavior by asking the right questions.

Då gruppearbeidet vart digitalt

Running an ASP.NET Web Application on Heroku

Brannfakkel - 5 korte om PHP, Trackpad, Sikkerhet, Bestillinger, SPA vs. BFF (Del 4 av 6)