lemonbytes

husband, dad, steelers fan and software engineer

Mar 13, 2014


I'm really excited to share a new blogging endeavor with my friend Mark Buetow, Shave with Swagger and Good morning! is our first post.  What should you expect in the future? Posts about shaving, product reviews, blade analysis and random pontifications about our honest devotion to the pleasurable indulgence of a decent wet shave in the morning.



For awhile now I've wished that Bamboo had an app, or something that could deliver a push notification when a build starts or finishes. Sure there is email, but that means my build notifications will get lost in all of the other junk I am quietly ignoring in my inbox.  What I want is a targeted notification for my builds. So I got to thinking, why not leverage Pushover?

I decided to setup some inline script tasks on one of my bamboo plans using the following code (supply your credentials accordingly), in order to give Bamboo push notifications.

https://gist.github.com/stanlemon/8726494

Of course you can kick this up a notch by changing the message, using additional variables and throwing other notifications in at very stages of your build plans.



I use Atlassian's Bamboo for continuous integration on a lot of projects. I'm a huge fan, it's a solid product with a lot of flexibility and the OnDemand service coupled with EC2 instances and custom EBS volume make for a really robust cloud based solution to continuous integration. Almost every project I put into Bamboo involves a call to load composer and install dependencies. Many of the projects I dabble with belong to other people and so they're locked down with some form of authentication and not normally in Packagist. In the past this has created some challenges with installing my composer dependencies, but this past weekend I think I finally found a tolerable solution to my dilemma.

In addition to being a big fan of Atlassian's Bamboo I also really like Atlassian Bitbucket. I became a heavy Bitbucket user back before Atlassian bought the product because I was a heavy Mercurial user and it was the only hosted solution available. When they were bought and added git I kept using them because they offer free private repositories, whereas competitor GitHub does not. I've had problems when I develop a private package and then want to use it in an application. My workaround up until this weekend was to create a "deployment" user and give them access to my private repository, finally including it's username/password on my vas url in the repository block of my composer.json. This is all sorts of ugly and I have never been satisfied with it. In addition to not being safe or secure it also chews up one of the sacred five users you can team up with on a private repository.

So this weekend I set out to find a different approach to private Bitbucket packages in composer. One that wasn't so ugly and didn't make me feel so insecure about my setup.

BitBucket (and GitHub for that matter) have this concept of a deployment key. It's a private/public ssh key combination that grants read-only access to your repository without chewing up a user account to do so.  It's specifically geared toward the problem I was trying to solve. In my case Bamboo executes it's tasks as the 'bamboo' user.  The trick is getting the private portion of your deployment key into a place that Bamboo can use it.  Bamboo OnDemand creates EC2 instances when it needs to run a build and then terminates it after its done.  This is great because it keeps costs low and it means you don't have to worry about a machine getting gunked up with stuff between builds. It also means there's no shared state between runs, so sticking a private key on your EC2 instance only helps you for a little while.  But wait a minute... what if I set that up with a task in my job when it runs?

I wound up creating an initial task to setup my private deployment key like this:

[gist]https://gist.github.com/stanlemon/8661196[/gist]

Fortunately Bamboo lets you lock down your user's ability to see these sort of things and the logs don't show anything indicating what's going on, which makes it relatively secure - at least seemingly more so than sticking a plain text password in my composer.json file.

Now if you're familiar with Bamboo at all you know that the initial repository setup does not allow you to clone using ssh. This is limited only to the Java implementation of git that Bamboo uses to poll the repository. The default EC2 images ship with a full first class git, and so that means if you declare your package in the repositories block like "git@bitbucket.org:team/project.git" it'll use the aforementioned key and load just fine.

Life is a lot easier with an on-premise install of Bamboo where your disk persists between builds and you can set that key up permanently, but for those of us living in the cloud this will do the trick. You can use this approach on-premise too though and you can even use it with Jenkins if that's your preferred continuous integration implementation.


Dec 10, 2013


A lot of services across the web are amping up security in lieu of recent breaches. One technique to do this is called two factor authentication. It’s a name that perfectly describes the technique, but explains absolutely nothing.

So what is two factor auth and why do you care? Simply, two factor auth is your password plus something else. In most cases that “something else” is going to be a text message, an email or a secure token system like Google Authenticator or Authy. Some banking websites have been doing this forever via email but the growing trend is to use text messages as they can be a considerably safer approach to this sort of authentication.

Here’s the thing to keep in mind… You are most likely already doing two factor auth in your life - you just don’t think of it like that. If you have a safety deposit box for example, it takes two keys to unlock it. Without both sets your birth certificate isn’t going to see the light of day. If you’ve bought a car recently you’re also using two factor auth as every car key these days comes with a microchip implemented in it. You can’t start your car with a copy of your key, you need to use the key plus the microchip if you want to drive anywhere. And if you don’t have that microchip your car not only won’t run, it very well may lock up on you too! These are two factor strategies, where they prevent criminal-like-folk from copying your keys and running away with your identity and precious automobile. Why not use that same strategy with your personal information stored securely on the world wide web?

How does two factor work with your favorite web service? There are two typical routes, the most common of which involves your cell phone and a text messaging plan. If you don’t have unlimited text messaging either pony up or take a trip to the Verizon store for an upgrade. When you login, normally for the first time, you’ll get a text message from the service in question. Websites like Facebook will ask you to punch in a unique code on this text message after you enter your password, but before you actually get to login to the service. The idea is that your cell phone is most likely on you and there’s a uniqueness to the device in your pocket that a hacker cannot replicate. Stealing your password then is not enough, you need to steal a person’s cell phone too - thus making it infinitely more difficult for a hacker to access your information.

Not every service has two factor authentication, but a lot do. You should evaluate the services you use every day and consider enabling two factor authentication where it’s available. I’m a big proponent of enabling two factor auth for your Google, Dropbox, Evernote and Facebook accounts. As these items likely contain more personal data about you and your friends than anything else you’re using it’s important to harden your security around them.

Don’t get me wrong… Two factor auth doesn’t just slow down the losers trying to compromise your data, it slows you down too. Principally though this should only happen when you setup Facebook on your phone, or configure your email client to pull down your Gmail. Your setup is slower, but your data is safer. In my opinion this is a fair trade considering what is at stake. One other thing to keep in mind… These services don’t do two factor auth for their sake. It actually costs them money to run, with almost no return on the investment! Two factor auth is a service for you, to protect your data and keep you, your family and friends safe.



So you don’t give a crap that your data gets exposed or hacked? You don’t have anything to hide, so the potential leak isn’t worth the added effort of complex passwords and password management systems.  You want a simple, easy to remember password.  Fair enough.  I get it.  You don’t give a crap, but here’s the thing… Your mom might. Or your dad, or your sister or your great Aunt Bertha or your Cousin’s best friend that you just recently added on Facebook.  And that’s the point!

Let’s say you’re one of the few who don’t give a rip because you have nothing to hide. Stop being selfish!  Most of this password protection junk has nothing to do with you.  It has to do with the information you have access to, like my email address, my phone number, the names of my kids and that picture I shared with you from my best friends bachelor party!

You are most likely passively collecting information in the services you use every day.  It might just be people's names, but it also could be more serious information like their addresses and phone numbers.  A data leak because you used a stupid password exposes all kinds of things that your friends and family don’t want everyone under the sun to know. And not just because it’s private information, but because it effects their safety!

It can get worse then just the revealing of address and phone numbers though.  How you say?  Consider the fact that that Facebook app on your phone posts where you go.  Maybe it’s a restaurant, church or even the grocery store.  You’re a hip social media rock star and you’ve been capturing your geo-coordinates and checking in wherever you go.  So have I, your mutual friend on Facebook,  as well as your neighbor’s 16 year old daughter.  Now ALL of that information about where you’ve been and the trends of your daily activity is accessible to some low life hacker that cracked your stupid-simple password.  Is this sounding scary yet?  Let’s keep going…  That hacker might decide to pay one of us (you, me or or your neighbor’s teenage daughter) a visit.  Or maybe the hacker sells that valuable data information to a petty thief or a pedophile. Now is it scary? It ought to be.  This is what happens when the flood gate known as your weakly protected account is opened.

You are just a gateway drug for a hacker. Your credit card, social security number are low hanging fruit compared to the peripheral data you are toting in those web based accounts you login day in and day out. Protecting your accounts with unique and complex passwords isn’t just about you.  It’s about everyone you engage with using those services.  It’s about personal protection, for you, your family and your friends. So I get it, you don’t have anything to hide that you’re worried about a hacker exposing. But I do.