<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

Sonatype Blog

Stay updated on the latest news from the makers of Nexus

Whatever, we’ve got security people for that...

As part of our launch of Nexus 2.0 and the Repository Health Check, we’re telling some stories about security and how security affects working developers. As developers we’re not always focused on security, but as attacks grow more complex, more aware of platforms like Java and .NET, and more capable of affecting custom application code, security is going to play an increasingly important role in development. In this post, I talk about a security incident I watched unfold last year and identify some of the lessons I walked away from the experience with.

But first, a message from our sponsor: Sonatype’s Nexus 2.0 offers a Repository Health Check. It’s not an answer to security by itself, but it can play a critical part in a larger, organization-wide approach to security. If you are developing applications with Tomcat, Spring, and other well-known components you’d be surprised at the kinds of vulnerabilities that are floating around in production. Once you have this capability to run a detailed RHC report in Nexus Professional, you can remove these components from applications, iterate, and get rid of known vulnerabilities. Click here to learn more about Nexus 2.0.

Missed the Nexus 2.0 Webinar? Don't worry. We recorded it just for you.

We understand. You've got a busy schedule, maybe you manage a large team of developers who all had to talk to you at once about some emergency. Maybe you were working on some interesting problem and got into "the zone". Well, if you missed it, don't worry, we recorded Jason's presentation in its full glory. Here, watch it.

 

Advanced Nexus Diagnostics with the Nexus 2.0 "describe" Flag

On Tuesday, I wrote a blog about How your build is leaking internal data and how you can prevent this using Nexus Routes. Our Engineering team chimed in on Tuesday and suggested that it would be a good time to introduce a valuable, undocumented debugging tool that you can use to gain some insight into how Nexus is resolving artifacts.

Try this in a browser that knows how to render JSON (like Google Chrome):

  1. Make a request for an artifact, let's use Apache Tomcat 6.0.29 from http://repository.sonatype.org as an example. This artifact is available from this link: https://repository.sonatype.org/content/groups/forge/org/apache/tomcat/apache-tomcat/6.0.29/apache-tomcat-6.0.29-bundle.tar.gz
  2. Next, just add "?describe" to the end of the URL. Using https://repository.sonatype.org/content/groups/forge/org/apache/tomcat/apache-tomcat/6.0.29/apache-tomcat-6.0.29-bundle.tar.gz?describe

What do cartoons have to do with build systems?

You know who this guy is? Probably not, he's Rube Goldberg.

I'm surprised by how few engineers know his work. Rube Goldberg was a cartoonist who lived from 1883-1970, he's famous for drawing cartoons of ridiculous and inconceivably complex machines. His work was important during a time in which the world was becoming increasingly mechanized and automated providing a sort of cultural "steam vent" - a way for people to poke fun at machines and industry. I'd embed his work here, but none of it is public domain, so see for yourself or search Google Images. (Be warned, you can spend hours looking at these cartoons.)

I learned about Rube Goldberg from an Engineering professor who, at the time, said, "Rube Goldberg is the most important thing you'll learn over the next four years". Back then, we all thought he was joking, but it turns out that he wasn't. In fact, I wish more people, especially "build engineers" had some exposure to these cartoons. If they had, they'd take a step back and realize that there has to be a better way.

Nexus 2.0 supports .NET: "Building a more Secure and Effective Development Environment"

While we released Nexus Professional 2.0 last week, today we're officially announcing our support for .NET. Here's a key excerpt from today's press release:

Sonatype, the company that is transforming software development, today announced that software developers using the .NET Framework can now utilize the Sonatype Nexus Professional repository manager to store, access and manage .NET components. Nexus is already the industry's most widely used repository manager for Java components. By extending support to .NET, Sonatype now offers an ideal solution for Microsoft development teams, as well as heterogeneous development organizations.

Public Service Announcement: Your build is leaking (and how to stop it)

Use Maven. Gradle, or Ivy? or any other tool that depends on a remote repository? (Which is just about every build tool these days.) If you do, there's a good chance that your builds are constantly leaking information about your projects, and if you don't take some simple measure to protect yourself external actors can learn a lot about your internal projects.

The Department of Super Secret Projects (The SSP)

To illustrate this problem, let's take a fictional government agency, the Department of Super Secret Projects, the SSP. Now everything the SSP does is, by definition, super secret. From the super secret propulsion system for a new sub to the super secret space-based laser project, this department is working on the kinds of projects that only a handful of people are working on and even fewer people are aware of.

Technology Focus: What is Scala?

Two weeks ago we talked about how many of the projects hosted in Scala Tools are moving over to publish directly to Central. That process is ongoing. In this post, I want to start something new. At Sonatype we touch a lot of different technologies and communities, and I want to make sure that we're doing all we can to help put a spotlight on some of the communities that we're watching. Whether it is a .NET-focused open source foundation like Outercurve, a customer that contributes back to Nexus OSS or, in this post, the Scala community, I think that Sonatype can at least help introduce some of these interesting technologies to a larger audience.

Gain some Insight with a Nexus Repository Health Check

Nexus 2.0 turns your repository manager into the first line of defense against security vulnerabilities and the perfect platform to assess your exposure to open source licenses. With this release, your repository becomes more than just a place to file binary artifacts, it becomes a tool you can use to implement security policy and govern which open source licenses are used in your projects.

Nexus is in perfect position to be your OSS “sentry”: keeping watch over insecure artifacts as they are downloaded from remote repositories. Your builds and your developers request open source artifacts from Nexus all the time, and Nexus relays those requests to remote repositories downloading the open source artifacts your teams have come to depend on. While your company builds software and completes CI builds, your Nexus instance is assembling a local cache of all the artifacts used in your applications. You can scan this local proxy cache for problematic components with a feature we’ve named Repository Health Check.


What is NuGet? (for Java Developers)

Nexus Professional 2.0 supports NuGet repositories, and while you'll hear much more about that next week I think it's important to introduce what NuGet is before we introduce you to how Nexus supports it. NuGet and NuGet Gallery is a relative newly way for .NET developers and .NET open source projects to distribute binaries. Nexus provides first-class support for proxying, hosting, and grouping the NuGet package repository format.

Now, I understand that the bulk of our audience is comprised of Java developers, and when a Java developer sees a .NET announcement or feature fly by it's often met with a shrug. For whatever reason, there's almost no overlap between Java developers and .NET developers, so I think it's important to talk about NuGet in terms Java developers can understand. I also think it's important for people to realize just how interested Sonatype is in spreading the word about NuGet. NuGet and NuGet Gallery remind us of Central, and if you've been paying attention to my blog posts in particular, I'm convinced that Central transformed both the way Java developers consume artifacts and the rate at which open source innovation happened over the last decade.

Nexus Pro 2.0: Support Distributed Teams with Smart Proxy

With the Nexus Professional 2.0 release, we’ve added a more intelligent approach to proxying repositories called Smart Proxy. When you configure a Smart Proxy you are establishing a relationship between two instances of Nexus.

Announcing Nexus Professional 2.0

Sonatype is pleased to announce Nexus 2.0, a major update for Nexus including several major features and features that add a new layer of intelligence about the artifacts stored in your repositories.

Distributing Binaries: Why not just use a Shared Filesystem?

I've seen it. I've seen the builds you never want to have to reckon with. The kinds of build scripts that make you stop, take a deep breath, turn to your client and say: "This is going to take a while to untangle." Ruinous hulks of procedural build logic relying on a lot of token replacement (both pre and post compilation). These builds, especially the more difficult builds, are in love with the idea of everyone having access to the same shared filesystem, or worse, they use source code management as a way to distribute binaries.

While I've seen this pattern in Unix-based environments, the "Everything is on the Shared Filesystem" build happens most often in environments that have standardized on Windows, and I'm pretty sure it happens because it's so easy to see the shared filesystem as a cure-all for collaboration. If you share Word documents and internal files through the shared filesystem, why not build output. If everyone's already connected to it, why not just dump all your libraries on it? Isn't Central just a glorified filesystem any way?

What a "Shared Filesystem" approach turns into...

It must be easy to fall into this trap, because I've untangled so many builds that assume the presence of an E: drive or G: drive instead of integrating something like Nexus. This is so common, I want to take some time to tell people what I see at the tail-end of these projects. What happens several years after someone makes the decision to depend on a shared network filesystem instead of using Nexus.

Nexus: Don't dive in until you know how to swim

When you adopt a new development tool how much time do you set aside to understand it? Do you just download a new tool like Maven, rip open the archive, install it, and just start clicking around? Or, do you read articles and books first? As we prepare to release Nexus 2.0, I’m curious about how current Nexus users adopted the tool. Leave a comment and let us know how you adopted and learned the tool, and if you had either positive or negative experiences.

Nexus 2.0 is coming. Join Jason for the first demo.

 

Scala Artifacts Now on Central

Two weeks ago, all Scala projects required a little bit of extra configuration to point to a custom repository for Scala artifacts hosted at scala-tools.org. Today, Scala artifacts are now available directly from Central. The contents of scala-tools.org are now integrated into the Sonatype OSS repository hosting service, and other projects have started to publish artifacts Central.

The Scala community will see immediate benefits from this move. There are no more extra repositories to configure. It just got incrementally easier to use Scala. If you are new to Scala, you don't need to reconfigure your repository manager to proxy another remote repository. The community will benefit from Sonatype's continued investment in the infrastructure that runs Central: a cluster of machines in both the US and the EU continuously monitored by a dynamic DNS server that can reroute traffic instantly in the event of downtime.

How did this happen? Joshua Suereth, David Bernard, and Derek Chen-Becker provided the bulk of the administrative work, and they recently decided to decommision this server and transition repository hosting to the free Sonatype OSS service. Here's the announcement by Joshua Suereth to the user forums on scala-lang.org on January 17th:

Scala-tools.org is going down and not accepting any new OSS projects. For those of us who wish to continue release software, I recommend migrating over to Sonatype. They put a few (good practice) limitations on contributions, but scala-tools.org would have done the same before long anyway. The benefit of Sonatype hosting is that your projects will make it onto the maven-central repository and benefit from the myriads of mirrors. Here's the link for how to get started contacting Sonatype: http://nexus.sonatype.org/oss-repository-hosting.html

Publishing Your Scala Project to Central via Sonatype OSS

If you maintain a project that previously published to the scala-tools.org repository, here are three resources that provide guidance for Scala developers looking to publish Scala artifacts to Central: