Skip to content

Latest commit

 

History

History
567 lines (430 loc) · 42.3 KB

CHANGELOG.md

File metadata and controls

567 lines (430 loc) · 42.3 KB
Raw

Hipcheck Changelog

All notable changes to this project will be documented in this file. This project adheres to Semantic Versioning.

3.6.2 - 2024-09-10

This is a small release to fix a bug in the release automation for 3.6.1. For more information on the key content for this release, check out 3.6.1.

Huge thanks to Ashley and the rest of the Axo team for their quick action to figure out this bug and get a workaround implemented!

Fixed

New Contributors

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.6.1...hipcheck-v3.6.2

3.6.1 - 2024-09-09

3.6.1 is a patch release, but it features one exciting new, still-experimental feature: support for plugins! Previously, if you wanted to add a new source of data or a new form of analsis to Hipcheck, you needed to modify Hipcheck itself. This placed some limitations on our ability to grow Hipcheck, and more importantly it conflicted with a core design philosophy of Hipcheck: that it should empower uses to express their policies about using open source software (this is one of our Product Values, as expressed in RFD #2).

With 3.6.1 users can now define custom plugins to provide new sources of data and new analyses. There's a lot more for us to do with this, including a lot of user experience polish, releasing our first SDK to make developing plugins easier, creating and publishing documentation on how to create, distribute, and use plugins, and more! For now though, this launch is our official starting point where users can create, distribute, and run plugins.

For more details on the design of the new plugin system, check out RFD #4. If you have questions on how to work with plugins, you can always ask us in our GitHub Discussions forum!

Completion of the Plugin Minimum Viable Product

Automation Fixes & Improvements

Dependency Version Bumps

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.6.0...hipcheck-v3.6.1

3.6.0 - 2024-08-30

This is a relatively small release, as we work on the initial implementation of our new plugin system as described in RFD #4.

There are two fixes in this release:

Plus lots of work on implementing plugins (not yet ready for use):

Some improvements to the website and to CI testing:

Refactoring of the Hipcheck source code:

Updates to our release infrastructure:

And finally, many dependency version bumps:

New Contributors

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.5.0...hipcheck-v3.6.0

3.5.0 - 2024-08-05

Hipcheck 3.5.0 continues our focus on user experience improvements with three major additions:

  • Improved target selection
  • The hc cache subcommand
  • Better progress reporting

Improved Target Selection

In Hipcheck 3.5.0 we've enhanced the ability to specify your target of analysis. This is Hipcheck's term for "the thing you want to analyze." With this new version, you can now provide:

  • Package URLs (pURLs): pURLs are a specification for a unified way of referencing packages on a variety of popular package hosts. For example, the pURL pkg:npm/foobar@12.3.1 refers to the package foobar version 12.3.1 on NPM.
  • VCS URLs: VCS URLs come from the Python ecoystem, where they're used by PIP to refer to Git repositories with additional metadata embedded in the URL. They're also used by the SPDX Software Bill of Materials standard. A VCS URL looks like git+ssh://git@git.example.com/MyProject, with the VCS being used as a prefix to the rest of the protocol, separated by a +.
  • Git References: References are how Git refers to specific things you can checkout in a Git repository, including specific commits, branches, and tags. By default, Hipcheck checks out the latest (HEAD) commit of a repository, but you can now use the --ref flag to specify a different ref to check out.
  • CycloneDX SBOMs: Hipcheck can now accept CycloneDX Software Bills of Material in addition to SPDX ones, in either JSON or XML format.

Note that some of the methods above allow embedding some target-type information directly, in ways that can contradict the --type flag when running hc check. If the --type flag and the target specifier metadata ever conflict, Hipcheck will produce an error rather than picking one option over the other automatically.

The following commits were for this work:

  • remove use of Source, SourceRepo, Remote structs in favor of Target by @j-lanson in #229
  • added types for new target repo spec and resolution by @j-lanson in #210
  • add more robust 'target resolution' systemD by @mchernicoff in #227
  • add --ref support to remaining target seed kinds by @j-lanson in #244
  • CLI can infer target type from target pURL by @mchernicoff in #205
  • CLI can infer target type from target VCS URL by @mchernicoff in #209
  • Hipcheck can process SBOMs using CycloneDX (currently JSON only) standard by @mchernicoff in #237
  • Hipcheck can process SBOMs using CycloneDX XML files by @mchernicoff in #239
  • update remote-repo updating to support git refs by @j-lanson in #240
  • update local-repo copying to support git refs by @j-lanson in #242
  • distinguish TargetSeed and TargetSeedKind to transfer ref info from cli by @j-lanson in #243

hc cache subcommand

We've also added a new subcommand, hc cache, for managing the repository cache that Hipcheck maintains. When Hipcheck runs, it creates a local clone of the repository being analyzed (if the repository is already local, Hipcheck still clones it into the repository cache to avoid mutating the original). Over time, this repository cache will grow, and some repositories may be quite large. The new hc cache subcommand lets the user see what's in the cache with hc cache list, and delete elements in the cache with hc cache delete.

The following commits were for this work:

  • add hc cache subcommand for manually listing/deleting elements of the cache by @j-lanson in #224
  • add commit info to hc cache display and index file by @j-lanson in #245
  • local repos are also cloned to HC_CACHE by @j-lanson in #208
  • shortcut cache entry size calculation with cache index file by @j-lanson in #236

Progress Reporting

Hipcheck now shows a progress bar during execution, especially during repository cloning, which can be quite slow for larger repositories. This is intended to make it clearer how Hipcheck's time is being spent, and went it's continuing to make progress vs. being stuck.

The following commits were for this work:

  • major refactor to enable better control of phases and progress bars by @vcfxb in #198
  • Variety of tweaks to the shell and phase infrastructure by @vcfxb in #213
  • Add progress bars when cloning repos (powered by the git2 crate). Integrate libgit2 trace messages into our logging by @vcfxb in #222

And More...

As always, there are more changes in a single version that can be adequately described here. View the full changelog to see the rest:

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.4.0...hipcheck-v3.5.0

3.4.0 - 2024-07-04

Hipcheck 3.4.0 is an exciting release featuring 3 new subcommands!

  • hc setup: When you install the hc binary, whether through an install script with a release, with cargo binstall, or by building it yourself, you still need to get the configuration and data files Hipcheck requires. This new command gets those files for you, so you can start using Hipcheck quickly and easily!
  • hc update: This lets Hipcheck update itself to newer versions! Under the hood, we're using the self-updater built and provided by cargo-dist, the tool we use for cutting new releases with prebuilt binaries. The hc update command is a wrapper around that updater. This command does require that you use our install script to get the self-updater.
  • hc scoring: This tells you how Hipcheck is scoring results based on your current configuration. While you can see the weights for each analysis in your configuration file, it can be tedious to do the math yourself to find out exactly how much each analysis contributes to the overall score. This command does that math for you to make it easier.

Hipcheck also now has an official website! Feel free to check it out, and let us know if you encounter any issues with it.

Added

  • Add new hc setup command:
  • Add new hc update command:
    • Adds hc update command to run the self-updater (if installed) to automatically bring Hipcheck up to date with a released version. Includes optional flags to update to versions other than the latest by @mchernicoff in #176
  • Add new hc scoring command:

Changed

Fixed

  • Fix broken Docker build:
    • Vendor libgit2 and openssl so that hipcheck builds in containers more consistently by @vcfxb in #177

Removed

  • Remove legacy CLI features that aren't actually implemented or supported:
    • Removes patch type as option for hc check or hc schema, as that was unsupported by @mchernicoff in #153
    • Remove pr analysis and scoring infrastructure by @j-lanson in #158

New Contributors

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.3.2...hipcheck-v3.4.0

3.3.2 - 2024-06-21

This patch is intended to workaround a bug in cargo-dist which caused the publication of 3.3.1 to fail to include all the expected artifacts. They're working on fixing the bug, but in the short term this is a reasonable workaround.

Changed

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.3.1...hipcheck-v3.3.2

3.3.1 - 2024-06-21

This patch release includes two general categories of fixes:

  • Getting Containerfile builds on new releases working.
  • Getting cargo-dist generation of binaries on new releases working.

Changed

Fixed

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.3.0...hipcheck-v3.3.1

3.3.0 - 2024-06-20

Hipcheck version 3.3.0 is mostly focused on refactors and internal improvements, including a substantial refactor of the hc Command Line Interface to be easier to use and easier for us to enhance in the future. We've also continued to mature our tooling and processes around Hipcheck, which should hopefully make future advancement easier.

RFDs

hc

Continuous Integration Workflows

  • Filter GitHub workflow to not run tests if changes to a push or pull-request are outside of code folders by @mchernicoff in #68
  • Add "Dependency Tree" task to CI by @alilleybrinker in #79
  • Publish tagged HC releases to Dockerhub by @j-lanson in #113
  • Add ability to manually exec push-to-dockerhub action by @j-lanson in #119

xtask

xtask is our internal development tooling.

  • Add license and description xtask/src/task/rfd.rs by @mchernicoff in #90
  • Add xtask changelog sanity check for git-cliff by @j-lanson in #92
  • Change xtask validate to xtask check when xtask ci is called by @mchernicoff in #89

Other Project Tooling

Dependency Version Bumps

New Contributors

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.2.1...hipcheck-v3.3.0

3.2.1 - 2024-05-10

Nothing really new in Hipcheck itself. Publishing this version mostly to work out issues with the machinery for publishing new releases and distributing prebuilt binaries.

Added

Changed

Fixed

Full Changelog: https://github.com/mitre/hipcheck/compare/hipcheck-v3.2.0...hipcheck-v3.3.0

3.2.0 - 2024-05-09

This is the first new version of Hipcheck since our initial open source release, and it represents a lot of housekeeping to get the project up and running! That includes:

  • Getting Hipcheck compiling cleanly on the latest stable version of Rust.
  • Getting all of Hipcheck's dependencies up to date.
  • Shrinking Hipcheck's crate structure down to just a single binary crate.

In addition, we worked on a lot of best-practice related items, including:

  • Defining RFD's (Requests for Discussion) as our means of managing the evolution of Hipcheck over time.
  • Setting up a DevContainer configuration, for folks who'd like to contribute to Hipcheck without needing to set up their local environment by hand.
  • Establishing Continuous Integration testing, to increase confidence in the correctness of future changes we may merge.
  • Defining a security policy, a code of conduct, and a guide for potential contributors, so people know how to interact with the project.
  • Defining our "Release Engineering" practices, which will help smooth out the flow of future releases of Hipcheck.

Up next we're planning to work on more serious redesigning of Hipcheck's architecture to support third-party plugins for data and analysis. If that's something that appeals to you, please let us know in the Discussions page!

Here's to the first of many more releases!

Changed

Fixed

New Contributors