Open asafalgawi opened 2 weeks ago
Hi @asafalgawi , thank you for the proposal. We have discussed this during the community meeting. We agree with the "latest" vulnerability report user scenario, however we need to understand the feasibility and scope of change. @binbin-li brought up good point today, the individual verifier might not have filtering abilities. Major refactoring might be required in executor code path. We still require more time to understand the notary scenarios a bit more, thankyou for your patience.
Hi @susanshi, thanks for the reviewing the proposal and for the update :)
Hi @asafalgawi , thank you for the proposal. We have discussed this during the community meeting. We agree with the "latest" vulnerability report user scenario, however we need to understand the feasibility and scope of change. @binbin-li brought up good point today, the individual verifier might not have filtering abilities. Major refactoring might be required in executor code path. We still require more time to understand the notary scenarios a bit more, thankyou for your patience.
Hi @asafalgawi, reviewing our current executor path below, we want to explore a bit more on the proposed implementation. How will the executor be refactored for filtering? Note we will not be able to change the verifier interfaces to maintain backward compatibility. If the current PR review meeting and community meeting time doesn't work, would you be open to meet and discuss in the once off meeting?
for _, referrerStore := range executor.ReferrerStores {
for _, reference := range referrersResult.Referrers {
for _, verifier := range executor.Verifiers {
}
}
}
Description
What this PR does / why we need it:
This PR adds a proposal for filtering artifacts based on their annotations before forwarding them to verification by one of the configured verifiers.]
The PR refers to issue #1772
Type of change
Added document to proposal directory.