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.
New Terms of Service: Effective 19th May 2021
Not your usual feature update, but we'll be updating our Terms of Service, effective 19th May 2021*:
For all individual users, the following terms will apply, both replacing the existing terms:
For all organisations and organisation users, the following terms will apply, extending the above terms:
We realise this is a grand undertaking, but please ensure that you read these terms carefully, as with all legal documentation. If you disagree with the content, you'll need to cancel your individual or organisation accounts; but we really hope that won't be necessary, as we'll explain next.
This is a complete revamp of our primary legal agreements between us (Cloudsmith) and you (the Users and Organisations) that we provide a service for. The intention was to finally bring all of these up to the expected level of privacy and security standards required for a service such as ours.
So some things in short to note:
- Our mission is to "Be Good, Do Good" and ensure that this influences all aspects of our policies.
- When engaging our lawyers, we asked them to ensure that the new terms didn't diminish the material rights of our users (that's You); therefore, no introductions of sneaky "gotcha" clauses.
- We paid particular attention to GDPR requirements, in addition to CCPA policy, to ensure that we're adequately articulating what personally identifiable information we're processing and why.
- We also wanted you to recognise the particular attention we pay to securing the service and keeping your private information. You've chosen it to be hidden from the public domain.
- We will absolutely never-ever resort to selling any level of your information. Much of our information required is related to either provision of the service or improving our service, for you.
- We occasionally like to send people marketing material, but only if they request it. We also pay particular attention to the rights to be forgotten and about allowing an "easy exit" if you need one.
The bottom line is: Your privacy and security are important. We care, and we want you to know that we do.
If you have absolutely any concerns at all, please let us know immediately. We'll be happy to discuss!
* Note: The terms are effective immediately for new users and new organisations.
Loggin' Hysteria: Login History
More account-based good news! We've surfaced the history of logins for your account:
You can find the new information on your account security page, underneath the Session Management, as described previously. In addition to seeing the current sessions, the historical view of logins includes context such as the login method, Geo/IP location and details about the browser, operating system and device that logged into and accessed your account. You can hover over the data for additional details.
Let us know if you've got any feedback or if you like the new feature. Enjoy!
Note: The login history only extends to your first login from the release of this feature today, but we'll keep track of and display the history for up to and including the 50 most recent logins.
A Wild Sesh: Session Management Controls
Good news! Take back some control and easily manage logged-in sessions for your account:
You can find the new controls on your account security page, along with some context for the session, such as when the session was last active, the Geo/IP location, and details about the browser, operating system and device that logged into and accessed your account. You can hover over the data for additional details.
These will give you extra insight into where the sessions occurred and perhaps by whom. If you don't recognise a session, or you want to end one remotely, you can utilise the Logout Other Sessions button to terminate them quickly. Now you can sleep with peace of mind, perhaps after changing your password.
You may also notice another section, but we'll talk more about that tomorrow. :-)
Until then, let us know if you've got any feedback or if you like the new feature. Enjoy!
Now Testing: Access Log Exports to S3
We're now rolling out Early Access to the "Access Log Exports to S3" feature:
With our automated S3 export, you'll be able to get the access logs for your repositories delivered to you periodically. You pick the frequency and the output format, and we'll make the drop hassle-free. You can then import your logs into your favourite Business Intelligence tools to slice dice and analyse your data at scale.
The exports are available in three flavours (formats), from least to most verbose:
- Apache-style: Logs in the "Apache-style" (i.e. web server) format, with the bare essentials for tracking.
- CSV: Comma-Separated Values, with a header line to indicate the available fields.
- JSON (Single): Detailed records as an array in a single JSON object, with additional header fields.
- JSON (Stream): As above, but newline-delimited records and no header, as described on ndjson.org.
- JSON (Stream+TS): As above, but each line contains a timestamped prefix, for tools like SumoLogic.
You'll be able to authenticate to your S3 logs bucket with least-privilege permissions via either Role Assumption to Pre-Shared Keys; that means we only need to write, but not read, the access logs.
We're configuring the exports to be once-per-day for the testing period, but beyond that, we'll be offering different configurable frequencies, such as once-per-month, once-per-week, once-per-hour, etc.
Sound like something you'd be interested in? Please contact us to get exporting today!
Note: This feature is available to Ultra-tier customers, but we'd be happy to let anyone try before committing. Also, with this release, we've removed the deprecated feature of generating raw access logs via the UI, due to performance reasons. The replacement coming up is a Downloads API in the near future.
John Hancocks at the Ready: Signatures for All
Cloudsmith has always performed signature and checksum validation at the core of the service - and today, we're introducing three awesome new ways to surface this information!
User Interface
The package information page now includes a link to retrieve the raw GPG signature for a package, using all of the same authentication schemes we support for packages.
Packages API
The package resource in the Cloudsmith API now provides a URL to retrieve the raw signature for a package and package file via the attribute signature_url.
Raw Format Indexes / URLs
Last (but by no means least) - our raw format has been updated to provide signature URLs on both our HTML and JSON indexes (where enabled within your repository). You can also append .asc to any raw file URL to retrieve the package signature directly.
These changes (and more upcoming) aim to give more visibility into the provenance of your software.