profile
viewpoint

MarkLodato/git-reparent 47

Git command to recommit HEAD with a new set of parents

in-toto/attestation 36

ITE-6 Attestation Definitions

MarkLodato/js-boxdrawing 35

JavaScript Box Drawing Library

MarkLodato/git-ssh-server 28

A restricted shell for managing GitHub-like sites through SSH.

MarkLodato/gh-contest 10

My github contest entry

MarkLodato/patch-converter 9

A script to convert the output of git patches to Hg format.

MarkLodato/cgit 5

a fast web interface for git

MarkLodato/dotfiles 5

My dotfiles

MarkLodato/cython_freeze 2

DEPRECATED: Equivalent of freeze.py for Cython

issue commentin-toto/attestation

Should the predicateType's hash be included as a digest?

That's a reasonable concern, but you'd need to figure out what to actually hash.

  1. The TypeURI is just a unique identifier that need not resolve to anything. The recommendation is to point it to human-readable documentation, but this is not required. Thus, you'd need to clarify what needs to be hashed, and state whether the URI must resolve to the thing-to-be-hashed.
  2. What is the input to the hash function? You need some well defined serialization that describes the schema. But there is no such standard format. One could use protobuf, or JSON schema, or something else entirely. For https://slsa.dev/provenance/v0.1, we just use HTML. That would need to be agreed upon. If you use a text-based format, you'll need to handle cases where you add a trivial newline and now the hash changes.
  3. It is a feature for the schema to change without updating the URL, to allow for backwards-compatible additions. If we required hash checks, then I don't think we could allow consumers to accept newer minor versions.
jul-sh

comment created time in 2 days

pull request commentslsa-framework/slsa

Switch from Google Analytics to GoatCounter.

@david-a-wheeler Any objections? Or @trishankatdatadog is it OK to submit?

MarkLodato

comment created time in 3 days

pull request commentslsa-framework/slsa

Simplify the specifications list template.

How do we block @NANOKINGJOKER?

Already done.

MarkLodato

comment created time in 4 days

push eventslsa-framework/slsa

Mark Lodato

commit sha ede46663893dfa07f8d29ad666ba762d8baa3d8f

Simplify the specifications list template. Similar to e56c388 (#270), but for the list of subpages in /spec/v0.1/index. This change replace the "automatic" code with a manual list, which is much easier to understand and maintain. No content change. The only HTML change is to switch from absolute to relative links and to eliminate empty `<li>` elements. NOTE: Neither the original nor new code correctly handled displaying more than one specification version. This commit adds a TODO making it clear that it doesn't work. Signed-off-by: Mark Lodato <lodato@google.com>

view details

Mark Lodato

commit sha ddde08eb052d6673a34240e93f2b753666f526e2

Merge pull request #271 from MarkLodato/spec-list Simplify the specifications list template.

view details

push time in 5 days

delete branch MarkLodato/slsa

delete branch : spec-list

delete time in 5 days

PR merged slsa-framework/slsa

Simplify the specifications list template.

Similar to e56c388 (#270), but for the list of subpages in /spec/v0.1/index. This change replace the "automatic" code with a manual list, which is much easier to understand and maintain.

No content change. The only HTML change is to switch from absolute to relative links and to eliminate empty <li> elements.

NOTE: Neither the original nor new code correctly handled displaying more than one specification version. This commit adds a TODO making it clear that it doesn't work.

Testing

The old and new version result in identical HTML except as noted above, ignoring one whitespace change and build timestamps on posts.

$ git checkout main
$ bundle exec jekyll build
$ mv _site /tmp/old_site
$ git checkout spec-list
$ bundle exec jekyll build
$ diff -u {/tmp/old_site,_site}/spec/v0.1/index.html

Compare:

  • https://deploy-preview-271--slsa.netlify.app/spec/v0.1/#specifications
  • https://slsa.dev/spec/v0.1/#specifications
+39 -31

2 comments

6 changed files

MarkLodato

pr closed time in 5 days

pull request commentslsa-framework/slsa

Simplify the specifications list template.

Thanks for the quick reviews!

MarkLodato

comment created time in 5 days

push eventMarkLodato/slsa

Mark Lodato

commit sha ede46663893dfa07f8d29ad666ba762d8baa3d8f

Simplify the specifications list template. Similar to e56c388 (#270), but for the list of subpages in /spec/v0.1/index. This change replace the "automatic" code with a manual list, which is much easier to understand and maintain. No content change. The only HTML change is to switch from absolute to relative links and to eliminate empty `<li>` elements. NOTE: Neither the original nor new code correctly handled displaying more than one specification version. This commit adds a TODO making it clear that it doesn't work. Signed-off-by: Mark Lodato <lodato@google.com>

view details

push time in 5 days

PR opened slsa-framework/slsa

Simplify the specifications list template.

Similar to e56c388 (#270), but for the list of subpages in /spec/v0.1/index. This change replace the "automatic" code with a manual list, which is much easier to understand and maintain.

No content change. The only HTML change is to switch from absolute to relative links and to eliminate empty <li> elements.

NOTE: Neither the original nor new code correctly handled displaying more than one specification version. This commit adds a TODO making it clear that it doesn't work.

Testing

The old and new version result in identical HTML except as noted above, ignoring one whitespace change and build timestamps on posts.

$ git checkout main
$ bundle exec jekyll build
$ mv _site /tmp/old_site
$ git checkout spec-list
$ bundle exec jekyll build
$ diff -u {/tmp/old_site,_site}/spec/v0.1/index.html
+39 -27

0 comment

2 changed files

pr created time in 5 days

push eventMarkLodato/slsa

Mark Lodato

commit sha ed01c78d80ec2d42e2cc9cd03caf25de716fab08

Simplify the specifications list template. Similar to e56c388 (#270), but for the list of subpages in /spec/v0.1/index. This change replace the "automatic" code with a manual list, which is much easier to understand and maintain. No content change. The only HTML change is to switch from absolute to relative links and to eliminate empty `<li>` elements. NOTE: Neither the original nor new code correctly handled displaying more than one specification version. This commit adds a TODO making it clear that it doesn't work. Signed-off-by: Mark Lodato <lodato@google.com>

view details

push time in 5 days

create barnchMarkLodato/slsa

branch : spec-list

created branch time in 5 days

delete branch MarkLodato/slsa

delete branch : nav

delete time in 5 days

PR opened slsa-framework/slsa

Simplify the nav template

Make the site easier to maintain by replacing the "automatic" navigation system with explicit configuration in _data/nav.yml.

This resolves several drawbacks with the old nav template:

  • It was difficult to add new pages. You had to set the order field correctly and update all the other pages, and even then it often didn't work.
  • There was no way to customize the link text (always page title) or to link to custom URLs (e.g. /provenance instead of /provenance/v0.2).
  • The mobile and non-mobile templates were duplicate but slightly different, which may lead to bugs in the future.

This PR keeps the HTML identical (except for whitespace changes) to make it easier to verify correctness.

Note: Neither the old code nor this code correctly set the "active" class on subpages of Specifications. That can come in a follow-up PR.

Testing

The old and new version result in identical HTML, ignoring whitespace (and build timestamps on posts).

$ git checkout main
$ bundle exec jekyll build && minify --html-keep-comments --html-keep-document-tags --html-keep-end-tags --html-keep-whitespace _site/index.html | sed -e 's/></>\n</g' >! /tmp/index.old.html
$ git checkout nav
$ bundle exec jekyll build && minify --html-keep-comments --html-keep-document-tags --html-keep-end-tags --html-keep-whitespace _site/index.html | sed -e 's/></>\n</g' >! /tmp/index.new.html
$ diff -u /tmp/index.old.html /tmp/index.new.html
+84 -118

0 comment

18 changed files

pr created time in 5 days

push eventMarkLodato/slsa

Mark Lodato

commit sha e56c3889ef045515c873ab6e79ae36cda5122e74

Simplify the nav template The old nav system had several drawbacks: - It tried to "automatically" list all of the specification pages using the `order` field of each page, but this didn't work correctly and was a pain to maintain. Plus the liquid code was complicated. - There was no way to customize the link text (always page title) or to link to custom URLs (e.g. /provenance instead of /provenance/v0.2). - The mobile and non-mobile templates were duplicate but slightly different, which may lead to bugs in the future. Now we have an explicit configuration in _data/nav.yml and use the same template for both mobile and non-mobile nav bars. This should be easier to maintain. Signed-off-by: Mark Lodato <lodato@google.com>

view details

push time in 5 days

create barnchMarkLodato/slsa

branch : nav

created branch time in 5 days

issue commentslsa-framework/slsa

Consider using Netlify for hosting

OK, it's set up. See https://slsa.netlify.app.

There is one bug: the "View source on GitHub" link is broken due to https://github.com/jekyll/github-metadata/issues/208: Netlify doesn't set a git remote in the clone for some reason, so the github-metadata plugin doesn't know what branch (main) and path (/docs) were used. Netlify does, so I think we can work around this through some netlify config, e.g. passing in parameters to the build, but for now it's good enough. Another solution would be to hard-code the link, but I'd prefer not to do that to allow previews of PRs/forks to work correctly.

MarkLodato

comment created time in 9 days

issue commentslsa-framework/slsa

Consider using Netlify for hosting

Since I have one +1 and no objections, I'm going to set it up to use my personal starter account for now. If we like it, we can consider going further and perhaps getting an open source license.

MarkLodato

comment created time in 9 days

push eventMarkLodato/dotfiles

Mark Lodato

commit sha fa642a73931f6ebe89f4b00f8c8435187984bccb

vim: remove console background color The background colors looks terrible when using hterm with some fonts that have gaps between lines. Because `bg` is not set, we have to use `black` as the color for Ignore.

view details

Mark Lodato

commit sha 4a560b70bcbc94a3fda5fb77d3d05aa5eadb19d5

vim: increase default gui size to include gutter

view details

push time in 10 days

delete branch MarkLodato/marklodato.github.com

delete branch : https

delete time in 10 days

push eventMarkLodato/marklodato.github.com

Mark Lodato

commit sha cb5e8f08061038fb8c55447939414ced74b40d91

Convert all http links to https.

view details

push time in 10 days

create barnchMarkLodato/marklodato.github.com

branch : https

created branch time in 10 days

issue commentslsa-framework/slsa

Provenance publication & discovery

Agreed on the need for this. My thinking is that we probably want both "publish alongside release artifacts" and "store attestations in a public database" (be it rekor or something else). The former is valuable for reliable online enforcement decisions, while the latter is valuable for deep offline analysis, continuous validation, and incident response.

joshuagl

comment created time in 11 days

issue commentin-toto/attestation

Consider adding a "digest kind" and/or "content type" to subject

  • Counterpoint: This is too abstract to warrant the cost. We need some sort of proof-of-concept to show that this would be exploitable in a somewhat realistic scenario.

We now have one: CVE-2021-41190. I'm hoping to have a more detailed writeup within the next few weeks, but below is a brief summary. Note that this is a very realistic and easy attack. It has been patched in most major registries by disallowing these "chimera" images, but a similar vulnerability is bound to show up elsewhere.

Scenario: There exists some sort of "scanner" that analyzes a container image and generates an attestation.

  1. Create a "chimera" JSON file that can be interpreted as both an OCI index and an OCI manifest. When interpreted one way, the image is "good"; when interpreted the other, the image is "bad".
  2. Upload the image to a registry with the "good" content type, and ask the scanner to scan it. This results in a "good" attestation.
  3. Re-upload the image to a registry with the "bad" content type, and deploy it somewhere that checks the attestation.

Actual result: The image passes the policy because an attestation exists saying "good".

Expected result: The image is rejected because it is bad. The verifier should realize that the attester was looking at a essentially a different image.

Do you include the kind/type in the matching?

Proposal: include the content type if and only if it affects the attestation.

  • For subject in provenance, omit content type unless the content type is actually an output of the build.
  • For subject for a scan result, include content type if it's an input to the scanner, and omit it if the content type is inferred
  • For materials in provenance, include the content type if it affected the build.

For matching, an artifact is considered matching a subject if the digest matches and either the subject has no content type, the query has no content type, or the content types match.

MarkLodato

comment created time in 11 days

issue commentslsa-framework/slsa

Switch to Community Specification license

No objections from me.

MarkLodato

comment created time in 12 days

issue commentslsa-framework/slsa

Add Bad Design as a supply chain scenario

But how would someone verify this? It seems out of scope of SLSA.

moshe-apiiro

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventslsa-framework/slsa

Mark Lodato

commit sha 99a105bdebba65d75424c60bb5b1d5d28b5724dd

Prefer relative links to simplify the content. This fixes the pages when rendered on GitHub and generally makes the source easier to read. Signed-off-by: Mark Lodato <lodato@google.com>

view details

Mark Lodato

commit sha b2c45aea94bc757432a8f3982a6f89cff5a421f8

Merge pull request #267 from MarkLodato/links Prefer relative links to simplify the content.

view details

push time in 13 days

more