Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Inspec profiles #3634

Closed
micheelengronne opened this issue May 3, 2019 · 15 comments
Closed

Support Inspec profiles #3634

micheelengronne opened this issue May 3, 2019 · 15 comments

Comments

@micheelengronne
Copy link

I would like to be able to handle my inspec profiles dependencies with renovate.

Inspec https://www.inspec.io/ is an evolution of serverspec to test systems and infrastructures.

It has a packaging system. A package is called a profile in the Inspec world.

An Inspec profile can have dependencies and a lock file.

I would like to fetch profiles from chef repositories, custom repositories and git repositories.

Thanks.

@rarkins rarkins added type:feature Feature (new functionality) new package manager New package manager support priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others ready help wanted Help is needed or welcomed on this issue and removed ready labels May 16, 2019
@rarkins
Copy link
Collaborator

rarkins commented May 16, 2019

For new package managers we generally approach the problem in 3 steps:

  1. Is a new datasource required?

  2. Is a new version scheme required (e.g. vanilla semver is not supported)

  3. Add extract and update functions

So to start with, can you provide an example profile that includes references to chef, custom and git repositories?

@micheelengronne
Copy link
Author

Inspec itself includes examples for its tests: https://github.com/inspec/inspec/tree/master/examples

With the meta profile, you have supermarket, git and url dependencies: https://github.com/inspec/inspec/tree/master/examples/meta-profile

With the inheritance profile, you have local dependencies:
https://github.com/inspec/inspec/tree/master/examples/inheritance

As far as I know, the only place (except the git tag and tar.gz artifact) where I see a version number is the version field in inspec.yml

Inspec also creates an inspec.lock file with the command inspec vendor with the --overwrite attribute to change the existing lock file.

@rarkins
Copy link
Collaborator

rarkins commented May 16, 2019

Can you point me to specific lines/sections of the files in the example tests? It's too complex for me to grok immediately. Specifically I'm looking for the types of references that you'd expect Renovate to update.

@micheelengronne
Copy link
Author

micheelengronne commented May 16, 2019

These examples do not keep their inspec.lock files so I generated them with inspec vendor:

For the meta-profile https://github.com/inspec/inspec/tree/master/examples/meta-profile:

---
lockfile_version: 1
depends:
- name: dev-sec/ssh-baseline
  resolved_source:
    url: https://github.com/dev-sec/ssh-baseline/archive/master.tar.gz
    sha256: 880d952f8bcaeb548e4f2aa798d4bfad0b35e0afad0f0a4d8e98ce474ae19f8a
  version_constraints: []
- name: ssl-baseline
  resolved_source:
    url: https://github.com/dev-sec/ssl-baseline/archive/master.tar.gz
    sha256: cf43acbe903f9fff832e0a1cb62ac5db19f2d92586c4eb9871e323207d673b35
  version_constraints: []
- name: windows-patch-benchmark
  resolved_source:
    url: https://github.com/chris-rock/windows-patch-benchmark/archive/master.tar.gz
    sha256: c96dcf60b60de709831000a253427116012dbb9c8b1958f5cd2f90e1abb68410
  version_constraints: []

For the inheritance profile https://github.com/inspec/inspec/tree/master/examples/inheritance:

---
lockfile_version: 1
depends:
- name: profile
  resolved_source:
    path: "/usr/local/src/inspec/examples/profile"
    sha256: 71d1cded626231c4cdf171fb7ecb0ccafe4ef5c0cbe55ee8fe055aa48947f7e1
  version_constraints: []
- name: profile-attribute
  resolved_source:
    path: "/usr/local/src/inspec/examples/profile-attribute"
    sha256: b321127d15ac031588575b4bbac140739b6238d187657659d82ea131cb9ea498
  version_constraints: []

As you can see in this other profile the version appears in the version field and is equivalent to a git tag:
https://github.com/dev-sec/linux-baseline/blob/master/inspec.yml

@micheelengronne
Copy link
Author

micheelengronne commented May 16, 2019

To improve further, I altered the meta-profile with the following inspec.yml:

name: meta-profile
title: Meta Compliance Profile
maintainer: InSpec Authors
copyright: InSpec Authors
copyright_email: [email protected]
license: Apache-2.0
summary: InSpec Profile that is only consuming dependencies
version: 0.2.0
depends:
  - name: dev-sec/ssh-baseline
    git: https://github.com/dev-sec/ssh-baseline
    version: 2.4.1

Notice that it uses a git dependency with a version constraint.
The resulting inspec.lock is:

---
lockfile_version: 1
depends:
- name: dev-sec/ssh-baseline
  resolved_source:
    git: https://github.com/dev-sec/ssh-baseline
    ref: 6625de7fd1bc9379f2a16d77051727354ecff28d
  version_constraints:
  - 2.4.1

The version constraint is reported in the lock

@rarkins
Copy link
Collaborator

rarkins commented May 16, 2019

By the way, in order of difficulty for us:

  • 1.0.0 -> 1.0.1 (easy)
  • 1 -> 1.0.1 (harder)
  • "" -> 1.0.0 (hardest)

Right now we don't do the third one for many managers at all. e.g. if you configure an npm dependency to have version "*" then we leave it alone and do not pin it. Same with Docker images.

So in terms of implementation I would aim to first support simple updating of versions in Inspec (e.g. 1.0.0 -> 1.0.1) and then pinning of versions (assuming ranges are supported) and then finally going from no version to a pinned version.

We'd also have to decide if we call "updating from no version to an exact version" to be "pinning" or if we need a new term to differentiate it

@micheelengronne
Copy link
Author

I don't know if ranges are supported and if "pinning" is the correct term.

I am not a member of the Inspec team. I think, we should work with them.

@aaronlippold @skpaterson and @chef your thoughts on that ?

@skpaterson
Copy link

hi @micheelengronne and @rarkins - apologies for the delay in responding. Adding InSpec support in Renovate looks interesting, I'll mention to our product folks this side. Vendoring effectively pins all profile dependencies. As far as I'm aware we cannot currently specify ranges of profile versions. For info, there's more detail here on InSpec profiles and versioning: https://www.inspec.io/docs/reference/profiles/

@micheelengronne
Copy link
Author

With the custom manager, it is possible to handle dependencies. What is missing though are datasources.

Inspec dependencies can be stored on a local path, an url, supermarket and chef compliance server. See https://www.inspec.io/docs/reference/profiles/

@micheelengronne
Copy link
Author

I think, we can handle the lock update indirectly if the custom script feature is implemented.

#5004

@micheelengronne
Copy link
Author

It seems that #5202 can fulfill my usecase. I will try it.

@tbugfinder
Copy link
Contributor

Hi @micheelengronne , how did you implement the update of inspec.yml?

@micheelengronne
Copy link
Author

Hi @tbugfinder, I added my deps that way in inspec.yml:

    - name: linux-baseline
      git: https://github.com/dev-sec/linux-baseline.git
      # yamllint disable-line rule:line-length
      # source: https://github.com/dev-sec/linux-baseline.git name: linux-baseline
      tag: 2.4.6

And in renovate config:

  "regexManagers": [
    {
      "fileMatch": ["^inspec.yml$"],
      "matchStrings": [
        "# source: (?<lookupName>.*)? name: (?<depName>.*)?\n    tag: (?<currentValue>.*)"
      ],
      "datasourceTemplate": "git-tags"
    }
  ],

@tbugfinder
Copy link
Contributor

Excellent. Thank you

@rarkins rarkins added the status:requirements Full requirements are not yet known, so implementation should not be started label Jan 12, 2021
@rarkins rarkins added new package manager New package manager support and removed new package manager New package manager support labels May 13, 2023
@github-actions
Copy link
Contributor

Hi there,

You're asking us to support a new package manager. We need to know some basic information about this package manager first. Please copy/paste the new package manager questionnaire, and fill it out in full.

Once the questionnaire is filled out we'll decide if we want to support this new manager.

Good luck,

The Renovate team

@rarkins rarkins added priority-4-low Low priority, unlikely to be done unless it becomes important to more people and removed priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality) help wanted Help is needed or welcomed on this issue labels Oct 1, 2023
@rarkins rarkins removed priority-4-low Low priority, unlikely to be done unless it becomes important to more people new package manager New package manager support status:requirements Full requirements are not yet known, so implementation should not be started labels Oct 1, 2023
@renovatebot renovatebot locked and limited conversation to collaborators Oct 1, 2023
@rarkins rarkins converted this issue into discussion #24724 Oct 1, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants