Sign me up!

Bintray Premium gives you cool new features such as private repositories, permission management, more storage and so much more. One of the biggest benefits of using a Premium account is the ability to create expirable, signed URLs for your repositories’ content.

Signed URLs you said? What’s that?

A signed URL is an obscure URL with a (potentially) limited lifetime. When your artifacts are published in a private repository, each artifact is hidden from unauthorized Bintray users. If you want to allow any Bintray user, or even or a non-Bintray user to download your package, you can generate a one-time unique URL with an option to limit its validity so that is expires after a certain amount of time. You can also revoke any outstanding URLs at any time.

How does it work?

When you become a premium user in Bintray, your account holds unique, internal, private and public keys. The URL you decide to sign, will be encrypted and decrypted with those keys.

Let’s say user “srubin” has a private repository called “artifactory”.

This private repo contains a file, “artifactory.rar”, that protected from public access. Only authorized users can download it using the standard download link, which is:
https://dl.bintray.com/srubin/artifactory/com/jfrog/artifactorypro/artifactory.rar

Bintray Premium Link Signing

Bintray Premium Link Signing


To allow a one-off download of this file we will generate a signed URL for it using a simple REST call:

curl -XPOST -usrubin:APIKEY "https://api.bintray.com/signed_url/srubin/artifactory/com/jfrog/artifactorypro/artifactory.rar"

Response:

{
"url":"http://dl.bintray.com/srubin/artifactory/com/jfrog/artiafctorypro/artifactory.rar?expiry=1415101346415&signature=BfRaL2HDbCDsPyPThAnlI%2B0TG26NcH4i0ugyKZ%2FjevLiNfEdHXyUh0Q1NNGc1Pz7V1nZkeh9RAafrUyUE%2FMOFQ%3D%3D"
}

By default, this URL will be valid for 24 hours, but we can change that by specifying an expiry time in a simple JSON configuration document:

curl -XPOST -usrubin:APIKEY  -H "Content-Type: application/json"  -d "{\"expiry\":7956915742000}" https://api.bintray.com/signed_url/srubin/artifactory/com/jfrog/artiactorypro/artifactory.rar"

Response:

{
"url":"http://dl.bintray.com/srubin/artifactory/com/jfrog/artiactorypro/artifactory.rar?expiry=7956915742000&signature=g5OC3RXkFhnnFYfsgqFXw9J%2FfmwCzeIsd%2FHCRgm5VjCAhrzij1GPuAv0JwZPhGD0mEqs1y2WcQ77LMrDzp9%3D%3D"
}

More details about this API can be found in our documentation.

Summary

Signed, expirable URLs is a cool new feature of Bintray. It allows you to automate the generation of one-off download URLs and distribute them to any end user.

We will soon extend this feature to make it even cooler. Keep following to see what we have in store for you!

Feel secure with SSL? Think again.

Recently, we’ve heard a lot of discussion about the trust we place in public binary repositories. For example, Maven Central, a popular legacy repository maintained by Sonatype, was recently compromised by a successful MITM attack. In response, Sonatype set up an https access to central (removing the demand for a $10 donation to the Apache Foundation for using SSL). This has no impact on millions of maven installations in the world, which will continue access Maven Central via http unless manually reconfigured, but the interesting question is – is that enough?

While SSL is important in guaranteeing the integrity of downloaded files, it doesn’t say anything about the integrity of the files in the repository itself. The only(!) verification mechanism in the repository itself that Maven Central and other legacy repositories suggest you blindly trust, is the set of signature files uploaded with the files. Interestingly enough, modern repositories such as RubyGems.org, npm-registry and Bintray don’t force you to sign your files at all. Let’s try to understand why.

Here’s tl;dr if you need one.

Is SSL access enough for us to feel secure?

To answer this question, let’s consider Maven Central. This is a repository that works with SSL and “secures” the files with PGP signatures. In theory, these signature files strongly identify the signer (assuming that both the jar files and the signatures are served over SSL). But do they really?

Let’s see how it works:

  • The author uses a gpg tool to generate a keypair for identification.
  • The author then uploads the public key to a trusted key server (one of MIT, SKS OpenPGP Public Key Server or PGP Global Directory).
  • Anyone who wants to download a package and verify its integrity runs a signature check against one of the servers, and gets the unique and verified identity of the author.

Is it so?

Let’s run a couple of experiments, and see how securely the “secured” Maven Central is really maintained.

Here’s one of Sonatype’s latests jars: nexus-core-2.8.1-01.

Let’s download it see what’s the signature says, after importing the signer’s public key:

>gpg nexus-core-2.8.1-01.jar.asc
 gpg: Signature made 05/27/14 18:00:54 Central Daylight Time using DSA key ID 8DD1BDFD
 gpg: Good signature from "Sonatype, Inc. (Sonatype release key) <dev@sonatype.com>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: 2BCB DD0F 23EA 1CAF CC11  D486 0374 CF2E 8DD1 BDFD

Whoa! What happened?! “There is no indication that the signature belongs to the owner”?!

Wait a second. Does that mean that anyone can generate a keypair for Sonatype, Inc. “(Sonatype release key) <dev@sonatype.com>” pretending to be the Sonatype release team?

Here’s an amazing picture for you:

heinrichh@uni-duesseldorf.de

Click to see

Hiene writes code

 

According to the “trusted” key server, all those signatures belong to the German poet Heinrich Heine. Well, I would say that’s quite unlikely since he passed away quite some time ago1.

Let’s run a couple of more tests (go figure, maybe it’s only Sonatype who can’t generate a “truly trusted” signature):

Here’s a signed Eclipse artifact:

>gpg aether-1.0.0.v20140518-source-release.zip.asc
 gpg: Signature made 05/18/14 12:54:52 Central Daylight Time using DSA key ID A7FF4A41
 gpg: Good signature from "Benjamin Bentmann (CODE SIGNING KEY) <bentmann@apache.org>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: BA92 6F64 CA64 7B6D 853A  3867 2E20 10F8 A7FF 4A41

Same again!

Here’s Oracle’s OpenJDK tool:

>gpg jmh-core-0.9.5.jar.asc
 gpg: Signature made 07/24/14 13:53:36 Central Daylight Time using RSA key ID 060CF9FA
 gpg: Good signature from "Evgeny Mandrikov (CODE SIGNING KEY) <mandrikov@gmail.com>"
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: A413 F67D 71BE EC23 ADD0  CE0A CB43 338E 060C F9FA

Whoa, who’s Evgeny Mandrikov? An Oracle employee? Nope. Why does he use gmail? Let’s see, maybe Sonatype pre-verified him when they gave him access to Maven Central? Did he establish a relationship with Oracle or something? Nothing, not a single question. “I have nothing to do with Oracle, but still want to publish OpenJDK artifacts!” “OK, go ahead”. Can you trust him to provide you with authentic OpenJDK artifacts? Not sure2.

You get the picture. You can’t trust those self-generated key-pairs. And the Trusted Key Servers themselves acknowledge it! Here’s a quote from the Key Verification Policy of PGP Global Directory:

…there is always a risk that the verified key in the PGP Global Directory is not actually owned by the person who appears to own it. While the verification mechanisms in the directory are suitable for many purposes, you should endeavor to use additional mechanisms…

That’s exactly what modern repositories, like Bintray and GitHub do. But we’ll get to that shortly.

But what about WoT?

Ah,” one can say, “that’s because you don’t have a clue about how pgp signatures work! You need to establish a Web of Trust with the signer and voila, the message is gone!

While technically correct, this makes very little sense in our context.

WoT works for the original usage of pgp signatures – authenticating content from people that you know directly, or indirectly through your contacts. For example, it works great for signing emails. You are likely to get email from people in your first, second or third circle of connections, but almost never from complete strangers. With packages from an Internet repository, this concept breaks completely. Chances that a developer personally knows the creator of a package, even if its indirectly to one or two levels, are close to zero. Same works for the creators of a package. As an author, you have no idea who is going to use your package. You can only hope that they’ll be a bunch of strangers that you don’t know :-D.

I am intrigued. Show me how can I maliciously upload a forged artifact to Maven Central without even using MITM!

Tedious, but straight forward:

  1. Invent a fake identity (with a fake, but functional email address).
  2. Generate a keypair for it.
  3. Upload to a public key server (that’s where your email is needed).
  4. Follow the guide. The trickiest part is faking a story about your artifact to get your account set up in oss.sonatype.org through the Sonatype JIRA. Well, be creative!
  5. Within a couple of hours (or days) your artifact will get to Maven Central. If the description you invented  looks realistic enough, no questions will be asked. Somewhere during  the process of uploading and releasing files, Sonatype will check that the signatures with which you signed your artifacts match the email you used for your oss.sonatype.org account. But of course, they match.
  6. Mazal Tov! Your fake artifacts are now in Maven Central. From there they will be securely(!) downloaded over SSL to your victim computers by Maven.

Easy? Well, not really. Looks like the MITM attack was easier. But that’s what it takes to add a jar to Maven Central.
Doable? Absolutely.

But how is Bintray different?

Well, we realize that in the modern world, where identity theft is one of the more popular crimes, you can’t blindly trust an online identity. So, like many other services, we recommend that you assess how trustable any particular content is (a jar in our case), based on the credit the community gives to the Internet identity of the author.

Here’s what I mean:

Let’s say you want to download Groovy. Here it is. Let’s see how can you establish trust in Groovy binaries:

  • You can see the links to a website and GitHub.
  • You can see that this package belongs to an organization: Groovy. You can clearly see the list of members, and check each and every one of them.
  • Here’s Guillaume Laforge.
  • Check out his twitter account – almost 8.5K followers.
  • Here’s his blog, all around Groovy.
  • LinkedIn? Looks good.

So, can you trust him? Probably. He’s an admin of the Groovy organization, so his reputation is the guarantee that the organization and the files in it are authentic. You’re good to go. Or not?

That’s up to you! We give you the information. You decide if you can trust it or not.

 But Maven just goes out there and brings stuff!

To create a safe build you must use an in-house binary repository manager:

  1. Install it.
  2. Configure a “dirty” and a “clean” repository.
    1. The dirty repository should be able to proxy a remote source of artifacts that gives you a good insight on artifact producers’ identities (not just a pile of files with self-generated signatures).
      Consider proxying Bintray’s JCenter instead of Maven Central. JCenter is a superset of Maven Central, so finding packages won’t be a problem.
    2. The clean repository is a local repository with no Internet access.
  3. Configure your build tool (Maven?) to be able to build against either of them.
  4. Use a “sandbox” (e.g. a vm) to run a “dirty” build against the dirty repository. Its cache will be populated with all the artifacts needed for the build.
  5. Examine the identities of the publishers of those artifacts (remember to select a binary repository that can generate a list of dependencies used for every build) against the information you have about them (as you understood, it’d better be more than self-signed signatures).
  6. Promote the artifacts that you trust to the clean repository (remember to select a binary repository with deduplicated storage that gives you free and immediate “move” operations).
  7. Now you can safely build against the clean repository!

Here’s the summary (a.k.a. tl;dr):

  1. SSL is an important way to verify that the files you trust get safely from a server to your machine.
  2. Don’t let SSL give you a false sense of trust in the origin or author of the files.
  3. Don’t blindly trust self -issued signatures. One can generate a signature for any identity, sign any file with it and upload it to Maven Central.
  4. Go with a platform that enables and encourages web identity verification. Check the author and decide for yourself.
  5. Use a binary repository manager to discover and control the artifacts needed (and select it wisely).

1A gpg tool to work with pgp signatures was developed in Heinrich Heine University of Dusseldorf. In honor of the late poet after which the university was named, all defaults in the tool were initialized to Heinrich Heine, with the expectation that people would replace them their own details. Apparently, that didn’t work. People just enter-enter-enter through the settings generating dozens of key-pairs for the poor German, illustrating the absurdity of  “authentic”, self generated key-pairs.
Thank you, Heinrich!

2Actually, you can. Oracle do not distribute binaries of OpenJDK, and Evgeny volunteered, and was empowered by OpenJDK committers to do it for them.
But can you know without being personally familiar with Evgeny?! No, you can’t.

Nodeclipse: 500k downloads per month and counting!

Paul Verest

Paul Verest

Paul Verest, the Nodeclipse project lead posted to the Nodeclipse blog about his experiences with Bintray.

He talks about how the Bintray distribution platform freed up resources to take care of the truly important things – driving Nodeclipse and Enide Studio forward!

The main benefits Paul mentions are:

  • Speed – almost 3 times faster than GitHub and more than 5 times faster than SourceForge!
  • Eclipse Plugins Update Site (P2) Support -  allows users to define a unified Eclipse Update Site for a bunch of Nodeclipse related plugins (with a single URL that always points to the latest versions)
  • Simple UI – simplifies the release process for the Nodeclipse team
  • Additional small perks – flexible statistics and new release notifications.

Read on the original article on the Nodecipse site and join the discussion.

Hosting your Eclipse update site (P2) on Bintray.com

Did you know you can easily host your Eclipse update site on Bintray.com?

After registering to Bintray (and optionally, creating or joining an organization), it’s as easy as 1-2-3:

  1. Use the predefined ‘generic’ repo (or create a new one) if you are generating a plain P2 update site, or ‘maven’ repo if you are generating a Tycho zipped site, and create a package for your site.
  2. Upload the Eclipse update site meta files (content.jar, artifacts.jar, etc. for site, or zip file with Tycho site) under the latest version, typically to the root path.
  3. Click on the “Set me up” button on the package page to get the necessary URL to use in Eclipse.

That’s pretty much it. Here’s an example:

Nodeclipse hosts their update site on Bintray:

Nodeclipse Eclipse update site on Bintray

Click to see Nodeclipse Eclipse update site on Bintray

In Eclipse, users just use the Bintray package link as an Update Site URL:

Install Bintray packages from eclipse

Install Bintray packages from eclipse

Cool, right? Well, almost :). Nodeclipse created an update site for each version (notice the ‘0.10.0’ at the end of the URL). It means that users may need to change this URL in their Eclipse settings for every new version released. That’s because up until recently you couldn’t override P2 metadata files.
But that’s not the case anymore! By using the REST API upload method you can always override P2 metadata files with new ones. Putting these files in the root of the repo lets users point at a permanent, single URL to configure Eclipse. Since these files are in the scope of the repository, i.e. do not belong to any package & version, the URL of the REST upload request should not include the package nor the version:

PUT /content/:subject/:repo/:file_path

Expect the upcoming release of Nodeclipse to follow this improvement :).

So here’s a win-win situation for you:
You get an awesome and free distribution platform with near-real time statistics, download-able request logs and and metadata.
Your users get lightening-fast downloads via a CDN directly from Eclipse, plus lots of new ways to get involved with your package. For example, the ability to follow organizations and users, or to review, rate and watch packages.

And oh, did we mention that Bintray is completely free to use for open-source packages?

Enjoy Bintray and use it as pain-free gateway to Maven Central

What does it means when some tool or framework has literally dozens of guides, pages long each?maven central dinosaur
It probably means that it is popular, or complicated to use. Usually, both.

That’s the story of Maven Central (a.k.a. Central Repository, a.k.a. repo1, a.k.a. ibiblio). Of course, there is a better alternative nowadays – Bintray is already a super-set of Maven Central, both in terms of UI, UX and content, but Maven Central is still “hardwired” into the super-popular Maven 2. As such, it is being used by many – by Maven users of course, but also by Ivy, and even by Gradle users (those not familiar with Bintray’s ‘jcenter()’ repo yet). That means that you (still) want your package to also end up  there.

But getting it there is painful… *Very* painful.

Maven Central #fail

Click to enjoy the comments :P

To understand how painful, next time you take a break, here’s a nice old-school text quest.

So, you get the picture. There has to be a better way. Indeed there is. Why don’t you use a proper distribution platform, with easy and intuitive on-boarding, publishing and sharing, with rich near real-time statistics, downloadable logs, packages inclusion, watching and sharing abilities, and much more. You know, Bintray.

Here’s the deal:

First, some simple one-time setup needed to be done.

  1. Register to Bintray and set up auto-signing: Generate yourself a keypair, if you don’t have one. Add it to your profile, and setup your default Maven repo (or a new one) for signing with your GPG key: Bintray can then sign your jars automatically.
  2. Add your Sonatype account under “accounts”. If you don’t have one, follow this procedure (yeah, we know what you are saying when you see it, that’s the last “wtf” in this guide, we promise).
  3. Create and link your package: Import from a GitHub repo or create a new package for your Maven project (multi-module projects can map to a single package). Click on “Add to JCenter” to get your package linked to the largest Java Maven repository on the planet.
  4. Set up Maven up to deploy to Bintray by copy-pasting the pom.xml snippets from “Set me up!” guide, or use the bintray-gradle-plugin.

Now, for each release, it’s easy as 1-2-3:

  1. Deploy: Deploy files to Bintray by running your build tool*.
  2. Publish: Review the build artifacts in Bintray and publish the version files if satisfied. Don’t forget to advertise your new release using a single-click tweet.
  3. Sync: On the version page go to the Maven Central tab (the one with the dinosaur icon on it), enter your Sonatype password and click “Sync” and you’re done! Your package is now in https://oss.sonatype.org/content/repositories/releases and will be synced to Maven Central (and they usually take their time). In case of a sync problem, Bintray will automatically take care of any needed cleanup.

Next, you’ll probably feel the urge to to tweet something like this:

Don’t resist it. You are joining spring, netty, jenkins, joda-time, asciidoctor and many many others that already feel the same way.


* Remember: distribution platform is not for SNAPSHOT-s. Stay tuned for our post about oss.jfrog.org to see how you can get access to a free binary repository with one-click promotion to Bintray.

Increase your package visibility, the social way!

So, your binaries are hosted on Bintray and you are watching your package download stats grow.
It’s time for a boost!
Two great new features online today; they might be small but they are powerful in spreading the word about your packages, or packages you like.

The Latest Download Image

Add a Download Link badge to your GitHub or Bitbucket ReadMe’s using our new Latest Download Image generator.
This will create a badge showing a download button, linking to the latest version of your package.
Currently we support: Markdown and Asciidoc, or plain old HTML.
Latest Version Download Badge

The Version Notification 

Visit any package hosted on Bintray and you will now find a “version notification link” badge that you can copy-paste to your website / blog / email.
Version Notification Link Badge
When your visitors click the badge, Bintray will encourage them to Watch the package, in Bintray’s usual friendly, non-obtrusive kind of way.
 
Watch alert - after clicking a version notification badge
Enjoy…