This is a security update to prevent logging temporary access tokens in build output. Those access tokens would have allowed a user to do a PUT request to overwrite an existing artifact only if all of the following were true:
They already had access to the build.
They identified the token in the build output.
The were to use the token within 30 minutes after the original artifact was uploaded.
A minor maintenance release, primarily to improve the single-box installation process for new trials of CircleCI Enterprise. Also, we have now follow advice from GitHub to not check if emails in GitHub Enterprise are “verified” — we will continue to check verified status if you are using github.com. If you have reason to change “verified” checks on your users’ emails let us know.
Release 1.47.0 requires more attention than other recent releases. Highlights of operational considerations for running this upgrade include:
You will need to upgrade Replicated to run this release (see below).
You will need to run a database migration, requiring bringing down your Services box and fully cycling your build fleet (downtime on the order of 1 hour should be planned)
We have changed our security policy for the underlying Mongo database - for most installations this will not require any additional work, but if you have enabled your own authentication on the underlying Mongo database please speak with us before running this upgrade.
We strongly recommend taking a full snapshot backup of your Services box before running this upgrade because you will be performing a non-trivial migration on your database. While we have taken great pains to ensure the migration accounts for all potential states of data, this will be the first such migration deployed to our Enterprise installations.
Process for Upgrading to 1.47.0 From Previous Versions
NOTE: You should plan for downtime during the upgrade process. It should not take more than an hour. We recommend you plan to turn off your build fleet as well, as you will need to cycle it after the upgrade.
Backup your Services box - we recommend a full snapshot of your VM as the simplest way to accomplish this.
Upgrade Replicated. You will need your Replicated console password and the private IP of your Services box. We’ll be referencing this doc for precise replicated instructions https://circleci.com/docs/enterprise/debugging-replicated/.
First you’ll need to login to your services box.
Second gain root access and log into (https://circleci.com/docs/enterprise/debugging-replicated/#trying-to-login-replicated) replicated.
Third If you get an error about not having a etc/replicated.conf file, then create one using these instructions: https://circleci.com/docs/enterprise/debugging-replicated/#config-file-etcreplicatedconf-not-found
Once your Replicated has been upgraded to 2.x, run source /etc/replicated.alias on the Services box to make sure the Replicated shell aliases work.
Go to your replicated console (usually available on port 8800 via HTTP at the IP or domain you use to access the CircleCI web UI) to finish the upgrade, then download and install the 1.47.0 update from inside the Replicated console.
After starting up the app, run the following command on the command line on your Services box: circleci run-migrations
We have released patches to our AMIs and other infrastructure to address CVE-2016-8655. We recommend all CircleCI Enterprise installations follow the instructions below to update both their Services box and their Builder fleet.
If you have any questions or difficulties please contact email@example.com.
We have released patches to our AMIs and other infrastructure to address CVE-2016-5195. We recommend all CircleCI Enterprise installations follow the instructions below to update both their Services box and their Builder fleet.
If you have any questions or difficulties please contact firstname.lastname@example.org.
Note for Admins: we will now block your upgrade if there are pending migrations that need to be performed against your databases.
We have changed the default behavior for builds with parallelism set above the current total container count in your build fleet. Previously we would auto-cancel any build with a parallelism above the total number of containers in your fleet. Those builds will now remain in the queue until the fleet is big enough to accommodate their parallelism setting. Builds behind those builds will continue to be bumped ahead, however, so the behavior is somewhat different than normal queuing behaviors, which is a strict FIFO model.
New System Settings option to set the maximum parallelism for all projects. This allows you to prevent teams from using more of your fleet than intended.
New option to auto-cancel “redundant” builds on a branch - found in the project settings, this new option allows you to set builds on branches other than your default branch to auto-cancel any builds on that same branch already running. This avoids running multiple simultaneous builds on the same working branch if you push several times in quick succession.
On the Systems Settings page under Admin you can now enter “Container Tweaks” that will be run whenever containers are started in your build fleet. This feature allows you to make adjustments to the build environment prior to builds running, so you can save time in each build. Note that these tweaks are only appropriate for things you want to apply to the environment for ALL of your builds.
We now parse your circle.yml before the build runs and fail if there are errors. Before, the build would start and errors would be surfaced only once they caused a failure in a running build.
Fixed a bug preventing artifacts from being generated in some circumstances after a failed build.
The Artifacts API now allows cross-origin requests when requesting specific artifacts. In the past you could do this when using the API to get a list of your artifacts but not for downloading specific artifacts. You can now do both with the API.
Fixed a bug that prevented some cases of triggering builds via the API. If you have had problems triggering builds with the API you may need to recycle your build fleet for this fix to take effect.
Fixed a bug that would cause problems if someone’s access was removed from a project in GitHub Enterprise but that person’s token was being used by CircleCI Enterprise. Other users should now be able to continue using the project as expected if the original token’s owner no longer has access.
Fixed a bug that prevented builds cancelled from the UI from actually cancelling in a timely fashion.
Various design improvements such as better notifications and confirmation dialogs when changing various settings, new links on the build page and builds list to make it easier to link directly to specific containers or parts of your build output, better information for builds marked as “Not Run”, hiding some settings that aren’t applicable to Enterprise customers, and various minor improvements and bug fixes.
PR-only builds - We have added functionality to only run builds when a pull request is open. To enable this functionality you can navigate to “Advanced Settings” for your project and enable the “Only build pull requests” option.
New Feature: The maximum size of files that you can upload for caching during builds has been fixed to 5G. The size is now bumped 20G by default on CircleCI Enterprise and customers can also override the default value to even larger size.
To override the default value, you need to run the following in a REPL of Service Box.
New Feature: Custom base URL for version control webhooks. When a new project is added, CircleCI will add a webhook to the GitHub repository of the project. With this new feature, you can override the default webhook base URL from the System Settings page under the Admin tools (available to designated administrative users). This feature is useful when your instance is behind firewall or other proxy and cannot directly receive webhooks from GitHub.
This release fixes a bug in the URL structure used to serve build artifacts.
The artifact URL format was recently changed to handle security concerns related to CircleCI’s hosted offering. The security concerns do not affect CircleCI Enterprise customers, but the change caused issues fetching build artifacts in CircleCI Enterprise installations. This release reverts the CircleCI Enterprise artifact format and resolves the issue.
Please Note: If you are using OS X builds you will need to run a manual migration as part of this release. After upgrading you will need to run this in a REPL: (circle.backend.model.esxi-vm/run-migrations!). Please talk with your account manager if you need further instructions.
The Admin Users page now has links to the builds of each user.
The API has a new endpoint /api/v1/admin/licensing that returns information about the number of seats available, number being used, when the license will expire, and how many inactive users there are in the system.
Fixed a bug where links to the documentation broke.
As part of this release we’re changing the behavior of artifacts to
only serve a whitelisted set of content-types. This means we won’t
serve .html files as text/html. This is a security risk on CircleCI
Enterprise since artifacts are served on the same domain as the rest
of the site – as a result, any user or malicious code used as part of
your build can push a specially-crafted artifact and gain control of
another user’s account.
If this is an issue, you can override this behavior by setting
“Serve artifacts with unsafe content-types” in the admin console. We don’t
recommend this, but we’re providing it for backwards compatibility.
This release also includes some changes to container
networking. Containers now each use a /24 in the subnet 172.16.1.0/16
If this conflicts with your private network, or if you were editing lxc-net
manually in order to fix a prior conflict, you can now use
CIRCLE_CONTAINERS_SUBNET and CIRCLE_CONTAINERS_SUBNET_NETMASK_LENGTH
on the builders to configure those. See “Adjusting Builder Networking” in the