Jamievan Dyke, Author at Stark & Wayne https://www.starkandwayne.com/blog/author/jamievandyke/ Cloud-Native Consultants Thu, 30 Sep 2021 15:49:18 +0000 en-US hourly 1 https://wordpress.org/?v=6.0.3 https://www.starkandwayne.com/wp-content/uploads/2021/04/cropped-SW_Logos__shield_blue_on_transparent_with_border-32x32.png Jamievan Dyke, Author at Stark & Wayne https://www.starkandwayne.com/blog/author/jamievandyke/ 32 32 Automate Vagrant Suspend on Logout or Shutdown https://www.starkandwayne.com/blog/hah-hah-hah-hah-stayin-alive-bosh-lite/ Tue, 12 Jul 2016 20:46:00 +0000 https://www.starkandwayne.com//hah-hah-hah-hah-stayin-alive-bosh-lite/

So you have your local BOSH-Lite, and you have your Cloud Foundry release on there, your Etcd, PostgreSQL, MySQL, Redis. You name it; it's on there.

Then you go and install the latest MacOS update and "Oh Gods, no!", You forgot to suspend that Vagrant instance, and you might be looking at an aborted state that means rebuilding it all. Not fun.

Apple has recommended not using login and logout scripts for some years now. Instead, you should be using Launchd scripts to manage your background applications and services. I decided it was time to look into how I'd automatically suspend Vagrant instances on shutdown.

The short version: Use Launchd to run a BASH script that waits until it is told to shut down, which runs a logout script.

The Launchd script, place this in $HOME/Library/LaunchAgents/org.$USER.logOut.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
    <key>Label</key>
    <string>onLogout</string>
    <key>Program</key>
    <string>PATH_TO_THE_SCRIPT_BELOW</string>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Now we need to create the script that does the work. I created this in my ~/scripts/onLogout.sh folder, but place it wherever suits you and change the path in the plist file above.

#!/bin/bash
onLogout() {
    # Suspend vagrant
    osascript -e 'display notification "Suspending Vagrant containers" with title "Please hold..."'
    /usr/local/bin/VBoxManage list runningvms | /usr/bin/sed -E 's/.*\{(.*)\}/\1/' | xargs -L1 -I {} /usr/local/bin/VBoxManage controlvm {} savestate >> /var/log/org.YOUR_NAME.log 2>&1
    exit
}
echo "INFO - Watching ${HOME}" >> /var/log/org.YOUR_NAME.log
trap 'onLogout' SIGINT SIGHUP SIGTERM
while true; do
    sleep 86400 &
    wait $!
done

Change YOUR_NAME to be your username, and any paths you would like to be different. Also, be sure to create the log file and make the script executable with the following:

sudo touch /var/log/org.$USER.log
sudo chown $USER /var/log/org.$USER.log
chmod +x $HOME/scripts/onLogout.sh

Now we have our Launchd launch script and the script that will run when we log out. We need to load the Launchd script so it runs on startup.

launchd load -w $HOME/Library/LaunchAgents/org.$USER.logOut.plist

There we have it. You can test it works without logging out by just running the script from your shell. You can use this script for anything else you'd like to do on logout or shutdown. Enjoy! Hah, hah, hah, hah. Stayin' alive!

Credit to Pepijn Bruienne, who had some scripts that helped me along the way.

The post Automate Vagrant Suspend on Logout or Shutdown appeared first on Stark & Wayne.

]]>

So you have your local BOSH-Lite, and you have your Cloud Foundry release on there, your Etcd, PostgreSQL, MySQL, Redis. You name it; it's on there.

Then you go and install the latest MacOS update and "Oh Gods, no!", You forgot to suspend that Vagrant instance, and you might be looking at an aborted state that means rebuilding it all. Not fun.

Apple has recommended not using login and logout scripts for some years now. Instead, you should be using Launchd scripts to manage your background applications and services. I decided it was time to look into how I'd automatically suspend Vagrant instances on shutdown.

The short version: Use Launchd to run a BASH script that waits until it is told to shut down, which runs a logout script.

The Launchd script, place this in $HOME/Library/LaunchAgents/org.$USER.logOut.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
    <key>Label</key>
    <string>onLogout</string>
    <key>Program</key>
    <string>PATH_TO_THE_SCRIPT_BELOW</string>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Now we need to create the script that does the work. I created this in my ~/scripts/onLogout.sh folder, but place it wherever suits you and change the path in the plist file above.

#!/bin/bash
onLogout() {
    # Suspend vagrant
    osascript -e 'display notification "Suspending Vagrant containers" with title "Please hold..."'
    /usr/local/bin/VBoxManage list runningvms | /usr/bin/sed -E 's/.*\{(.*)\}/\1/' | xargs -L1 -I {} /usr/local/bin/VBoxManage controlvm {} savestate >> /var/log/org.YOUR_NAME.log 2>&1
    exit
}
echo "INFO - Watching ${HOME}" >> /var/log/org.YOUR_NAME.log
trap 'onLogout' SIGINT SIGHUP SIGTERM
while true; do
    sleep 86400 &
    wait $!
done

Change YOUR_NAME to be your username, and any paths you would like to be different. Also, be sure to create the log file and make the script executable with the following:

sudo touch /var/log/org.$USER.log
sudo chown $USER /var/log/org.$USER.log
chmod +x $HOME/scripts/onLogout.sh

Now we have our Launchd launch script and the script that will run when we log out. We need to load the Launchd script so it runs on startup.

launchd load -w $HOME/Library/LaunchAgents/org.$USER.logOut.plist

There we have it. You can test it works without logging out by just running the script from your shell. You can use this script for anything else you'd like to do on logout or shutdown. Enjoy! Hah, hah, hah, hah. Stayin' alive!

Credit to Pepijn Bruienne, who had some scripts that helped me along the way.

The post Automate Vagrant Suspend on Logout or Shutdown appeared first on Stark & Wayne.

]]>
iTerm and Tmux, sitting in a tree. https://www.starkandwayne.com/blog/iterm-and-tmux-sitting-in-a-tree/ Thu, 08 Oct 2015 00:05:43 +0000 https://www.starkandwayne.com//iterm-and-tmux-sitting-in-a-tree/

A lesser known trick of iTerm 2 is that it has some pretty swish tmux integration. For most of us, we know that terminal multiplexers like tmux and screen solve a lot of problems like:

  • Restoring terminal sessions that have died due to:
    • Network issues
    • Putting your laptop to sleep in the middle of a long running command
    • iTerm crashing, although rare, it happened to me once
  • Sharing a terminal with another remote user
  • Splitting the screen to see 2 things at once

One of the annoying things about terminal multiplexers is that scrolling to previous history isn't as simple as a quick trackpad flick.

Behold, the magic:

# Start a new tmux session
$ tmux -CC
# Resume a previous tmux sessions
$ tmux -CC attach

The magic, is the -CC. iTerm will start a new tmux session and your terminal will now look like this:

** tmux mode started **
Command Menu
----------------------------
esc    Detach cleanly.
  X    Force-quit tmux mode.
  L    Toggle logging.
  C    Run tmux command.

If this was a new session you'd have a new window pop up that is a tmux session. The window acts like you'd expect. Opening a new tab in fact opens a new tmux window. You can also split panes, resize windows and panes and many other things.

If you tmux -CC attach, it opens up your previous window exactly as it was before.

It's lovely, yummy and brilliant. Enjoy!

The post iTerm and Tmux, sitting in a tree. appeared first on Stark & Wayne.

]]>

A lesser known trick of iTerm 2 is that it has some pretty swish tmux integration. For most of us, we know that terminal multiplexers like tmux and screen solve a lot of problems like:

  • Restoring terminal sessions that have died due to:
    • Network issues
    • Putting your laptop to sleep in the middle of a long running command
    • iTerm crashing, although rare, it happened to me once
  • Sharing a terminal with another remote user
  • Splitting the screen to see 2 things at once

One of the annoying things about terminal multiplexers is that scrolling to previous history isn't as simple as a quick trackpad flick.

Behold, the magic:

# Start a new tmux session
$ tmux -CC
# Resume a previous tmux sessions
$ tmux -CC attach

The magic, is the -CC. iTerm will start a new tmux session and your terminal will now look like this:

** tmux mode started **
Command Menu
----------------------------
esc    Detach cleanly.
  X    Force-quit tmux mode.
  L    Toggle logging.
  C    Run tmux command.

If this was a new session you'd have a new window pop up that is a tmux session. The window acts like you'd expect. Opening a new tab in fact opens a new tmux window. You can also split panes, resize windows and panes and many other things.

If you tmux -CC attach, it opens up your previous window exactly as it was before.

It's lovely, yummy and brilliant. Enjoy!

The post iTerm and Tmux, sitting in a tree. appeared first on Stark & Wayne.

]]>
Encryption is getting easier https://www.starkandwayne.com/blog/encryption-is-getting-easier/ Tue, 28 Jul 2015 21:37:00 +0000 https://www.starkandwayne.com//?p=2597

Reasons

There are many reasons why encrypting your email is a good idea, but as developers we have a responsibility to for our clients. Maybe you're sending credentials for a service, maybe the client would like to discuss sensitive company information, maybe you're about to find out your Secret Santa!

We've been encouraged in the corporate and enterprise environment to go with paid-for services that can provide end-to-end solutions to our problems. These come with the worrying fact that governments can demand they hand over the keys and all of that sensitive information is no longer a secret.

Encrypting your information with the open source GPG tools is simple enough, but verifying an identity (like a github account, twitter account or maybe even a domain) was a little harder. I'd like to show you a simple way to do encryption and verification that leaves the keys in your hands.

The pieces

Here's a quick overview of how this works.

Encryption requires you to have 2 keys, a private one and a public one, we call this a keypair. You keep the private one to yourself and you give the public one to others. When you encrypt a message you encrypt it with your private key and the recipient's public key. The only person that can unlock that encryption is whomever holds the private key that matches the public key you encrypted against.

For example, if I wanted to send Dr Nic an email containing my bank details (so he can give me wads of cash) I would take my private key and his public key and encrypt it. Because he holds the private key that matches the public key I used, only he can unlock it.

For verification of an identity you can use Keybase. My twitter account is (as you know) @fearoffish, if you search Keybase for that twitter account then you'd find that I have verified that account belongs to me and my public key is there for you to use.

Snapshot of my Keybase account

You'll also notice there are links to other services I've verified are mine like my github account, my domain name and more.

TL;DR

If you are on a Mac you can use the GPG Suite along with Mail.app and it's easy. If you use any another client it becomes more painful but still achievable.
If you are on iOS then you can use iPGMail and sending messages is painless, but receiving is still a little copy and paste dance.
If you want to verify users and then get hold of their public keys, there are services like Keybase that are starting to make that painless.

What do I need

There are many tools you could use but these are the tools that I use.

The GPG Suite:

The workhorse of our workflow, this does the encrypting, decrypting, signing and verifying of all the things. It comes with a complete commandline toolset to use as well as GUI tools that accompany them.

Keybase:

A directory of identities that will prove the person you're communicating with is who you think. For example, when I want to send Dr Nic an encrypted email with my bank account details, I can use Keybase to look him up because I know his Github account is drnic.

iPGMail:

This is the iOS application I use, it's inexpensive and simple to use. On Android you could use K9 with Android Privacy Guard (APG) to achieve the same.

Setup

On your Mac:

  • Install GPG Suite
  • Install Keybase
  • Sign up to Keybase (Invite only currently, see below)

The GPG Suite provides the majority of tools you'll be using here. There are many extensive tutorials available around the Internet for this, so I'll give the short summary and a handy tip below.

Install the Keybase client using either Homebrew or their own NPM installer:

$ # Using Homebrew
$ brew install keybase
$ # Using their NPM installer
$ npm install -g keybase-installer

Once you have the tools it's time to join Keybase, at the moment it's invite only. I'd recommend you either join the queue by signing up, or search Keybase for someone you know and it will show if they have any invites to pester them for. You can join Keybase from the cli as well as the site:

$ keybase join

Once you're registered you should go to the Keybase website, sign in and follow the instructions to verify your online identities like your Twitter and Github account.

On iOS:

  • Install iPGMail, Apple's Mail client currently does not support encryption on iOS
  • Export your private key on your Mac, you can do this from the Keybase site or from the cli gpg --export-secret-key -a "User Name" > private.asc
  • Import that private key into iPGMail using Airdrop or Dropbox. Instructions

Now you have the tools and keys in place, let's talk about how to use them.

Encrypting, decrypting, signing, verifying

On a Mac:

The good news here, is that the GPG Suite handles this all for you if you use Apple Mail. GPGMail (it gets installed as part of the suite) integrates directly into Apple Mail when you're reading it will decrypt and verify signatures, and when you're composing it will encrypt and sign. Let's have a quick look.

When I want to send Dr Nic an encrypted or signed message I'll need his public key, I can find that with Keybase (using their site or the cli) as well as verify it is the right Dr Nic.

$ keybase search drnic
-    drnic   579b1c809edbcbed8b869bdc0b92a265a0921641    github:drnic    twitter:drnic   dns//drnicwilliams.com  dns//starkandwayne.com
-    nickloose   19bbdcac4565f2f3fb06157f23caa66394fdff67    github:nickloose    twitter:nickloose   http://nickloose.de http://hellodrnick.com

Keybase has found 2 matches for this search, we want the first. We see his Keybase username (the first word after the dash) is drnic so let's keep track of him:

$keybase track drnic
info: ...checking identity proofs
✔ public key fingerprint: 579B 1C80 9EDB CBED 8B86 9BDC 0B92 A265 A092 1641
✔ "drnic" on twitter: https://twitter.com/drnic/status/621374157616480256
✔ "drnic" on github: https://gist.github.com/df629668a531b193985a
✔ admin of the DNS zone for starkandwayne.com
✔ admin of the DNS zone for drnicwilliams.com
Is this the drnic you wanted? [y/N] y
Permanently track this user, and write proof to server? [Y/n]

You need a passphrase to unlock the secret key for
user: "Jamie Van Dyke <jamie@fearoffish.com>"
2048-bit RSA key, ID 48872E720641FE38, created 2013-07-30
         (subkey on main key ID 84C040D506DF5149)

info: ✔ Wrote tracking info to remote keybase.io server
info: Success!

So Keybase has looked up the user drnic and presented me with all of the details that he has verified. I can see he has verified his Twitter account, Github account and 2 domains that he owns. It also shows me how he verified that with the Tweet and Gist. I accept that this is indeed the Dr Nic that I want to track, and I chose to permanently track him.

But what is tracking? If I'm using the Keybase commandline tool, every time I want to interact with his public key (that is every time I want to encrypt, decrypt, sign or verify something with him) I will need to verify that he is who I think. That can get tedious very quickly; Tracking removes that need. An added benefit is that tracking him adds his public key to our local GPG Keychain (when you use the commandline tool), so his public key is available to GPG Mail when we want to email him.

Dealing out the secrets

On a Mac

Let's have a look at how we'd email an encrypted message. Open up Mail.app and compose a new message, you should see some new options available to you:

Compose message with Open PGP options

Notice the lock symbol and the tick. These are the encryption and signing options. The blue tick shows me I'm signing this message, the grey lock shows me that encryption is not available. It won't be, not until I give it a recipient who I have the public key for. There are some caveats to the process here, I'll talk about them at the end of this post.

I tracked Dr Nic earlier, so I should be able to encrypt a message to him. In Mail.app it looks like this:

Example Mail.app screen when encrypting

I've used his keybase.io account for this, as that's the only email that is stored in his public key (for now). I'm going to run him through adding his other email addresses to his public key later, you can skip to the bottom of this short post to see how you can.

So the steps to send an encrypted and signed email in Mail.app go like this:

  • Compose an email, ensure the from and to addresses both exist in your GPG Keychain
  • Click the lock and tick sign so they are both blue
  • Write the email, bearing in mind that only the body is encrypted.
  • Send

My GPGMail preferences look like this:

My GPG Mail Preferences

Receiving encrypted emails in Mail.app is simple, you just receive them and they get decrypted on the fly:

Decrypted message in Mail.app

On iOS

  • Open iPGMail and click Compose in the bottom tabs
  • Add the public key for the person you're emailing, if it's not in the list you can add keys from the Keys tab
  • Add your private key as the from address
  • Write your subject and body
  • Click the Share symbol: Share symbol on iOS. If you setup your SMTP mail server you can send it from here, otherwise Copy to Clipboard and paste it into your preferred mail client.

Until email clients build encryption into their apps, this is the painful part. I prefer to send encrypted emails from iPGMail on the go because it's much easier. Decrypting requires a little effort too, but it's all in the name of secrecy!

Receiving in Mail is easier when the encrypted message is attached instead of embedded. Attached messages are basically just copied over to iPGMail which decrypts them and checks the signatures. Here's a series of screenshots to demonstrate:

A received encrypted message in iOS Mail

Click on the attachment, and you're presented with the plain text version. Click on the text and the sharing icon appears at the top right:

The share icon for the encrypted attachment

Click the share icon bring sup your list of options for sharing. We'd use the "Copy to iPGMail" option:

The "Copy to iPGMail" sharing option

If the message were embedded we would have to copy all of the text to the clipboard, and then open iPGMail which would ask if you'd like to decrypt the clipboard contents.

Adding email addresses to your private key

There are command line options to achieve this, but using the GPG Keychain is so simple you might as well use that.

  • Open GPG Keychain and double click your private key
  • Select User ID's and then the little plus icon under the list,enter your full name and the email address but leave the comment blank.
  • Click the Generate User ID button
  • Now in the menu, select Key -> Send public key to key server which shares your key with one of many open directories.
  • For Keybase you need to use keybase push --update. Anyone adding your key to their keychain will be able to use all of those new email addresses. If they are already tracking you on keybase they will need to untrack and track to get that change.

Conclusion

Encryption is still painful, however finding and verifying the people you need to interact with has become easier thanks to Keybase. If you need to send encrypted messages there is no workaround until messaging client's get onboard. Open source encryption is the future as it isn't open to a government demanding the keys be handed over and masses of people losing their privacy.

The post Encryption is getting easier appeared first on Stark & Wayne.

]]>

Reasons

There are many reasons why encrypting your email is a good idea, but as developers we have a responsibility to for our clients. Maybe you're sending credentials for a service, maybe the client would like to discuss sensitive company information, maybe you're about to find out your Secret Santa!

We've been encouraged in the corporate and enterprise environment to go with paid-for services that can provide end-to-end solutions to our problems. These come with the worrying fact that governments can demand they hand over the keys and all of that sensitive information is no longer a secret.

Encrypting your information with the open source GPG tools is simple enough, but verifying an identity (like a github account, twitter account or maybe even a domain) was a little harder. I'd like to show you a simple way to do encryption and verification that leaves the keys in your hands.

The pieces

Here's a quick overview of how this works.

Encryption requires you to have 2 keys, a private one and a public one, we call this a keypair. You keep the private one to yourself and you give the public one to others. When you encrypt a message you encrypt it with your private key and the recipient's public key. The only person that can unlock that encryption is whomever holds the private key that matches the public key you encrypted against.

For example, if I wanted to send Dr Nic an email containing my bank details (so he can give me wads of cash) I would take my private key and his public key and encrypt it. Because he holds the private key that matches the public key I used, only he can unlock it.

For verification of an identity you can use Keybase. My twitter account is (as you know) @fearoffish, if you search Keybase for that twitter account then you'd find that I have verified that account belongs to me and my public key is there for you to use.

Snapshot of my Keybase account

You'll also notice there are links to other services I've verified are mine like my github account, my domain name and more.

TL;DR

If you are on a Mac you can use the GPG Suite along with Mail.app and it's easy. If you use any another client it becomes more painful but still achievable.
If you are on iOS then you can use iPGMail and sending messages is painless, but receiving is still a little copy and paste dance.
If you want to verify users and then get hold of their public keys, there are services like Keybase that are starting to make that painless.

What do I need

There are many tools you could use but these are the tools that I use.

The GPG Suite:

The workhorse of our workflow, this does the encrypting, decrypting, signing and verifying of all the things. It comes with a complete commandline toolset to use as well as GUI tools that accompany them.

Keybase:

A directory of identities that will prove the person you're communicating with is who you think. For example, when I want to send Dr Nic an encrypted email with my bank account details, I can use Keybase to look him up because I know his Github account is drnic.

iPGMail:

This is the iOS application I use, it's inexpensive and simple to use. On Android you could use K9 with Android Privacy Guard (APG) to achieve the same.

Setup

On your Mac:

  • Install GPG Suite
  • Install Keybase
  • Sign up to Keybase (Invite only currently, see below)

The GPG Suite provides the majority of tools you'll be using here. There are many extensive tutorials available around the Internet for this, so I'll give the short summary and a handy tip below.

Install the Keybase client using either Homebrew or their own NPM installer:

$ # Using Homebrew
$ brew install keybase
$ # Using their NPM installer
$ npm install -g keybase-installer

Once you have the tools it's time to join Keybase, at the moment it's invite only. I'd recommend you either join the queue by signing up, or search Keybase for someone you know and it will show if they have any invites to pester them for. You can join Keybase from the cli as well as the site:

$ keybase join

Once you're registered you should go to the Keybase website, sign in and follow the instructions to verify your online identities like your Twitter and Github account.

On iOS:

  • Install iPGMail, Apple's Mail client currently does not support encryption on iOS
  • Export your private key on your Mac, you can do this from the Keybase site or from the cli gpg --export-secret-key -a "User Name" > private.asc
  • Import that private key into iPGMail using Airdrop or Dropbox. Instructions

Now you have the tools and keys in place, let's talk about how to use them.

Encrypting, decrypting, signing, verifying

On a Mac:

The good news here, is that the GPG Suite handles this all for you if you use Apple Mail. GPGMail (it gets installed as part of the suite) integrates directly into Apple Mail when you're reading it will decrypt and verify signatures, and when you're composing it will encrypt and sign. Let's have a quick look.

When I want to send Dr Nic an encrypted or signed message I'll need his public key, I can find that with Keybase (using their site or the cli) as well as verify it is the right Dr Nic.

$ keybase search drnic
-    drnic   579b1c809edbcbed8b869bdc0b92a265a0921641    github:drnic    twitter:drnic   dns//drnicwilliams.com  dns//starkandwayne.com
-    nickloose   19bbdcac4565f2f3fb06157f23caa66394fdff67    github:nickloose    twitter:nickloose   http://nickloose.de http://hellodrnick.com

Keybase has found 2 matches for this search, we want the first. We see his Keybase username (the first word after the dash) is drnic so let's keep track of him:

$keybase track drnic
info: ...checking identity proofs
✔ public key fingerprint: 579B 1C80 9EDB CBED 8B86 9BDC 0B92 A265 A092 1641
✔ "drnic" on twitter: https://twitter.com/drnic/status/621374157616480256
✔ "drnic" on github: https://gist.github.com/df629668a531b193985a
✔ admin of the DNS zone for starkandwayne.com
✔ admin of the DNS zone for drnicwilliams.com
Is this the drnic you wanted? [y/N] y
Permanently track this user, and write proof to server? [Y/n]

You need a passphrase to unlock the secret key for
user: "Jamie Van Dyke <jamie@fearoffish.com>"
2048-bit RSA key, ID 48872E720641FE38, created 2013-07-30
         (subkey on main key ID 84C040D506DF5149)

info: ✔ Wrote tracking info to remote keybase.io server
info: Success!

So Keybase has looked up the user drnic and presented me with all of the details that he has verified. I can see he has verified his Twitter account, Github account and 2 domains that he owns. It also shows me how he verified that with the Tweet and Gist. I accept that this is indeed the Dr Nic that I want to track, and I chose to permanently track him.

But what is tracking? If I'm using the Keybase commandline tool, every time I want to interact with his public key (that is every time I want to encrypt, decrypt, sign or verify something with him) I will need to verify that he is who I think. That can get tedious very quickly; Tracking removes that need. An added benefit is that tracking him adds his public key to our local GPG Keychain (when you use the commandline tool), so his public key is available to GPG Mail when we want to email him.

Dealing out the secrets

On a Mac

Let's have a look at how we'd email an encrypted message. Open up Mail.app and compose a new message, you should see some new options available to you:

Compose message with Open PGP options

Notice the lock symbol and the tick. These are the encryption and signing options. The blue tick shows me I'm signing this message, the grey lock shows me that encryption is not available. It won't be, not until I give it a recipient who I have the public key for. There are some caveats to the process here, I'll talk about them at the end of this post.

I tracked Dr Nic earlier, so I should be able to encrypt a message to him. In Mail.app it looks like this:

Example Mail.app screen when encrypting

I've used his keybase.io account for this, as that's the only email that is stored in his public key (for now). I'm going to run him through adding his other email addresses to his public key later, you can skip to the bottom of this short post to see how you can.

So the steps to send an encrypted and signed email in Mail.app go like this:

  • Compose an email, ensure the from and to addresses both exist in your GPG Keychain
  • Click the lock and tick sign so they are both blue
  • Write the email, bearing in mind that only the body is encrypted.
  • Send

My GPGMail preferences look like this:

My GPG Mail Preferences

Receiving encrypted emails in Mail.app is simple, you just receive them and they get decrypted on the fly:

Decrypted message in Mail.app
On iOS
  • Open iPGMail and click Compose in the bottom tabs
  • Add the public key for the person you're emailing, if it's not in the list you can add keys from the Keys tab
  • Add your private key as the from address
  • Write your subject and body
  • Click the Share symbol: Share symbol on iOS. If you setup your SMTP mail server you can send it from here, otherwise Copy to Clipboard and paste it into your preferred mail client.

Until email clients build encryption into their apps, this is the painful part. I prefer to send encrypted emails from iPGMail on the go because it's much easier. Decrypting requires a little effort too, but it's all in the name of secrecy!

Receiving in Mail is easier when the encrypted message is attached instead of embedded. Attached messages are basically just copied over to iPGMail which decrypts them and checks the signatures. Here's a series of screenshots to demonstrate:

A received encrypted message in iOS Mail

Click on the attachment, and you're presented with the plain text version. Click on the text and the sharing icon appears at the top right:

The share icon for the encrypted attachment

Click the share icon bring sup your list of options for sharing. We'd use the "Copy to iPGMail" option:

The "Copy to iPGMail" sharing option

If the message were embedded we would have to copy all of the text to the clipboard, and then open iPGMail which would ask if you'd like to decrypt the clipboard contents.

Adding email addresses to your private key

There are command line options to achieve this, but using the GPG Keychain is so simple you might as well use that.

  • Open GPG Keychain and double click your private key
  • Select User ID's and then the little plus icon under the list,enter your full name and the email address but leave the comment blank.
  • Click the Generate User ID button
  • Now in the menu, select Key -> Send public key to key server which shares your key with one of many open directories.
  • For Keybase you need to use keybase push --update. Anyone adding your key to their keychain will be able to use all of those new email addresses. If they are already tracking you on keybase they will need to untrack and track to get that change.

Conclusion

Encryption is still painful, however finding and verifying the people you need to interact with has become easier thanks to Keybase. If you need to send encrypted messages there is no workaround until messaging client's get onboard. Open source encryption is the future as it isn't open to a government demanding the keys be handed over and masses of people losing their privacy.

The post Encryption is getting easier appeared first on Stark & Wayne.

]]>