If you are not currently paying attention to checksums in your repositories, you should, and if you are looking for an extra level of security, you should definitely start signing your releases with PGP signatures. Security issues are rarely the priority in a development effort, but in this case, if you appreciate the importance of your repository manager, you'll agree that you don't want to wake up one day wondering about the the integrity of you binary artifacts.
One of the "features" of a competing repository manager is that it creates "Checksums on Deploy". While Nexus does compute checksums for a UI-based artifact upload and the tool does allow you to rebuild checksums for exception cases, we don't automatically compute checksums for artifacts deployed with build tools. Why? That's not how security works.
To do that is to encourage two "worst practices": first, that checksums are an after-thought and, second, the checksums shouldn't be signed with a PGP signature. It's impossible to sign checksums if you rely on a repository manager to do this for you, and when you push this responsibility up to an automated process, there's no way to guarantee that artifacts were signed by an individual (with a PGP key and a password).
Checksums: Often ignored, critical to security...
First, why do checksums matter anyway? You calculate checksums for a few reasons. First, a checksum, is one of several methods for making sure that a file hasn't been modified in transit. When you download a file from a server, you grab the MD5 or SHA1 checksums and compare them to the checksums of the file from the remote repository. This is just the first level of defense against compromise. If you've configured Nexus to download from a Central mirror, Nexus is smart enough to go and get the MD5 and SHA1 from the canonical repository: repo1.maven.org. You are protecting yourself against a "man in the middle" attack where someone intercepts your call to download an artifact and injects some malicious code, the checksums wouldn't match up and you'd know that something bad was happening.
If you want to use a repository manager that looks at checksums, use Nexus 2.0.1. The open source version of Nexus lets you set a strict checksum policy which will be applied to a remote repository. Nexus will refuse to serve an artifact if there is a problem with the Checksum if the policy is set to "Strict".
PGP Signatures: Another Level
...but, if someone were smart enough to intercept your traffic and rewrite JARs, they'd probably be smart enough to rewrite checksums as well. What's the defense against that? Well, take a look at the artifacts for nexus-api. Not only do we ship checksums, but we ship PGP signatures of checksums and artifacts. Now, not every project in Central does this, especially older artifacts, but most new projects have to follow a set of rules enforced during the process of publishing artifacts to Central.
On the consumption side, you can use Procurement in Nexus Professional to check for the presence of a signature, and on the publishing side signing your releases with a PGP signature and making PGP signatures available on a public keyserver will help people double-check that artifacts and checksums are consistent. Note: I think there's more work to be done to create tools that encourage the use of PGP keys and, more importantly, give repository administrators some control over what keys are to be trusted.
Automating Checksums and PGP Signatures?
Returning to this idea of automating the generation of checksums and signatures. It isn't something we recommend. Checksums and signatures should be generated as a part of your build, and as a further guarantee of security, you should avoid ever recording your GPG passphrase in an automated build. Your build generates checksums and your build signs artifacts (and if you are going to sign something, ideally, you'd be there to apply your signature). This may seem impractical to many readers, but a commitment to security often involves accepting some ideas that introduce inefficiency.
Security is always a tradeoff, and it's easy to err on the side of having too much security or having none at all. None of the mechanisms outlined in this post are perfect guarantees of security on their own. If artifacts can be compromised, so can checksums. If checksums can be compromised, PGP signatures can be replaced. Also, checksums and PGP signatures are only valuable if people start paying attention to them. Whether it is through the process we've put in place to require PGP signatures and checksums for artifacts published to Central or through the decisions made in the implementation of Nexus, Sonatype is committed to creating more secure systems.
