joedoe47 5dbcde997f
git-annex in joedoe47@pc-stick:~/bin/gpass
2 months ago git-annex in joedoe47@pc-stick:~/bin/gpass 2 months ago
TODO git-annex in joedoe47@greatfox-lylat2:/media/sdi1/documents/public/gpass 3 months ago
changelog git-annex in joedoe47@pc-stick:~/bin/gpass 2 months ago
gpass git-annex in joedoe47@pc-stick:/media/sda1/documents/public/gpass 2 months ago



This isn't a fork of the pass app. I just got an idea to use/make something similar to pass thats easier and a bit more flexible for me to use.

it is a wrapper for gpg and uses "gpg -c" to quickly encrypt data and it defaults to AES256 and uses sha512 to verify the file. It can also use GPG keys if you want.

You will want to try this if:

  • you want a good and simple password manager

  • you want to just use "a password" to encrypt data and have it make a basic attempt at file integrity

  • you change passwords often

  • you want to generate random passwords, passphrases from word lists, or even hash based passwords

  • you want to have more control of your passwords or data and they are secured

  • you want to leak less metadata about your passwords compared to pass

  • you plan to use this on multiple linux, unix or linux/unix-like systems (tested mostly on termux, fedora, and debian but I focused on using coreutils and gpg)

Pass already exists but this is something I thought would be cool to make anyways.

This leaks less metadata because its a script that uses GPG to store multiple passwords into a file in CSV format. Where as pass will store 1 password per file and you organize these passwords using folders. Thus allowing an adversary to know that you have an account on a specific site, eg. 'facebook'. However with gpass I could have a file called "social-media.gpg" and I may or may not have my facebook accounts there.

Please do not misunderstand, pass isn't insecure or flawed in anyway; both pass and gpass, at worst case scenario an attacker knows how big an encrypted file is, what might be inside based on the name, and when it changed but not necessarily what changed. Both also use GPG.

I made gpass to lessen the amount of data an adversary can get from the name of a file (via security through obscurity), the ability to use a password or a GPG ID, and 2 other forms of password generation.

These programs are even better if you store your data on a LUKS storage device and practice good operational security to share/sync these passwords. (About LUKS).

The main difference with gpass is that with gpass, you have 1 file with multiple passwords. An adversary would have a harder time figuring out what passwords are in file "X.gpg", should they somehow grab a hold of your LUKS drive or see your git server.

Also by allowing gpass to switch between symmetric and asymmetric encryption, I can choose to have some password protected via gpg public key and others via a long passphrase.

Naturally the larger a password file the slower sed is to find/add/delete data but you would probably need around a 900,000 passwords on a raspberry pi 3 to really notice slow downs but performance will vary depending on your hardware and what its doing.

This can be as secure or as relaxed as you want it, depending on how you use it!

How to try/install


To try:

$ bash /path/to/gpass [arguments]

if you want something more permanent you can just use an alias:

$ cd gpass && echo "alias gpass=\"$(pwd)/gpass\"" >> "$HOME/.bashrc"

every so often just do "git pull" in this directory every so often to make sure it stays up to date.


There are some configuration options that can be set via evnironment variables to tweak how gpass operates. you can add these variables to your .bashrc or .profile to properly make gpass work to your liking.

  • I want to use GPG Keys/ID to encrypt data

    - $ export ENCRYPTION="symmetric" (and you can just use a regular password rather than your PGP key)
  • I want to use another encryption algorithm

    - $ export ALGORITHM="twofish" (or whichever algorithm you fancy; camilla256 is another)
  • If you think /dev/random is better.

    - $ export ENTROPY_SOURCE="/dev/random"

Backwards compatibility

I have tested gpass in a few environments. Debian, Fedora, Archlinux, Termux (no proot). Because these are the linux and linux-like environments I use the most. So rest assured it will work on linux mint, windows new ubuntu bash, and any operating system so long as it has gpg, bash, and coreutils.

Since the program uses a simple CSV standard and uses gpg, you can switch to any alternate method of managing your passwords if you think this program isn't for you.

Suggested Security Practices

  • Only use machines you trust. I would not suggest you open a password file in an environment you do not trust or is capable of snooping on you or your data.

  • Change symmetric password for file "X" often (depending on how sensitive the data is you may even want to change the password based on a schedule)

  • If a site or program allows for long passwords, you should probably use a passphrase with a modifier or a hash password (some sites require 8-16 character passphrases)

    • a modifier would be like the spaces between the words in a passphrase AND a counter of sorts, a pin code, a color, or something that changes but only you know in your head. This helps to add additional entropy to the passphrase or hash based password.

    • Passphrase "Narcotic Truck Penpal Upriver Abe Drunken"

    • Password based on a counter with slashes instead of spaces "Narcotic/Truck/Penpal/Upriver/Abe/Drunken | 2" '

    • Password based on a pin with period instead of spaces "Narcotic.Truck.Penpal.Upriver.Abe.Drunken | 3283"

    • Password based on a color with 'z' instead of spaces (its a shade of grey in hex but a color in any format should do. English, hex, rgb, etc.) "3NarcoticzTruckzPenpalzUpriverzAbezDrunken0 | cecece"

  • Use LUKS drives to store your data (security is best when layered; keep a back up of the passphrase for this somewhere safe too or don't)

    • if you are on IOS or Android use full disk encryption but note that phones are RARELY secure environments to be working on.
  • Try to use NTFS or FAT to store files (journaled file systems can have files restored if its done in a reasonably short time of deletion; and thankfully you can have LUKS+NTFS/vfat)

  • Don't blindly trust the built in sha512 checking (an adversary will probably mess with these files indirectly, so its best to keep a back up and check them manually; even if you use public key/asymmetric encryption)

  • I recommend you use syncthing, git annex, git, unison, rsync or old school sneakernet to sync files

    • this will allow you to keep at least 2 duplicates of hashes to ensure data integrity and away from centralized points of failure (if a password gets leaked its because of the site/program or you; no one else)