{"action":"created","issue":{"url":"https://api.github.com/repos/in-toto/in-toto/issues/43","repository_url":"https://api.github.com/repos/in-toto/in-toto","labels_url":"https://api.github.com/repos/in-toto/in-toto/issues/43/labels{/name}","comments_url":"https://api.github.com/repos/in-toto/in-toto/issues/43/comments","events_url":"https://api.github.com/repos/in-toto/in-toto/issues/43/events","html_url":"https://github.com/in-toto/in-toto/issues/43","id":190190159,"number":43,"title":"Fix MATCH rule ambiguities","user":{"login":"lukpueh","id":589324,"avatar_url":"https://avatars.githubusercontent.com/u/589324?v=3","gravatar_id":"","url":"https://api.github.com/users/lukpueh","html_url":"https://github.com/lukpueh","followers_url":"https://api.github.com/users/lukpueh/followers","following_url":"https://api.github.com/users/lukpueh/following{/other_user}","gists_url":"https://api.github.com/users/lukpueh/gists{/gist_id}","starred_url":"https://api.github.com/users/lukpueh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lukpueh/subscriptions","organizations_url":"https://api.github.com/users/lukpueh/orgs","repos_url":"https://api.github.com/users/lukpueh/repos","events_url":"https://api.github.com/users/lukpueh/events{/privacy}","received_events_url":"https://api.github.com/users/lukpueh/received_events","type":"User","site_admin":false},"labels":[{"id":381362161,"url":"https://api.github.com/repos/in-toto/in-toto/labels/question","name":"question","color":"cc317c","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2016-11-17T23:02:21Z","updated_at":"2016-12-22T15:39:31Z","closed_at":null,"body":"The current rule type `MATCH` uses the following language:\r\n```\r\nMATCH (MATERIAL|PRODUCT) <path pattern> [AS <target path pattern>] FROM <step name>\r\n```\r\nCurrently this reads (my interpretation of the specification):\r\n>`MATERIALS` or `PRODUCTS`, depending on the rule's second element, of a step with `<step name>` and matched by `<target path pattern>`  (if specified) or `<path pattern>` (else), must have a hash that matches the hash of a `MATERIAL` or `PRODUCT`, depending on whether the rule is in the `material_matchrules` or `product_matchrules`, of a step that matches `<path pattern>` and has not been matched by a previous rule. The rule also fails if the target path pattern does not find any artifacts.\r\n\r\nWhen I and @SantiagoTorres, who came up with the language and implemented it, tried to apply these rules in real world software supply chains, we both had difficulties to express what we wanted, which IMHO indicates that the language should be clarified and freed from ambiguities.\r\nThe following (or at least most of it) should be unmistakingly clear by just reading the rule:\r\n\r\n- **What is the match source and what is the match target?**\r\n   rule in one of step's rule lists VS.  `... FROM <step name>`\r\n\r\n- **What is the source artifact type and what is the target artifact type?**\r\n   rule in `material_matchrules` or `product_matchrules`  VS. `MATCH (MATERIAL|PRODUCT)...` \r\n\r\n- **Should there be a target artifact for every source artifact? (currently no)**\r\n  material_matchrule (source): `MATCH PRODUCT *  FROM target-step`\r\n  source materials : `hash(foo) = x`, `hash(bar) = y`\r\n  target products:    `hash(foo) = x`\r\n  Pass?\r\n\r\n- **Should there be a source artifact for every target artifact? (currently yes)**\r\n  material_matchrule (source): `MATCH PRODUCT *  FROM target-step`\r\n  source materials : `hash(baz) = x`\r\n  target products:    `hash(baz) = x `, `hash(zap) = y`\r\n  Fail?\r\n\r\n- **Should the rule fail if the path pattern does not find any artifacts?**\r\n  `MATCH PRODUCT foo ...` should probably fail if there is no product foo?\r\n  `MATCH PRODUCT * ...` should probably not fail if there is no product?\r\n\r\n- **Do we solely match by hash in case of wildcard patterns?**\r\n  material_matchrule (source): `MATCH PRODUCT *  FROM target-step`\r\n  source materials : `hash(new/path/foo) = x`, `hash(bar) = y`\r\n  target products:    `hash(foo) = x`, `hash(baz) = y`\r\n  \r\n- **Can artifacts be matched more than once by different MATCH rules? Would AND, OR operators to concatenate MATCHRULES help here?**\r\n\r\n-------\r\n\r\nBelow is a super explicit language to start the discussion. This might be exaggerated but at the same time still does not express *everything*. I don't say, maximum explicitness is a must, nonetheless implicit behavior should be defined somewhere, e.g. in the specs.\r\n\r\n```\r\nMATCH [ALL] (MATERIAL|PRODUCT) <source path pattern> FROM <source step name> WITH [ALL] (MATERIAL|PRODUCT) <target path pattern>  FROM <target step name>\r\n```\r\n"},"comment":{"url":"https://api.github.com/repos/in-toto/in-toto/issues/comments/268825172","html_url":"https://github.com/in-toto/in-toto/issues/43#issuecomment-268825172","issue_url":"https://api.github.com/repos/in-toto/in-toto/issues/43","id":268825172,"user":{"login":"lukpueh","id":589324,"avatar_url":"https://avatars.githubusercontent.com/u/589324?v=3","gravatar_id":"","url":"https://api.github.com/users/lukpueh","html_url":"https://github.com/lukpueh","followers_url":"https://api.github.com/users/lukpueh/followers","following_url":"https://api.github.com/users/lukpueh/following{/other_user}","gists_url":"https://api.github.com/users/lukpueh/gists{/gist_id}","starred_url":"https://api.github.com/users/lukpueh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lukpueh/subscriptions","organizations_url":"https://api.github.com/users/lukpueh/orgs","repos_url":"https://api.github.com/users/lukpueh/repos","events_url":"https://api.github.com/users/lukpueh/events{/privacy}","received_events_url":"https://api.github.com/users/lukpueh/received_events","type":"User","site_admin":false},"created_at":"2016-12-22T15:39:31Z","updated_at":"2016-12-22T15:39:31Z","body":"We do use the same language to provide the no tampering guarantee as well as to constrain what a functionary can do within a step. I agree with @awwad that these are two separate concerns and maybe also could be separated conceptually. \r\n\r\nThe first is an in-toto core requirement, whereas the second one is an additional security feature, similar to \"constrain stdout/stderr of a step\" or \"constrain the return value of a step\", for which we intended custom inspections.\r\n\r\nI can see how the files used in a step are more interesting than stdout/sdterr/return value and why we therefore want core code to provide this ability.\r\n\r\nIn any case we must agree on what we expect from the matchrules. We need to find a common ground for wildcard's flexibility/convenience, moving/renaming files and still allowing a one-to-one mapping of files. "}}
{"actor":{"display_login":"lukpueh"}}