kosli-dev/cli

A CLI client for reporting compliance events to https://kosli.com

cli's Issues

Add --verbose option to dir:// protocol

Print detailed information on every file/dir name and content that contribute to the fingerprint calculation.
Make sure this information and its format is identical to merkely/change (which must also support this option).

Search bar in docs not working on staging site

This affects: https://staging-docs--kosli-docs.netlify.app/
The issue seems to be that the /search page does not exist on the staging site, so the action of the search form defaults to the current page.

2.8.9 release was not completed

👋 it looks like 2.8.9 release was not completed, ie the github release did not get created as 2.8.8, raise this issue for some awareness. Thanks!

relates to Homebrew/homebrew-core#169537

Docs example flag needs updating

In the new kosli attest artifact the documentation says
--git-commit yourCommitShaThatThisArtifactWasBuiltFrom \
but the flag is not part of the command
Error: unknown flag: --git-commit

The flag was renamed to --commit, but the example is outdated

Update docs page text for attest commands now attestations can be against a Trail

If I try the following command (from a working-directory that has a git repo):

kosli attest generic \
  --commit=$(git rev-parse HEAD) \
  --flow=${FLOW} \
  --trail=${TRAIL} \
  --name=wibble.fubar

then the command succeeds (it's the equivalent of the old report ... commit)

In this case, the attestation is, logically, against the Artifact:

• we are not providing a --fingerprint
• we are not providing an [IMAGE_NAME]--artifact-type
• we are providing --name=wibble.fubar.

So the wording:

If the attestation is attached to an artifact, the artifact SHA256 fingerprint is calculated (based on the --artifact-type flag) or can be provided directly (with the --fingerprint flag).

is not correct.

• Provide correct wording

As I see it, there are 4 "target" choices when attesting:

1. A Trail ; use only a dotted --name
2. An Artifact that does not yet exist ; use only dotted --name
3. An Artifact that does exist ; use --fingerprint (IMAGE_NAME not required)
4. An Artifact that does exist ; use --artifact-type (IMAGE_NAME required)

---

In the help for the flags:

• the --artifact-type flag is marked as [conditional] whereas

• the --fingerprint flag is marked as [optional]

• Is it clearer to say that both are now [conditional] (or [optional]) given that you can attest against a trail ?
  Most commands have an example of attesting against a trail (at the bottom of the page), and those commands have
  neither an --artifact-type nor a --fingerprint flag.

---

Some pages, eg kosli attest jira, say
The artifact SHA256 fingerprint is calculated (based on the --artifact-type flag) or can be provided directly (with the --fingerprint flag).

Other pages, eg kosli attest pullrequest github, say

If the attestation is attached to an artifact, The artifact SHA256 fingerprint is calculated (based on the --artifact-type flag) or can be provided directly (with the --fingerprint flag).

• Ensure attest command documentation is consistent

---

If I try the following command (from a working-directory that has a git repo)
which has no --fingerprint and no [IMAGE_NAME]--artifact-type

kosli attest generic \
  --flow=${FLOW} \
  --trail=${TRAIL} \
  --name=wibble.fubar

then the error I get is:
Error: an attestation targeting artifacts ['wibble'] requires at least one of: artifact_fingerprint or git_commit_info.

• Is this correct ?
• Should the commit-info be gathered automatically if the current working directiory is inside a git repo ?
• Should the diagnostic message be translated into the names of missing flags ?

Add parameter to specify the approver in an approval

Currently the approver for an approver is hard coded as External. I need to be able to specify the approver as a parameter e.g

kosli report approval $(cat output/tagged_image)
        --fingerprint=$(cat output/fingerprint)
        --description="Approved in Gitlab pipeline"
        --oldest-commit=origin/production
        --approver="${GITLAB_USER_NAME} <${GITLAB_USER_EMAIL}>"

Cannot calculate dir:// protocol digest due to file locking

In Frende meeting on 22/10/21 Hakon was unable to use the reporter to calculate digest/fingerprint for a directory because other processes had a file lock on one or more files in the directory.

missing cli documentation in report env command

When entering an env report <env-type> command in the CLI (ie: ./merkely environment report server), the help does not show like for other commands, instead the following error is returned: Error: environment name is required

make build should put kosli binary in sub-directory?

make build creates the binary in the current directory. Probably should put it into a build subdirectory.

Can --paths accept a space in the comma separated list of paths?

At the bottom of
https://docs.kosli.com/client_reference/kosli_environment_report_server/
There is this...

--paths a/b/c, e/f/g \

Is this right?
Or does it need to be

--paths a/b/c,e/f/g \

This also occurs at the bottom of
https://docs.kosli.com/how_to/record/

document whether CLI commands do or do not require a git repo to be present

I have briefly looked at this:

Any attest command (that is not attest-artifact) basically has three forms:

1. kosli attest junit --fingerprint=${fingerprint} --name=alpha.unit-test ...
2. kosli attest junit ARTIFACT_NAME --artifact-type=docker --name=alpha.unit-test ...
3. kosli attest junit --name=alpha.unit-test ...

Number 1 relies on their being a previous attest-artifact for the supplied fingerprint.

Number 2 also relies on their being a previous attest-artifact for the calculated fingerprint.

Number 3 relies on a git-commit to "commit-join" to a previous attest-artifact for that commit

The kosli-attest artifact command currently requires a git repo to be present.
Eg when you try a command like this, with --repo-root defaulting to . where there is no git repo:

kosli attest artifact ${FILENAME} --fingerprint=${FINGERPRINT} --name=alpha --build-url=https://a.b.c --commit-url=https://a.b.c

or like this

kosli attest artifact ${FILENNAME} --artifact-type=file --name=alpha --build-url=https://a.b.c --commit-url=https://a.b.c

You get the following error:
Error: failed to open git repository at .: repository does not exist

So, at present, it appears that all the kosli-attest command require, directly or indirectly, a git repo to be present

pipeline name missing in snapshot

when I use kosli env get command the pipeline is printed as N/A for an artifact that we actually have a provenance of (for 'compliancedb' org):

$ kosli env get prod-aws
COMMIT   ARTIFACT                                                                       PIPELINE  RUNNING_SINCE  REPLICAS
N/A      Name: 358426185766.dkr.ecr.eu-central-1.amazonaws.com/adot:v0.21.0             N/A       12 days ago    1
         Fingerprint: 8cbf709ad4c4eb3d5edcd33a806b9d2903d48945a897047c6ab184d2445dd6c3                           
                                                                                                                 
3051844  Name: 358426185766.dkr.ecr.eu-central-1.amazonaws.com/merkely:3051844          N/A       12 days ago    1
         Fingerprint: 5485d80e21b760b0257c5cd837bc2ac6bebcf0cb625d3e9e95812358e2bffb79                           
                                                                                                                 
$ kosli artifact get merkely@5485d80e21b760b0257c5cd837bc2ac6bebcf0cb625d3e9e95812358e2bffb79
Name:                      772819027869.dkr.ecr.eu-central-1.amazonaws.com/merkely:3051844
Pipeline:                  merkely
Fingerprint:               5485d80e21b760b0257c5cd837bc2ac6bebcf0cb625d3e9e95812358e2bffb79
Created on:                Thu, 03 Nov 2022 10:35:22 CET • 12 days ago
Git commit:                305184489c866e5d71def6aa6fe517e8bcbcc9ff
Commit URL:                https://github.com/kosli-dev/server/commit/305184489c866e5d71def6aa6fe517e8bcbcc9ff
Build URL:                 https://github.com/kosli-dev/server/actions/runs/3384506568
State:                     COMPLIANT
Running in environments:   dnb-aws#250, modulr#142, prod-aws#297, stacc#257
Exited from environments:  azure-staging-aws#1822, staging-aws#2274
History:
    Artifact created                                         Thu, 03 Nov 2022 10:35:22 CET
    unit-test evidence received                              Thu, 03 Nov 2022 10:36:48 CET
    unit-test-coverage evidence received                     Thu, 03 Nov 2022 10:36:49 CET
    integration-test evidence received                       Thu, 03 Nov 2022 10:37:21 CET
    integration-test-coverage evidence received              Thu, 03 Nov 2022 10:37:22 CET
    Deployment #5433 to staging-aws environment              Thu, 03 Nov 2022 10:38:34 CET
    Deployment #5434 to azure-staging-aws environment        Thu, 03 Nov 2022 10:38:43 CET
    Started running in staging-aws#2273 environment          Thu, 03 Nov 2022 10:40:22 CET
    Started running in azure-staging-aws#1820 environment    Thu, 03 Nov 2022 10:40:24 CET
    Deployment #5435 to modulr environment                   Thu, 03 Nov 2022 10:43:41 CET
    Deployment #5436 to dnb-aws environment                  Thu, 03 Nov 2022 10:43:44 CET
    Deployment #5437 to stacc environment                    Thu, 03 Nov 2022 10:43:45 CET
    Approval #280 created                                    Thu, 03 Nov 2022 10:43:46 CET
    Approval #280 approved by external://External            Thu, 03 Nov 2022 10:43:46 CET
    Deployment #5438 to prod-aws environment                 Thu, 03 Nov 2022 10:43:47 CET
    Started running in prod-aws#297 environment              Thu, 03 Nov 2022 10:44:56 CET
    Started running in dnb-aws#250 environment               Thu, 03 Nov 2022 10:45:38 CET
    Started running in stacc#257 environment                 Thu, 03 Nov 2022 10:45:45 CET
    Started running in modulr#142 environment                Thu, 03 Nov 2022 10:45:45 CET
    No longer running in staging-aws#2274 environment        Thu, 03 Nov 2022 12:00:22 CET
    No longer running in azure-staging-aws#1822 environment  Thu, 03 Nov 2022 12:00:24 CET

Kosli concepts on docs.kosli.com

Describe organizations, environments, pipelines
plus any additional pages that we may need to make Kosli easier to understand for newcomers

styling footer at docs.kosli.com

• footer needs to stick to the bottom of the page no matter the length
• width of the footer needs to match figma desgin

additional stuff discovered on the way

• table of content header + styling needs to match figma design
• docs home page ruined by fixing above issues - FIX BEFORE PUSHING
• verify/fix how it looks on mobile
• docs home page grid (8 icons with links) need rework so it works better/more consistent

Use cucumber/ci-environment to handle multiple CI environments

Describe the issue
We have to support multiple different CI environments for CLI reporting. We are currently hand crafting this each time.

The Cucumber team have an open source library that does a similar thing: https://github.com/cucumber/ci-environment

This has support for multiple languages including Go.

We might want to fork or extend it for our usecase.

update helm chart

we're still using old (1.5.9) version of cli in helm chart, time to update

can we make it always latest? does it even make sense?

AWS authentication different for reporting ecs and lambda

reporting ecs requires environment variables, reporting lambda requires environment variables OR flags - can we unify?

help for ecs:

[...]
Examples:

# report what is running in an entire AWS ECS cluster:
export AWS_REGION=yourAWSRegion
export AWS_ACCESS_KEY_ID=yourAWSAccessKeyID
export AWS_SECRET_ACCESS_KEY=yourAWSSecretAccessKey

kosli environment report ecs yourEnvironmentName \
	--api-token yourAPIToken \
	--owner yourOrgName


Flags:
  -C, --cluster string        The name of the ECS cluster.
  -h, --help                  help for ecs
  -s, --service-name string   The name of the ECS service.

Global Flags:
  -a, --api-token string      The Kosli API token.
  -c, --config-file string    [optional] The Kosli config file path. (default "kosli")
  -D, --dry-run               [optional] Whether to run in dry-run mode. When enabled, data is not sent to Kosli and the CLI exits with 0 exit code regardless of errors.
  -H, --host string           [defaulted] The Kosli endpoint. (default "https://app.kosli.com")
  -r, --max-api-retries int   [defaulted] How many times should API calls be retried when the API host is not reachable. (default 3)
      --owner string          The Kosli user or organization.
  -v, --verbose               [optional] Print verbose logs to stdout.

help for lambda:

[...]
Examples:

# report what is running in the latest version AWS Lambda function (AWS auth provided in env variables):
export AWS_REGION=yourAWSRegion
export AWS_ACCESS_KEY_ID=yourAWSAccessKeyID
export AWS_SECRET_ACCESS_KEY=yourAWSSecretAccessKey

kosli environment report lambda myEnvironment \
	--function-name yourFunctionName \
	--api-token yourAPIToken \
	--owner yourOrgName

# report what is running in a specific version of an AWS Lambda function (AWS auth provided in flags):
kosli environment report lambda myEnvironment \
	--function-name yourFunctionName \
	--function-version yourFunctionVersion \
	--aws-key-id yourAWSAccessKeyID \
	--aws-secret-key yourAWSSecretAccessKey \
	--aws-region yourAWSRegion \
	--api-token yourAPIToken \
	--owner yourOrgName


Flags:
      --aws-key-id string         The AWS access key ID.
      --aws-region string         The AWS region.
      --aws-secret-key string     The AWS secret key.
      --function-name string      The name of the AWS Lambda function.
      --function-version string   [optional] The version of the AWS Lambda function.
  -h, --help                      help for lambda

Global Flags:
  -a, --api-token string      The Kosli API token.
  -c, --config-file string    [optional] The Kosli config file path. (default "kosli")
  -D, --dry-run               [optional] Whether to run in dry-run mode. When enabled, data is not sent to Kosli and the CLI exits with 0 exit code regardless of errors.
  -H, --host string           [defaulted] The Kosli endpoint. (default "https://app.kosli.com")
  -r, --max-api-retries int   [defaulted] How many times should API calls be retried when the API host is not reachable. (default 3)
      --owner string          The Kosli user or organization.
  -v, --verbose               [optional] Print verbose logs to stdout.

Daily snyk-scan of server failing with null-pointer dereference

Our daily snyk scan of the server is failing with this...

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xa9ed38]

See https://github.com/kosli-dev/server/actions/runs/8567365373/job/23479015177#step:7:44
Looks like it is the same kind of error we've seen before, involving the CLI and json decoding.

Add 'list trails' command to CLI

There is currently no kosli list trails command.
Logically, I think there should be.

Small PR to fix non-deterministic output in CLI

The PR is https://github.com/kosli-dev/cli/tree/print-tags-in-sorted-order
It fails because, it says, the % coverage has gone down.
I cannot see why.
I vaguely recall Sami having a way to fix this but he is off and there is no help in the cli readme.

Better command identification when CLI command fails

The cyber-dojo live-snyk-scans run a script which attests the result of each snyk scan twice, once for the Trail representing the live-snyk-scan, and once more for the original Trail that built the Artifact

snyk container test ...
kosli attest snyk ...
kosli attest snyk ...

Several times I have got an error in one of the kosli attest snyk commands and it is very difficult to tell which attest-snyk command is failing (this is in a script remember). It is sufficiently tricky that I now do a set +e/set -e around the attest-snyk command and do my own error reporting.
See https://github.com/cyber-dojo/live-snyk-scans/blob/7b967a8dd6140a5b987a22d9673cad8b37fd656b/snyk_scan_live_artifacts_and_attest_to_kosli.sh#L120

It would be good, when a CLI command fails, if it could print the command, the Flow, and the Trail, as well as the diagnostic.

Small bugs in CLI doc text for kosli fingerprint

The text for the kosli fingerprint command has a few small bugs...

1. The text for the --artifact-type flag reads

-t, --artifact-type string | [conditional] The type of the artifact to calculate its SHA256 fingerprint. 
One of: [docker, file, dir]. Only required if you don't specify '--fingerprint'.

This is the correct text for a general attest command, but for the kosli fingerprint command the --artifact-type flag is required.

2. The text in the Synopsis reads

When fingerprinting a 'dir' artifact, you can exclude certain paths from fingerprint calculation using the
--exclude flag. Excluded paths are relative to the artifact path(s) and can be literal paths or glob patterns.

I think this would be slightly better as:

When fingerprinting a 'dir' artifact, you can exclude certain paths from the fingerprint calculation using the 
--exclude flag. Excluded paths are relative to the DIR-PATH and can be literal paths or glob patterns.

3. There are no examples.

Add missing [default] to flag in docs

In https://docs.kosli.com/client_reference/kosli_pipeline_approval_request/#synopsis
the entry for --repo-root is missing its leading [default]

2.8.8 release was not completed

👋 it looks like 2.8.8 release was not completed, ie the latest release did not get created. Raise this issue for some awareness. Thanks!

relates to Homebrew/homebrew-core#167117