Skip to content
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

in-toto-golang does not provide defaults for excluding artifacts #207

Open
anotherbridge opened this issue Feb 17, 2023 · 7 comments
Open
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@anotherbridge
Copy link

anotherbridge commented Feb 17, 2023

Note: this has been edited by @adityasaky to capture the underlying issue. The original issue filed by @anotherbridge is below.

General information:

in-toto-golang does not provide a default set of patterns to exclude like the Python reference implementation. See: https://github.com/in-toto/in-toto/blob/fbc1eb053dd39c6d1fb307a60bd2c781e667c931/in_toto/settings.py#L39

This causes some differences in behaviour when using this implementation instead of the reference implementation. This difference can be observed when using in-toto-golang with in-toto/demo during its untar inspection. The go implementation does not automatically exclude the link metadata stored in final_product for the steps performed thus far.

Current behaviour:

No defaults for artifact excludes.

Expected behaviour:

Same defaults for artifact excludes as the Python reference implementation.


Original Issue

General information:

I did compare the Python and Golang versions of the in-toto-framework. In order to do so I followed the demo-project.
During the verifification step the golang version seemed to have generated a corrupt untar.link file.

  • Version (tag or commit): checked out repo at state of commit 82bb771
  • Operating system (Linux/Mac/Windows): macOS Ventura (ARM architecture)
  • Go version: go version go1.19.6
  • Go build flags (if any):

Description of the bug:

When building the in-toto binary I ran:

make build 
make test

According to the output all the tests seemed to be successful. Then I followed all the steps described in the demo project. All steps worked as expected when using the in-toto Golang version (denoted as in-toto-golang) until the point of verification. When running the verification step something interesting happened:

  1. Running it it with in the Python version in-toto-verify --layout root.layout --layout-key alice.pub resulted in a success and return status 0.
  2. Then running the go version in-toto-golang verify --layout root.layout --layout-keys alice.pub resulted in the following output:
inspection failed: artifact verification failed for Inspection 'untar', materials [clone.776a00e2.link package.2f89b927.link untar.link demo-project/foo.py update-version.776a00e2.link] disallowed by rule [DISALLOW *]
  1. After that I tried running the verification of the python version (with the same untar.link as generated by the go version) again and got the following result back:
(in-toto-verify) RuleVerificationError: 'DISALLOW *' matched the following artifacts: ['demo-project/foo.py']
Full trace for 'expected_materials' of item 'untar':
Available materials (used for queue):
['.keep', 'alice.pub', 'demo-project.tar.gz', 'root.layout', 'demo-project/foo.py']
Available products:
['.keep', 'alice.pub', 'demo-project.tar.gz', 'root.layout', 'demo-project/foo.py']
Queue after 'MATCH demo-project.tar.gz WITH PRODUCTS FROM package':
['root.layout', '.keep', 'alice.pub', 'demo-project/foo.py']
Queue after 'ALLOW .keep':
['root.layout', 'alice.pub', 'demo-project/foo.py']
Queue after 'ALLOW alice.pub':
['root.layout', 'demo-project/foo.py']
Queue after 'ALLOW root.layout':
['demo-project/foo.py']

The two versions of the untar.link file are given as follows:
Golang
Python

P.S. I had to add a .txt extension to both of the files, since GitHub wouldn't let me upload them otherwise.

@anotherbridge anotherbridge added the bug Something isn't working label Feb 17, 2023
@adityasaky
Copy link
Member

Hi @anotherbridge, this is caused because the first time you ran verification, it created some artifacts (it untar-ed the archive and created link metadata for the inspection). Subsequent verification attempts record these artifacts and consider them invalid. Can you try your comparison in two clean copies of the demo repo? Thanks!

@anotherbridge
Copy link
Author

Hey, thanks for the response @adityasaky.

Unfortunately when running the same in two different and clean copies of the demo repo the same occurs. For the Python version everything works fine, but when running the verification with the Go version I'm still getting the same error:

in-toto verify --layout root.layout --layout-keys alice.pub

inspection failed: artifact verification failed for Inspection 'untar', materials [update-version.776a00e2.link clone.776a00e2.link package.2f89b927.link] disallowed by rule [DISALLOW *]

This was the directory structure before I ran the verification in both cases:

.
├── alice.pub
├── clone.776a00e2.link
├── demo-project.tar.gz
├── package.2f89b927.link
├── root.layout
└── update-version.776a00e2.link

Again here are the untar.link files generated in both cases:
Golang
Python

@adityasaky
Copy link
Member

Good catch, @anotherbridge! Here's why this is happening: https://github.com/in-toto/in-toto/blob/fbc1eb053dd39c6d1fb307a60bd2c781e667c931/in_toto/settings.py#L39

The Python implementation automatically excludes recording certain artifacts which the Go implementation does not. @lukpueh and @shibumi, do we add these defaults to the Go implementation?

@anotherbridge
Copy link
Author

Thanks very much @adityasaky! That explains the behavior. And when explicitly allowing the *.link files, the verification does work as expected.

@adityasaky
Copy link
Member

Great! I'm going to edit this ticket to record exactly why this is happening.

@adityasaky adityasaky changed the title Verification does not work as expected in-toto-golang does not provide defaults for excluding artifacts Feb 22, 2023
@adityasaky adityasaky added enhancement New feature or request good first issue Good for newcomers and removed bug Something isn't working labels Feb 22, 2023
@PradyumnaKrishna
Copy link
Contributor

Hey @adityasaky, I would like to take up this issue.
Just want to know, where can we have ExcludePatterns in golang like we have in in-toto settings.py. I am thinking add this as a global variable in runlib.go.

@adityasaky
Copy link
Member

I'm actually less sure if we should patch it here or in in-toto-python. IMO the default excludes is not immediately obvious and potentially unexpected behaviour to a newcomer. @lukpueh WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants