profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jchestershopify/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.
Jacques Chester jchestershopify @Shopify

jchestershopify/heroku-buildpack-ruby 0

Heroku's Ruby Buildpack

jchestershopify/rubygems 0

Library packaging and distribution for Ruby.

jchestershopify/slsa 0

Supply-chain Levels for Software Artifacts

fork jchestershopify/rubygems

Library packaging and distribution for Ruby.

https://rubygems.org/

fork in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentShopify/agent

update bundler to 2.2.22

 DEPENDENCIES   fpm  BUNDLED WITH-   1.12.1+   1.17.3

Doesn't seem to have upgraded to 2.2.22?

pfeffer

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

issue commentslsa-framework/slsa

Pair and mob programming

Expanding a bit, in $JOB-2 I could see assigning an interrupt pair to review and promote commits as soon as they're made on development. Does that track for you?

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

Thanks.

How do you feel about two-branch strategies, where there's a development trunk and a release branch? Assuming two branches, promotions could presumably require some additional review.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

So popping the stack, is your position that trunk-based pairing is to be forbidden? I'm obviously against that position, but if it is the position it should be explicit.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

And they modify the tooling without being noticed how?

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

In the case of pair programming, the tooling (i.e. local environment used to commit the change) can be subverted by a single person.

How do they do this without their pair noticing?

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

Couldn't an attacker subvert review tools?

My impression was that the requirement is about having multiple humans involved, so that no one human can make an unreviewed change. Tools seems to be an expansion of the requirement.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

How would this address the threat model of committing a different change than was reviewed?

Could you elaborate on the scenario? I want to make sure we're really talking about the same thing, I am concerned that we're talking past each other.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

How would synchronous review address this, other then re-reviewing the diff using an asynchronous review tool?

I looked into this a bit. I think that meeting the desired standard would require multiple git signatures to strongly establish authentic identities. That's not natively supported, though there are schemes based on using git notes.

I still think my reading is correct: it's permissible, but tooling needs to capable of distinct authentications at commit time. At the moment it's a schlep.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

I think an FAQ entry would be fine. I think finding a concise wording suitable for the core requirements doc would be quite difficult.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

I think there are two separate questions being discussed. The first is whether four-eyes is satisfied by synchronous review. The second is about tooling to assure that four-eyes has occurred.

As currently written, the second issue is already addressed:

The platform ensures that no person can use alternate identities to bypass the two-person review requirement.

To satisfy this requirement for synchronous reviews, additional tooling would be required to ensure distinct identities. That this tooling is not common doesn't make it impossible. Organisations wanting to perform synchronous reviews would need to bear the additional burden of creating such automation.

As currently drafted, I don't think the requirement prohibits synchronous review:

Every change in the revision's history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated.

And in fact, now that I've done a forensic reading, that might be my answer: the bar for pair programming teams is higher in terms of building automation, but it's not forbidden outright. If you have two strongly authenticated persons attached to the change, and if it is not possible to make changes solo, you meet the requirement.

jchestershopify

comment created time in 2 months

issue closedslsa-framework/slsa

Allow alternative digest algorithms

Currently (as of), the requirements doc says of identifying artifacts that:

The provenance identifies the output artifact via a cryptographic hash. The RECOMMENDED algorithm is SHA-256 for cross-system compatibility. If another algorithm is used, it SHOULD be resistant to collisions and second preimages.

It would be useful if provenance tooling could calculate multiple digests, so that if one digest algorithm is rendered untrustworthy, there is still a redundant way to assure integrity.

  1. Recommending an algo+digest format, eg JWT's alg field or W3C Subresource Integrity.
  2. Allow provenance systems to attach multiple digests to a single resource.

closed time in 2 months

jchestershopify

issue commentslsa-framework/slsa

Allow alternative digest algorithms

Closing as #98 was merged.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

That's a "soft" check that can be bypassed by a single person.

I can make this argument about self-reviews. How do you prevent those? Through automation which checks for multiple identities attached to the commit or series of commits.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

One-person review?

I agree that some kind of reviewing or four-eyes rule should be in effect at lower SLSA levels.

(Xref #95, which is tangentially related.)

joshuagl

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

A "committing to trunk without extra review step" workflow implies that each individual collaborator has permissions to write to the trunk branch, making the review a convention vs. a hard requirement enforced by software that cannot be bypassed.

Can't the same kind of automation refuse to accept changes that have only one authored-by or committed-by identity? (It seems like a good idea even before reaching SLSA-4, actually).

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Allow alternative digest algorithms

@inferno-chromium see #98 for my suggested rewording.

jchestershopify

comment created time in 2 months

PR opened slsa-framework/slsa

Explicitly allow multiple provenance hashes

This change updates the "Identifies Artifact" requirement to allow multiple hashes to be computed for artifacts. This is already a capability of the In-Toto attestation format.

+6 -3

0 comment

1 changed file

pr created time in 2 months

create barnchjchestershopify/slsa

branch : explicitly-allow-multiple-hashs

created branch time in 2 months

issue commentslsa-framework/slsa

Allow alternative digest algorithms

Can you submit a PR for the wording change that makes it more clear ?

Let me see what I can come up with.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Allow alternative digest algorithms

Ah, I missed that! But could we at least get a "... MAY allow multiple digest algorithms to be applied" or similar in the requirements itself? That would help prevent future passers-by like yours truly from making the same request.

jchestershopify

comment created time in 2 months

issue commentslsa-framework/slsa

Pair and mob programming

I'm not sure I understand. Could you elaborate on the scenario?

jchestershopify

comment created time in 2 months

PR opened slsa-framework/slsa

Lay disallowance emph on RFC2119 MUST NOT

This is a very minor stylistic change. Instead of using "MUST disallow" as the negative, I suggest using "MUST NOT allow". This places the emphasis onto the RFC 2119 term and makes visual scanning easier.

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchjchestershopify/slsa

branch : place-emphasis-on-must-not

created branch time in 2 months

push eventjchestershopify/slsa

push time in 2 months