Let's Hash It Out: Debian Acquire-By-Hash
Our more observant Debian users may have noticed that we rolled out support for acquire-by-hash over the past week - you may have also noticed fewer pipeline disruptions as a result!
What does this mean for me?
If you're someone spinning many plates, you may have encountered some hiccups with your pipeline when updating your repository whilst simultaneously deploying from it - causing `hash sum mismatch` errors. This is the result of an active repository, with indexes fetched while the repository is in a state of change.
Well, no more - farewell to the troubles of yesterday! Debian acquire-by-hash functionality is here to steady the ship and avoid pipeline interruptions caused by those pesky race conditions. This removes the need for any pipeline workarounds - e.g. built-in delays.
How does one acquire this functionality?
So long as you are using APT v1.2.0 or newer, APT will take care of the rest. If you're not, we recommend upgrading - but don't worry, your client will still work; it just won't be able to fetch indexes using acquire-by-hash.
We have more exciting news on the way...
Keep an eye on our changelog; we have some exciting updates landing very soon - we think you'll be just as excited as us when they land!
A Secret Handshake: SAML-only Authentication
Good news! As part of our efforts to further secure access for users in your org, we're introducing the ability to enforce SAML-only Authentication. Plus, a bonus is that SAML is now fully self-service configurable:
With SAML-only Authentication configured, all members of your organization will no longer be able to use password-based or social-based authentication. In other words, they must use SAML when authenticating. This will ensure that they contact only your Identity Provider for authentication. If the Identity Provider says no (i.e. because the user is removed, locked out, etc.), they'll not be able to log in anymore.
How do you configure SAML-only Authentication?
- You need to be an Owner or Manager for your organization (see docs on Organization Roles).
- Then you'll find it within the "SAML Authentication" section of your organization settings (screenshot).
- Ensure that the "Enforce SAML-only Authentication (for All Users)" checkbox is ticked.
- Click "Update". You'll now be enforcing SAML-only authentication in your organization.
You'll also be able to utilise the same page for self-service SAML configuration. Now you'll be able to enable, disable, enforce and configure SAML as and when required. You can specify either a metadata URL, where we fetch the SAML metadata from your Identity Provider automatically or provide us with the XML directly.
What's next? For this area of the application, we'd like to implement SCIM for automated off-boarding.
Note: Single Sign-On via SAML (i.e. using an external Identity Provider to authenticate users) is an Ultra tier feature. You can find out more about Ultra features on our pricing page, and if you'd like to book a chat with us, we're always happy to talk (no hard sales push).
Lean On Me: Custom Support Details
Good news! You can now set a custom support email and URL for your organizations. For error messages when installs or setups go wrong or where we need to communicate an issue to your users, we'll now display your own support email and URL. You can configure it in your org profile settings:
For example, if your users use the automated bash installs for Linux-based scripts, and an error is encountered during setup, we will display your support email and URL instead of the defaults. So they'll now know how to contact you to resolve the situation quickly and efficiently.
We'll continue to roll out support (no pun intended) for this in other places where a contextual error message could be displayed. Don't worry; if the error message is because of an issue on our side, we'll still let the user let it know it was our fault, and we'll happily handle those issues for you. That's why we're here, after all!
Open All Hours: Repository-Level Privileges
Good news! If you've been looking for an easy method of setting the default access for a repository across your organization, we've got you covered. Introducing repository-level default privileges:
These complement the existing default org-wide repository privileges.
Such that the privilege for a user is the greatest privilege granted to them via:
- Assignment to them directly, via "Privileges for Specific Users".
- Derived from their team membership via "Privileges for Specific Teams".
- By default on the repository, via "Default Privileges".
- By default on the organization, via the org-wide "Default Object Privileges" (see org settings).
Now you've got the flexibility you need to create a repository with a common level of access for all organization members without compromising any other repository in the org.
We've Run The Numbers: API Improvements
We've just released several awesome improvements to our Entitlements and Metrics API endpoints in our quest to strive for API nirvana.
First up - at the request of many of our users, we now extended token lookup in the Entitlements API to resolve tokens by name and by token content. Historically users would have to make an API call to retrieve the Cloudsmith identifier of a token prior - but no more! Fewer calls, time saved, much happiness.
Next, our Metrics API. We've smoothed over the cracks here, bringing perfect 20/20 alignment to the Package Metrics API and the Entitlement Metrics API. Both these endpoints now provide bandwidth and downloads (and, of course, configurable with a timespan). Additionally, we now return a single dictionary response for these APIs instead of a list with a single dictionary.
This does mean there are some changes here that may alter your workflows. We've bumped the versions of our bindings and CLI to accommodate these improvements - a one and done way of getting these, for python:
pip install --upgrade cloudsmith_api cloudsmith_cli
Last (but by no means least) - we now support the ability to configure the visibility of the package statistics within a repository. Want to tighten access to administrators only in a valorous quest for privacy? We're here to help with that. This setting is now available in the Main Settings section of all repositories.
Happy Tuesday! <3 from the Cloudsmith Team.
Version Badges: Now with Even Shorter Lifespans
Good news! When you're embedding version badges elsewhere, you'll probably have noticed that services like GitHub like to cache them for an excruciatingly long time*, often well beyond the lifetime of the package version itself. That changes today, along with a stylish (yes, stylish, not just style) update:
Couple of things to note:
- The cache TTL (Time-To-Live) time has been reduced from 86400 seconds (1 day) to 300 seconds (5 mins).
- You can now generate badges for Docker images that have a version (non-hashref) assigned to them.
- The latest version badges will now show a "(latest)" prefix; you can turn this off via "show_latest=false".
- You can now customise the appearance of the badge (see below for more details).
- We'll now generate a (much) nicer "version not found" badge if a package or version isn't found.
Tweaking the badge appearance:
- Figure out how you want to tweak it by looking at the official shields attributes.
- Find the query string in the snippet (near the question mark), and add <attribute>=<value> to it.
- Don't forget to put an ampersand between your new value and the next part of the string.
For example, why not go for a wild and crazy alternative colour badge?
Finally: A huge thank you to shields.io for providing an amazing badge rendering service! \o/
Note*: This isn't actually GitHub's fault, our previous use of shields.io meant the Cache-Control header was always returning a max-age of 86400. So we migrated to shields.io newer JSON-based endpoint to fix it.