profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/MarkLodato/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

MarkLodato/git-reparent 46

Git command to recommit HEAD with a new set of parents

MarkLodato/js-boxdrawing 34

JavaScript Box Drawing Library

MarkLodato/git-ssh-server 28

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

in-toto/attestation 27

ITE-6 Attestation Definitions

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 commentslsa-framework/github-actions-demo

GitHub- vs Self-Hosted detection is inaccurate.

Another idea: Download all workflow run logs. The first line indicates whether it's github- or self-hosted. That would require the provenance generator to have access to the logs, which is not ideal, and when doing it mid-run, I'm not sure if there are race conditions where that wouldn't work well.

MarkLodato

comment created time in 2 days

issue openedslsa-framework/github-actions-demo

GitHub- vs Self-Hosted detection is inaccurate.

The detection of GitHub-hosted runner vs Self-hosted runner is inaccurate. What we want to know is "did all jobs use GitHub-hosted runners?" Instead, the current code says "does the current job (creating the provenance) use a GitHub-hosted runner." Is it possible to actually check what we need?

An ugly idea is to parse the yaml to check all the runs-on fields, but that both (a) requires fetching and parsing the yaml, which is terrible, and (b) properly identifying which are github-hosted and which are self-hosted.

Any better ideas?

created time in 2 days

issue commentslsa-framework/azure-devops-demo

Fix recipe and materials

There is a similar issue with self-hosted runners, which applies to both Azure Pipelines and GitHub Actions. Each individual job within a workflow can use its own runner, so there is no workflow-wide property that says "all steps were run on hosted runners."

MarkLodato

comment created time in 2 days

issue commentslsa-framework/slsa

Easy way to view versioned SLSA

That would work! To me the big challenge is all the styling - HTML, CSS, Jekyll. Not my area of expertise. :-)

joshuagl

comment created time in 2 days

issue commentslsa-framework/azure-devops-demo

Fix recipe and materials

Hi @gattjoe, sorry for the long delay. I was on leave.

We have the same issue with Google Cloud Build (GCB), where we can't tell whether the build steps come from YAML or from the GUI. (@msuozzo @TomHennen FYI.) For now, I think it's OK to say that we can't detect it, then add it later if we figure out a way (say by the API). I'll take a look. Thanks for the research!

I'll do a little more research then send you a pull request for the fields!

MarkLodato

comment created time in 2 days

issue commentslsa-framework/slsa

Indicating SLSA versions for policy evaluation

I think tooling should indicate (or allow users to choose?) which version of the SLSA framework is being used. Maybe down the road the levels will be stable enough that it won't be an issue, but for now I think that there's still enough in flux that versioning is useful.

joshuagl

comment created time in 2 days

issue commentslsa-framework/slsa

Easy way to view versioned SLSA

Definitely! Suggestions / pull requests on how to do this would be we welcome.

Also, we currently have two different versions: the version of the spec (levels + requirements) and the version of the provenance schema. So we probably won't version the entire website.

joshuagl

comment created time in 2 days

issue openedslsa-framework/azure-devops-demo

Publish extension under slsa-framework project

Currently it's under @gattjoe's account. We need to publish it under the SLSA Framework project.

Instructions: https://docs.microsoft.com/en-us/azure/devops/extend/overview?view=azure-devops

created time in 2 days

issue closedslsa-framework/azure-devops-demo

Set up Azure Pipeline

Set up an Azure Pipeline to run this demo. This will allow us to test it and verify that it works.

  • [x] Created a slsa-framework organization in Azure DevOps.
  • [x] Create an azure-devops-demo project.
  • [X] Configure a pipeline to run the demo.
  • [x] Configure GitHub to automatically run the pipeline on commit.
  • [X] Add other members to the organization. (@TomHennen and @joshuagl for now - we're limited to 5)

closed time in 2 days

MarkLodato

issue commentslsa-framework/azure-devops-demo

Set up Azure Pipeline

It worked: https://dev.azure.com/slsa-framework/azure-devops-demo/_build/results?buildId=3&view=artifacts&pathAsName=false&type=publishedArtifacts

I'll continue to refine it.

MarkLodato

comment created time in 2 days

PR opened slsa-framework/github-actions-demo

Revert "Properly name each artifact in GH Actions."

This reverts commit f293d1cd68f0b3457dbf3f4f793e9f9cadd5efa1.

An "artifact" in GitHub Actions is a collection of files, not a single file, so the original version was working fine (with all files under the collection named "artifact") whereas the new version broke because it tried to download the non-existent artifact named "artifact".

Let's just revert to the old version because it was fine.

+0 -4

0 comment

2 changed files

pr created time in 3 days

create barnchMarkLodato/github-actions-demo

branch : revert

created branch time in 3 days

Pull request review commentslsa-framework/github-actions-demo

Properly name each artifact in GH Actions.

 jobs:       - name: Upload provenance         uses: actions/upload-artifact@v2         with:+          name: build.provenance

Also it's unsigned so it's not a DSSE envelope.

MarkLodato

comment created time in 3 days

PullRequestReviewEvent

push eventslsa-framework/github-actions-demo

Mark Lodato

commit sha f293d1cd68f0b3457dbf3f4f793e9f9cadd5efa1

Properly name each artifact in GH Actions. Previously both the artifact (salsa.txt) and the provenance (build.provenance) were uploaded with the default name of "artifact", meaning that the provenance overwrote the original artifact.

view details

Mark Lodato

commit sha ff918f78538627b611a8f01a2ecce584247ae086

Merge pull request #25 from MarkLodato/artifact-name Properly name each artifact in GH Actions.

view details

push time in 3 days

delete branch MarkLodato/github-actions-demo

delete branch : artifact-name

delete time in 3 days

PR merged slsa-framework/github-actions-demo

Properly name each artifact in GH Actions.

Previously both the artifact (salsa.txt) and the provenance (build.provenance) were uploaded with the default name of "artifact", meaning that the provenance overwrote the original artifact.

+4 -0

0 comment

2 changed files

MarkLodato

pr closed time in 3 days

Pull request review commentslsa-framework/github-actions-demo

Properly name each artifact in GH Actions.

 jobs:       - name: Upload provenance         uses: actions/upload-artifact@v2         with:+          name: build.provenance

Not in this PR, since it's not in JSON Lines format (it's currently pretty-printed).

MarkLodato

comment created time in 3 days

PullRequestReviewEvent

PR opened slsa-framework/github-actions-demo

Properly name each artifact in GH Actions.

Previously both the artifact (salsa.txt) and the provenance (build.provenance) were uploaded with the default name of "artifact", meaning that the provenance overwrote the original artifact.

+4 -0

0 comment

2 changed files

pr created time in 3 days

create barnchMarkLodato/github-actions-demo

branch : artifact-name

created branch time in 3 days

PullRequestReviewEvent

push eventslsa-framework/azure-devops-demo

Mark Lodato

commit sha 41ab26db4a683f28cc27c7f9807ccaf2810e608e

Set up CI with Azure Pipelines Context: issue #3 [skip ci]

view details

push time in 4 days

PullRequestReviewEvent

issue commentslsa-framework/slsa

Tag a initial/draft/non-final release of SLSA

Suggestion: "v0.1 (2021-09-15)". The version number is just "0.1" (SemVer2), but we write it with the date in parentheses for ease of understanding. The git tag would just be "v0.1".

Alternatively we could put the date in the "build metadata" of the SemVer2, i.e. "v0.1+2021-09-15", but to me that's much harder to read.

TomHennen

comment created time in 5 days

issue openedslsa-framework/slsa

"Build as Code" missing from Levels page

Need to add a table entry pointing to the requirements.md page.

created time in 5 days

Pull request review commentslsa-framework/slsa

Add "Identifies Source Code" requirement

 or [the Explicitly Run Commands example](https://slsa.dev/provenance/v0.1#explicitly-run-commands)).  <td>✓<td>✓<td>✓<td>✓+<tr id="identifies-source-code">+<td>Identifies source code+<td>++The provenance identifies the repository origin(s) for the source code used in+the build.++The identified repositories SHOULD only include source used directly in the build.

I agree that we need to update the terminology and have several examples with common build services. My recommendation:

  • Source: primary "top-level" input artifact. Most build services have a notion of a "source" and this should reflect that.
  • Build Config: top-level build definition / configuration. Sometimes this is the same as Source.
  • Dependency: anything else.

Examples:

Service Source Build Config Dependencies
GitHub Actions git commit containing the workflow definition (same as source) dependent actions, runner vm, anything fetched during the build
GCB (build-as-code) git commit containing the cloudbuild.yaml (same as source) ...
GCB (config in UI) git commit that was triggered serialization of the config ...
TomHennen

comment created time in 6 days

PullRequestReviewEvent

push eventMarkLodato/slsa

Mark Lodato

commit sha 9631d412f5538974e01aa58e1f9847d5ee36eab5

Rewrite ITE-6 using new schema and separte files. - Clarify goals. - Split specifications to their own files. - Avoid introducting new terminology or talking about "layers" because doing so adds complexity without benefit. - Use a much simpler schema that is both closer to existing in-toto 0.9 as well as easier to read and write. - Document the new Provenance type. - Other minor fixes.

view details

Mark Lodato

commit sha 6a2a7a3dcc924ab6b7c48454132bb61d7a0ad9fe

Refactor to make layering more distinct. - Reference SLSA. - Split into a distinct `predicateType` + `predicate` based on the SLSA attestation model. - Convert `subject` and `materials` to lists of objects, rather than maps from URI to DigestSet, so that (1) we can more naturally extend with more fields, such as media type, and (2) to allow easier indexing. - Add a proto definition of the Statement layer. - Move the curl example to README (no need for a duplicate YAML file.) - Switch to lowerCamelCase, which is already used by signing-spec.

view details

Mark Lodato

commit sha a40c931ac79db057035df675ff228c9348058434

doc fix: definedInMaterial is an integer

view details

Mark Lodato

commit sha fb00576720618a7071e8d1d3611373234280604f

Merge branch 'ite-6' of ITE This imports the history of [ITE-6] into the new attestation repo. Commit IDs have changed from the ITE repo because the history only includes ITE-6. Original commit 410d15599f034ce30166c65ef5986e309759b706 maps to the parent commit, a40c931ac79db057035df675ff228c9348058434. [ITE-6]: https://github.com/in-toto/ITE/pull/15

view details

Mark Lodato

commit sha 5a4af7851aa98942f29eda41e1c386b29d069297

Move predicates to separate directory.

view details

Mark Lodato

commit sha 3cedcad56a314aa9dcc9e32f8b8ee26ce94d5e68

Fix links within provenance.md

view details

Mark Lodato

commit sha a83f690279cc556485a077da01a115a9370080c7

Provenance: add buildFinishedOn

view details

Mark Lodato

commit sha 5630f34ee33c32c61f5f6b4d7a95585e99633840

Merge pull request #10 from MarkLodato/finished Provenance: add buildFinishedOn

view details

Mark Lodato

commit sha 9d6f96efbfed7f4cc118c4ebc5e9cecc1f417d9f

Better document schema; remove proto files.

view details

Mark Lodato

commit sha f1f865874d1e954a842d458088b9205c4439c2d0

Link to README from each predicate type. Otherwise the reader might not understand that there's more to the spec.

view details

Mark Lodato

commit sha 5418ba0e1e664220e68375216387eef6ac49722e

Fix JSON syntax for `subject` in schemas.

view details

Mark Lodato

commit sha 41cc42d3464d9778e91e84b8d7efc1422554f3d0

Add examples section to the Provenance spec. This shows how to use Provenance in practice and serves as a starting point for discussions with various CI/CD systems.

view details

Mark Lodato

commit sha 3edfa709abefc20e06767af8d1bd6dd4568e9a10

Provenance: add bazel example

view details

Mark Lodato

commit sha 04a0a06f73f0f3a80db2f24bc9c1b2cadac6ed80

typo: entry_point -> entryPoint

view details

Mark Lodato

commit sha a20100e7ffd8683d18633a2da261db9b68dec05d

Provenance: clarify builder and recipe. The previous wording did not clearly explain the meaning of builder and recipe, nor did it explain how recipe was intended to be complete.

view details

Mark Lodato

commit sha 51ed926b1b1bbb41823f3dc59538d854f1fe8f65

Add `Statement.type`, use MediaType in envelope. Add a new Statement `type` field that indicates the schema version, and use an unversioned MediaType in the Envelope `payloadType` field. Reasoning: - This makes the Statement self-describing, which aids readability. - Not all envelopes authenticate the payload type. Since we want the layers to be independent, we should include the schema version inside to protect against this. - MediaType is the standard way of indicating encoding; URI is uncommon for that purpose. - Most formats include a version inside the payload (e.g. PDF or JsonSchema) and have an unversioned MediaType. We do the same. - Removing the encoding from the type URI (i.e. removing "-json") allows policy engines to be encoding-agnostic. - The existing in-toto format (link and layout) already use a `type` field, so we can continue using the same concise MediaType. Note that the same reasoning does *not* apply to `predicateType`, which continues to be a URI. We considered moving it inside `predicate.type`, but then we need to worry about field name collisions.

view details

Mark Lodato

commit sha 7b1e0223d8b77ea3e5aa7bcd3870a22c875948e5

Merge pull request #12 from MarkLodato/type-inside-payload Add `Statement.type` and use MediaType in envelope.

view details

Mark Lodato

commit sha 9e021639097cda6f391be330190e57599823f0cc

Provenance: clarify the model and usage. Feedback from several readers indicated that the purpose of the various fields was not clear. Hopefully this new explanation resolves ambiguity. It includes a model with diagram, expanded and more accurate field explanations, and a simple example.

view details

Mark Lodato

commit sha bc66a3449b735e5df63dc15351b8099bfa47fcda

Rename reproducibility to environment (#14) The original name misleadingly sounded like whether it was reproducible, as opposed to the type. The word `environment` matches in-toto's current usage and also better conveys that these are builder-controlled parameters.

view details

Mark Lodato

commit sha 0ebd102b1471142c8e51f5d1d3abaf4fbe83393c

Set version numbers to 0.1. The specs are still in flux, so we'll use 0.1 to indicate this. (Do not update the version numbers of fake example specs.)

view details

push time in 6 days

issue commentin-toto/attestation

A good TLDR for attestations

Sure! Mind suggesting some wording?

trishankatdatadog

comment created time in 6 days