search

in-toto / specification

Specification and other related documents.
https://in-toto.io
MIT License
40 stars 26 forks source link

Document "artifact rule" rationale #4

Open lukpueh opened 7 years ago

lukpueh commented 7 years ago

The recent discussion about whether and why we decided to replace the implicit DISALLOW * with an implicit ALLOW * when verifying expected materials and products makes it clear that we need to document these decisions more thoroughly.

in-toto/in-toto#43 shows how the current design of MATCH rules (only) evolved.

@SantiagoTorres suggests to create a Wiki that summarizes such on- and offline discussions and provides additional information about the rationale behind certain design decision that would go beyond the scope of the specification.

reza-curtmola commented 7 years ago

I missed all the discussion for the rationale why we prefer an implicit rule ALLOW instead of a DENY at the end of the artifact rules. Santiago mentioned that this is preferred because of the feedback received, which is mostly to improve usability.

I don't have a strong preference for either one, but I wanted to make sure that Justin is also on board with this choice.

JustinCappos commented 7 years ago

I don't remember the content of the discussion here, but do vaguely recall a discussion a long while back. We definitely need to document it in a way that others can see and chime in.

On Wed, Oct 11, 2017 at 5:11 PM, reza-curtmola notifications@github.com wrote:

I missed all the discussion for the rationale why we prefer an implicit rule ALLOW instead of a DENY at the end of the artifact rules. Santiago mentioned that this is preferred because of the feedback received, which is mostly to improve usability.

I don't have a strong preference for either one, but I wanted to make sure that Justin is also on board with this choice.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/in-toto/docs/issues/4#issuecomment-335949742, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XDySGHALDKIeWz_geM6fFgEe0WSLgks5srS72gaJpZM4Pymap .

lukpueh commented 7 years ago

I think the main argument was that having to explicitly authorize (ALLOW) every material and product seems cumbersome, given that we mostly care for linking (MATCH) products of one step to the materials of the next step. And that for a more restrictive layout, a project owner can always use an explicit DISALLOW * rule.

JustinCappos commented 7 years ago

I'd like to see some examples of this so we can better understand the implications.

If there is an explicit ALLOW *, doesn't this mean new items can effectively always be silently added?

SantiagoTorres commented 7 years ago

Sorry I missed this comment. I'll upload some examples soon to the repository's wiki to help us document these design decisions.

An explicit ALLOW * does indeed allow a step to register any products in their materials and products. Much like a firewall, I think having an explicit DISALLOW for good practice is a better decision than the opposite.

JustinCappos commented 7 years ago

Offhand, I'd rather have 1) an accidental annoyance from blocking something that is caught later and rectified before the software is shipped than 2) a situation where a compromised step can add any set of files they like, compromising any meaningful security guarantees.

However, with some discussion, I may feel differently.

On Fri, Oct 27, 2017 at 5:56 PM, Santiago Torres notifications@github.com wrote:

Sorry I missed this comment. I'll upload some examples soon to the repository's wiki to help us document these design decisions.

An explicit ALLOW * does indeed allow a step to register any products in their materials and products. Much like a firewall, I think having an explicit DISALLOW for good practice is a better decision than the opposite.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/in-toto/docs/issues/4#issuecomment-340105122, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD_AQcqsxaAiHJ3W8GnCv3Jaws3Ywks5swlGggaJpZM4Pymap .

lukpueh commented 5 years ago

Below is a mostly exhaustive list of related historic and ongoing in-toto issues and PRs. It's worth combing through these, when rehashing the artifact rule rational.