This repository allows to handle and share securely sensitive data by wisely using GNU Privacy Guard (GPG). It consists of a simple directory structure and a shell script named
secshare, which is a simple GPG wrapper.
Your team established a chain of trust:
All members should have signed each other's public keys. If you don't know what this means, you should read some good manual on how to do it: I would personally suggest this guide.
Your hard drive is encrypted:
The helper scripts of this repository will store sensitive information as plaintext on your hard drive. This is secure only if your disk is encrypted.
No revocation of granted access:
The script knows nothing about your data, and if someone leaves the team you probably want to consider all shared secret as compromised.
No fine-grained selection of access: all team has got access to all
Your sensitive data is stored in the
datadirectory. Note that the
datadirectory is added to the
.gitignorefile and must never be commited.
Files and top-level directories under
dataare treated as distinct sensitive items, so you can group together in the same top-level directory any tree of related data.
secsharescript encrypts each sensitive item as ascii-armored gpg-encrypted tarball. Each encrypted file is stored in the
A file named
keyswill list the users which are allowed to access data. This setting is honored by the
secsharescript during the encryption phase.
keysfile is signed by one member of the team. This ensures the
keysfile to contain only authorized keys, hence avoiding an attacker to put her key among the recipients of encryption. This step is handled by
secshare, and generates a detached signature file named
Since encrypted files cannot be read, an index file documenting the content of each of them is recommended, along with descriptive file names.
You share everything by pushing
keys.ascand the index file (if any)
secsharescript is a simple helper program written in Bourne Shell (sh). The following commands are supported:
Initialize the repository unless it wasn't already initialized. This simply creates the filesystem structure and initializes the
Encrypt each sensitive item (file or directory) in the
datadirectory. Put the resulting encrypted files in the
Recipients are obtained by reading the
keysfile (see the Keys file format section for details). The
./secshare closecommand will fail unless the
keysfile can be verified against a detached signature
keys.asc, and the signature was made by a trusted user.
(A trusted user is someone whose key was signed by you or another user you trust. Again, RTFM!).
keysfile with a detached signature. This is a required step in order for you and other team members to
./secshare closesuccessfully. One should never sign blindly the
Open one or more files contained in
Files cannot be opened unless they were encrypted with the user's public key (via
A pattern can be specified to ask for one or more files to be decrypted. If not specified, the script will try to decrypt all encrypted files.
pub:prefix should identify a public key.
What follows the
pub:prefix will be cut of white-space characters and used as parameter for
--recipientin GPG. In other words the short id of the key or an email address will work fine, but the full key fingerprint is recommended.
pub:lines, this file can contain arbitrary text, which will be ignored by the
secsharescript. This "feature" can be used to put useful comments, as the name of the key owner.
If no key is provided in the keys file GPG will not be provided with
--recipientdirectives, and you will be interactively asked to provide a recipient.