Geo Restriction Lets You Control Where Your Content Can Be Downloaded From

geolocation1When you publish software for distribution on Bintray, you generally want to give it as wide a reach as possible and expose it to as many potential users as you can. But there are also cases in which you have to restrict access to certain countries. For example, government security or export regulations may forbid you from doing business with certain countries, or your own company may even restrict your particular organization to distributing your software in your own local region of the world. This is where Bintray’s Geo Restriction feature saves the day.

White lists and black lists

Bintray’s Geo Restriction feature works by letting you define a whitelist or a blacklist per repository. If you create a whitelist, only users from countries entered in the list will be able to download software from the repository. A black list works the opposite way; users from countries in the list are forbidden from downloading software. Bintray determines where a download request is coming from by passing the request IP to a GeoIP provider who determines the country from which the request originated. Then, if a Geo Restriction is applied to the target repository, Bintray will make sure the request can be honored according to the whitelist or blacklist defined. For download requests from countries restricted from accessing a repository, Bintray will respond with an error.

Geo Restriction is available for repositories in an Enterprise account. Gold account users can also see how this feature works, but are limited to one country in the list.

It’s so easy

You can define a whitelist or blacklist by selecting the Geo Restriction tab in the Edit Repository page for each of your repositories. Note that you can only edit the repository if you own it, or if it’s owned by an organization of which you are a member and have the required authorization to do so.

GeoRestriction

Geo restrictions come first

A Geo Restriction overrides any other form of “permission” in Bintray. In other words, even if a user is a member of your team and has “permission” to download a file, or even if you’ve provided someone with a signed URL or an entitlement  to download a file, if their request comes from a restricted country, it will be blocked.

Enjoy!

 

Keep Your Secrets Safe by Serving Encrypted Files

encrypted_280x215aOnce you have uploaded your content into Bintray private repositories, it’s pretty safe through Bintray’s management of users, organizations, and teams. But what happens when you need to send a private file to someone else? Signed URLs give you an easy way to do that. Just generate your URL signing key and use the URL signing API call to create the URL. You can even make the URL valid for only a limited period of time. Now all you need to do is send the URL to the right person.

But what happens if the URL or the downloaded file gets into the wrong hands? Suddenly the file containing a license key/sensitive company information/anything-else-you-badly-wanted-to-keep-private is exposed..

Well, worry no more.  Bintray can now protect you from that kind of unwanted exposure.

On-the-fly file encryption

Bintray can now encrypt your file, on-the-fly, before it is downloaded through the signed URL. It works like this:

  • Upload your file (either manually through the website or using the REST API) into one of your private repositories.
  • Now you can generate the signed URL which will download the file.
    Nothing new yet, but here’s the thing.
    Now you can also attach a secret to the signed URL and tell Bintray to encrypt the file before it is downloaded. Bintray uses AES 256 CBC encryption for which you can provide your own secret key or ask Bintray to create one for you.
  • Now you can provide your customer with your secret through an alternative communications channel.
  • Once your customer has downloaded the file, they can use the secret key to decrypt the file using an OpenSSL command line. In other words, they need both the signed URL and the secret key.

Let’s See It In Action

Let’s assume we have a top secret “message.txt” file in a repo. We’ll use the REST API to create the signed URL:

curl -X POST -H "Content-Type: application/json" https://bintray.com/api/v1/signed_url/bintray/repo/message.txt?encrypt=true --data '{"valid_for_secs": 3600, "secret" : "my secret"}'

200 OK
{
"url": "https://dl.bintray.com/bintray/repo/message.txt?expiry=1461681694199&id=fHObRX27TU3EEpjQYIj9HFhbthU%2BPkkD4iXkRibKBYQvTFqlXP9tPUGlk5Xm3qE3&signature=nDt3t7Wj%2BP1B6chQ3AEt8iwaeowWuK66eQTP2tvgfa3AfmSAvR3IrPuVkP3tx90ihT2vMT9m1trJQ6IJZiVdSA%3D%3D"
}

If you don’t supply a secret, Bintray will create one for you and return it as an Http header: X-Bintray-Secret. Note that for that extra bit of security we limited the validity of the URL to 3600 seconds.

Your customer can now download the file from the returned URL:

curl -o message.txt "https://dl.bintray.com/bintray/repo/message.txt?expiry=1461681694199&id=fHObRX27TU3EEpjQYIj9HFhbthU%2BPkkD4iXkRibKBYQvTFqlXP9tPUGlk5Xm3qE3&signature=nDt3t7Wj%2BP1B6chQ3AEt8iwaeowWuK66eQTP2tvgfa3AfmSAvR3IrPuVkP3tx90ihT2vMT9m1trJQ6IJZiVdSA%3D%3D"

You can choose any secured way to send the user the secret. For example: phone or text message.

Now, to decrypt the file, your customer can use OpenSSL:

$ openssl enc -aes-256-cbc -d -in <encrypted file name> -out <decrypted file name output>

The tool will prompt your customer for the secret and then proceed to decrypt the file.

That’s how you keep your secrets safe. Enjoy!