Increase your Maven Package’s Exposure by Adding it to JCenter

If you already distribute your Maven packages via Bintray, your packages can gain further exposure by including them in Bintray’s JCenter! (if you are not very familiar with Bintray’s support for Maven, please refer to the user guide and to my previous post).

JCenter is the repository with the biggest collection of Maven artifacts in the world. And it’s on the best software distribution platform around – Bintray. This is where you want your Maven packages to be! CDN speed, user exposure, and live statistics to monitor the use of your artifacts are some of the benefits you get from JCenter. And if you really want to, you can also have your project synced with the older Maven Central repository.

Submit an Inclusion Request to JCenter

To promote sharing of packages within the developer community, once you have uploaded a package to one of your repositories, you can submit a request to the owner of any other repository to have your package included in theirs. If your request is granted, your package can be found just like any other package in that repository. You still maintain full control over the package in your own repository, and any changes you make to it, such as delivering new versions, or even removing it, are automatically synced to the other repository in which it’s included. So to maximize exposure of your Maven package in Bintray, all you need to do is request to have it added to JCenter.
In order to submit a request, just click on the ‘Add to JCenter’ button:

Add Package To JCenter
Once a Bintray moderator approves your request, your package will be available on JCenter, and you will receive a message into your Bintray mailbox. You will also see that your package is now linked to JCenter:
Maven Projects Linked To JCenter

Sync with Maven Central

At this point you can also have JCenter sync your package to Maven Central if you need to serve frameworks still using this repository. All you need to do is click on the ‘Maven Central’ link as shown above. Remember that you need to provide your Sonatype user name to Bintray before the syncing, but don’t worry, Bintray will remind you to do so if you haven’t already added it to your profile under Accounts:
Accounts Sonatype
Bintray takes care of the rest. Please also refer to the step by step instructions for how to sync your artifacts with Maven Central.

Good luck, and keep your package front and JCenter!

Enterprise Level Access Control with Keys and Entitlements

entitlements200x190

“Private repositories”, “Teams and Organizations”, “Permissions”…, sounds like that’s all you need to provide secure private downloads. Well, not quite. Those are great features that fit the bill if your consumer is a Bintray user. But what if she isn’t? Well, then there are signed URLs. Those should do the trick. Just sign your file and send your consumer the URL. But what if you want to share an entire repository, package or version with a group of people, but need to give each of them different privileges. Some can only view or download your files, but others should be able to delete your files or upload new ones. Signed URLs don’t cover that kind of control. They are great for single files, but for more fine-grained access control, you need a more sophisticated feature. That’s where entitlements and keys come in.

“Entitlements,” you said? What are those?

Entitlements are privileges you can give anyone…yes anyone, not only Bintray users, to entities in your private repositories. “Entities” means anything that can contain files – a whole repository, a path within the repository, a specific package or a specific version. “Privileges” means “rw”  – download, upload and delete, or “r” – download only. If you didn’t notice, the combination of entities and privileges gives you any level of granularity that you need for providing access.

But how do you unlock entitlements?

I guess you get the hint. Keys unlock entitlements. You generate a key along with its password (or Bintray can generate one for you automatically). Your user will have to provide the username and password to enable the key that unlocks the entitlement. That’s where the security lies. Only users who have both the username and the password of the key that you provide to them can access your repository entities according to the entitlements you created.

So how does it all work?

Two simple steps using Bintray’s REST API:

  1. Create keys. You can supply a password for each key you create, or Bintray can generate one for you.

  2. Create entitlements. When you create entitlements, you specify which keys to apply to them.

Now all you need to do is provide your user with the username and password for one of those keys. Your user now applies a REST API to access your private Bintray resource while including the key and password you provided as parameters to the API call. Bintray will check if there is an entitlement that allows access to that resource, and if that entitlement has the key that the user specified associated with it.

Let’s see an example at work

Let’s say user “ACMECorp” has a private repository called “acme”.

This private repo contains several versions of acprod under the “acmecorprod” directory that are protected from public access.

ACMECorp wants to authorize a “platinum customer” to download the different versions. Needless to say, “Ms. Platinum” does not have a Bintray account.

First, ACMECorp needs to create a key. Bintray offers two ways to maintain control over keys that are distributed to outside users. The easy way is to just put an expiry date on the key. A more advanced method is to set up an internal server that is used to validate and authenticate keys, and provide the server URL to Bintray when a key is created. Every time a user tries to access ACMECorp’s repositories, Bintray will validate the key using  the URL that ACMECorp provided when creating it. Since ACMECorp is very careful with its key, let’s assume they want to validate keys with their own systems:

curl -XPOST -uacmecorp:APIKEY “https://api.bintray.com/users/acmecorp/download_keys
{
“id”: “key1″,
“expiry”: 7956915742000
“existence_check”:{
      “url”: “http://callbacks.myci.org/username=:username,password=:password”,
      “cache_for_secs”: 60
      }
}

Bintray creates a key and its associated password

Status: 201 Created
{
"username": "key1@acmecorp",
"password": "8fdf84d2a814783f0fc2ce869b5e7f6ce9f286a0"
}

ACMECorp now creates an entitlement that provides download privileges to the acmecorprod directory, while assigning key1 that was just created

curl -XPOST -uacmecorp:APIKEY "https://api.bintray.com/packages/acmecorp/acme/acprod/entitlements
{
"access": "r",
"download_keys": ["key1"]
}

Bintray responds:

Status: 201 Created
{
"id": "7f8d57b16c1046e38062ea3db91838ff77758eca",
"access": "r",
"download_keys": ["key1"]
}

Basically, that’s it. ACMECorp can now just provide the username “key1@acmecorp” and its password to Ms. Platinum who can now use them to access the acmecorprod directory in ACMECorp’s repository.

For example, to download version 1.0 of acprod, Ms. Platinum would use:

curl -XGET “https://dl.bintray.com/acmecorp/acme/acmecorprod/1.0/acprod.exe” -ukey1@acmecorp -p”8fdf84d2a814783f0fc2ce869b5e7f6ce9f286a0”

But what happens now if ACMECorp and Ms. Platinum have a falling out. When that happens, ACMECorp can just delete the download key from their validation server and “Hey presto”, Ms. Platinum is now locked out of ACMECorp’s repositories.

Try doing that on Docker Hub, RubyGems.org, NuGet Gallery, Maven Central or any other repository or download center out there. Bintray is the only one that provides you with this level of control over access to your private resources.

Another one bites the Maven Central dust (and saved by Bintray)

Today, I encountered another very detailed blog post on the woes of publishing on Maven Central. Jose Maria Arranz (@jmarranz) explains why he doesn’t like Maven in general and publishing to Maven Central in particular (I am with him on a lot of valid points).

I can’t help quoting:

Fortunately when searching for how-to articles and commenting in Twitter, @jbaruch an employee of JFrog contacts with me offering Bintray.com alternative to publish to Maven Central, the people behind JCenter, I read the article “The easy way to maven central” and I was sold. Bintray provides a GUI to upload and self sign your artifacts if you provides your public and private GnuPG keys, and with a simple UI action you are published in JCenter repository, and providing the Sontaype user and password you can finally easily publish in Maven Central.

Bintray helped me to break the wall of Sonatype process. I’m saved!!

Currently I’ve released RelProxy on JCenter and Maven Central. For releasing I use Ant calling to Maven tasks to generate the required Maven artifacts and to generate a distribution zip with everything. Everything could be automated, I could add signing and uploading from Ant (or maybe by the POM) without Bintray, but Bintray auto-signing and uploading UI is enough for me, releasing is done from time to time and most of releasing process is already automated, and releasing in JCenter is a plus.

Note: Don’t forget JCenter, for instance Maven Central is no longer pre-configured in Google Android environment.

That’s what I call “success”!

Thanks for the kind words, Jose Maria! I am happy that we managed to help 🙂

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.

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 😛

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.

Hot on Bintray: Package Merging

We have recently introduced package merging: several packages from the same repository can now be merged into one. This is extremely useful when you have existing packages that are not aligned properly. For example, when you have many small technical packages (modules) that are logically one, single package, often using the same version scheme. Such situations are extremely common with maven packages that were created to reflect existing group IDs and that are effectively part of a single package (a common situation for packages imported to JCenter).

This is how it works:

Package Merging

(1) From the package you wish to merge the other packages into, click the new Merge button.
(BTW, have you noticed our new tabs UI? ;-))

(2) Once clicked, select the other packages to merge into the package you have just selected.
The merge page contains two sections: On the left side, a list for filtering, finding and selecting candidate packages in the same repo for merging.  On the right side, the  package that is the merge target – all other selected packages will be merged into it. Note that the default is the name of the package you have selected in step #1, but you can change this name.

How to Merge Packages?

(3) Click Merge to have the files and versions of all the selected packages merged. Note that your files will be laid-out in the repository exactly as they were before the merge – but you can now manage them and all your versions under a new, consolidated logical package.

Knock yourself out! 🙂

Stay in Context, See the World

New release, new features!

Focus on what’s important

You know, Bintray supports various repository types, like Maven, YUM and Debs, and more types to come. But sometimes all those goodies are just too much. You want to see and search for only certain type of packages (e.g. focus only on Maven jars to use Bintray as Maven repository). Now you can scope the whole Bintray experience to a single repository type:
select context

And woot! You are in the Java world, completely. Nothing but your beloved jars:
maven context
The selection is persistent, and you can always clear it by clicking the x on the filter button.

See where your fans are

I know I usually write too much, so this one will be image only:
map

Nuff said.

Happy publishing!