Blog

Gemnasium next Enterprise adventure

Responding to the big demand on our support, we have decided to start working on the Enterprise Edition of Gemnasium. This version will be available on premises, running on your own servers. It will allow your Gemnasium instance to reach private repositories hosted on Atlassian Stash or Github Enterprise, and many other things the SAAS version is not able to achieve today. We have planned to start a private beta in early 2016, but until then, we would be very glad if you could help us building the next Gemnasium for your enterprise:

Security: one issue, many packages

If you’re familiar with Linux distributions, you probably know the concepts of “downstream” and “upstream”; these refer to the package you install and the source project, respectively. For instance, postgresql.org hosts the source of Postgresql RDBS and it’s available as a package for Debian, Fedora, etc. When “upstream” is fixed and gets a new version, many packages have to be fixed too. One issue, many packages. Things are different for librares written in Ruby, Python or Node as the developers in charge of the project also build the package.

Dear package, give git tags to your versions

Every now and then, we at Gemnasium.com go through the source code of some package that’s been reported to be vulnerable. Not only we want to better understand the security issue, we also want to be sure about which versions are affected and which versions are fixed. This can be quite easy when the source is on GitHub, and when each individual version corresponds to a git tag, or very difficult (and frustating) when there’s not relation between the two.

Dependency requirements going wild

Listing the libraries a project depends on is generally not enough: one has to be more specific about the versions that are fully compatible with the project. This task is both critical and difficult - especially when it comes to versions that have not been published yet. Hopefully, we’ve got this wonderful convention called SemVer. For instance, if a project is compatible with version 1.0 of a library “z”, we can assume that it’s also compatible with 1.

Dependency management using commits

Today package managers make it easy to install a library at a particular git branch or commit (assuming we can access the source code of the library). This is so convenient that PHP Composer (PHP’s main package manager) goes a step further: if the source code of a library is managed using git, all the git branches are automatically turned into so-called “versions” users can easily install. Nice, don’t you think?

Security alerts go free

Until recently, a paid subscription was required to access the details of a security alert on Gemnasium.com. Today we’ve got good news for all free Gemnasium users: you can see the security alerts without paying a dime. Alerts management also went free. Not familiar with this feature? Let’s recap. When your project turns redWe at Gemnasium are constantly looking for new package advisories that may impact the dependencies of your projects.

Trusted domains removal

Last year in February 2014 we introduced a new feature called trusted domains. Basically, a trusted domain makes possible to share a Gemnasium account with users having emails matching the domain. For instance, ACME’s dev leader would trust “acme.com” domain to share ACME’s projects with *@acme.com: jane.doe@acme.com, john.doe@acme.com, etc. “trusted domains” were introduced to easy team management in medium sized companies. But there were drawbacks we were not aware of when releasing this feature.

Gemnasium in Docker wonderland

Why using Docker?Since the first version of Gemnasium, we knew it wouldn’t be possible to generate all the data we needed from the files provided. Gemspec files, for example, are pure Ruby files, and the only way to get all the metadata is to execute a ruby interpreter. Docker was not available at this time (2011), and the files were parsed like text files, leaving behind the metadata using ruby code (ie: spec.

Auto-update reloaded

Last December when we announced we were working on improving the auto-update feature after reflecting on its initial implementation. We are now excited to announce that the new auto-update implementation is online! All you have to do is to upgrade to Gemnasium Toolbelt 0.2.6. Toolbelt upgrade If you already use the auto-update feature, you will stick to the old implementation until you upgrade to Gemnasium Toolbelt 0.2.6. The latest release of Toobelt introduces a new autoupdate apply sub-command that patches the dependency files and apply the best result of the auto-update run.

Auto-Update: Lessons learned

Last summer, we released the auto-update feature that aims to ease the update of the dependencies of your projects. Auto-update leverages the test suite you provide to determine whether or not an update is compatible with your project: it iterates through the possible updates, runs the test suite, and eventually returns the best dependency files. So the auto-update is all about exploring a bunch of updates and picking the best one.