12 · Derivando pins¶

Os pins dizem quando uma obrigação se aplica, e um pin errado dá uma resposta correta à pergunta errada (capítulo 4). Escrever bem os pins exige saber como o motor compila uma política; conferir uma condição declarada contra uma regra exige conhecer a regra. A segunda é a habilidade que a maioria dos revisores tem, então o modo derive_pins transforma escrever os pins em conferi-los.

O que ele calcula¶

Dada uma tabela de propriedades versionada, o derive_pins calcula, para cada obrigação, a condição mais fraca sob a qual ela vale, em vez de prová-la sob os pins que alguém escolheu. Ele pergunta cada obrigação primeiro sem pins, já que uma que vale incondicionalmente é estritamente mais forte que uma que vale sob alguma condição. Depois, para cada condição que os ramos da política sugerem, ele retira um pin de cada vez enquanto a obrigação continuar valendo.

derived = client.derive_pins("properties.json")
for record in derived.records:
    if record.get("summary"):
        continue
    print(", ".join(record["ids"]), record["minimal_pin_sets"], record["reads_as"])
print(derived.summary.get("conditions_no_row_covers"), "condition(s) no row covers")

Cada obrigação volta com os seus minimal_pin_sets e uma frase que um revisor pode confrontar com a regra que ela deveria aplicar:

risk_warning_given gates respond with permitted high risk answer exactly when $product_is_nmmi or $product_is_rmmi.

Ou seja: o aviso de risco protege a resposta de alto risco exatamente quando o produto é um NMMI ou um RMMI. Isso não é um conjunto de pins para copiar. É uma afirmação que alguém pode rejeitar: o aviso só é aplicado a estes dois produtos ou é o que a regra diz, ou é um achado.

Os quatro contadores do resumo¶

Contador	O que significa
`rows_with_redundant_pins`	a obrigação vale sem os seus pins, então eles a enfeitavam em vez de sustentá-la. Não é uma falha: reescreva a linha sem eles, ou mantenha as duas formas de perguntar como um `pin_pair` onde os pins declaram a própria condição da regulação (capítulo 11)
`conditions_no_row_covers`	o que deve ser tratado como defeito. A política aplica a obrigação sob uma condição sobre a qual nenhuma linha da tabela pergunta, então a tabela parece ter provado esse ramo, e não provou
`obligations_with_incomparable_minima`	a obrigação é aplicada sob duas ou mais condições, nenhuma das quais implica outra. Cada uma é uma afirmação separada e precisa de uma linha própria. Não é um defeito por si só, desde que todas estejam cobertas, o que o contador anterior confere
`rows_a_weaker_condition_would_carry`	uma linha fixa mais pins do que precisa. Não está errado, e vale a pena ver: quanto mais estreita a pergunta, mais uma resposta limpa deixa sem dizer

Uma condição não tem contador. Uma obrigação com minimal_pin_sets vazio é uma que a política nunca exige em nenhum caminho: ela aparece no registro dessa obrigação e em nenhum dos quatro totais. Um pipeline que lê só a linha de resumo não a verá, então leia também os registros. É um defeito diferente de uma proteção que pode ser contornada: a verificação está ausente de um caminho, em vez de contornável nele, e nenhum pin salva essa linha.

A ressalva¶

Derivar os pins não os valida. A condição é lida dos próprios ramos da política. Se a regra exige uma obrigação incondicionalmente e a política só a confere dentro de um ramo, a condição derivada é esse ramo, e a obrigação vale sob ela. Nada no motor consegue detectar isso, porque nada no motor conhece a regra. O que muda é o que o revisor recebe: aplicado só quando o produto é um NMMI é uma frase que alguém pode confrontar com o regulamento e rejeitar, e um pin numa requisição não é.

Os limites¶

Uma condição derivada é a da política, não a da regra. É uma proposta para um revisor, e o revisor decide se ela é a condição que a regra quer dizer.
Uma obrigação que a política nunca exige não tem conjunto mínimo nem contador; leia os registros.
A derivação é sobre as linhas da tabela. Uma linha que ninguém escreveu não tem derivação.