search

uptane / uptane-standard

standard for Uptane
https://uptane.github.io
Other
37 stars 31 forks source link

Make slow retrieval attack prevention a SHALL #216

Closed mnm678 closed 3 years ago

mnm678 commented 3 years ago

Resolves #194

jhdalek55 commented 3 years ago

Reviews please...@trishankkarthik @JustinCappos @tkfu

jhdalek55 commented 3 years ago

@tkfu @trishankatdatadog can we get this approved? It's just a wording change.

trishankatdatadog commented 3 years ago

Hmm, nothing against this PR, but generally speaking, we should get >= 2 reviews from 2 different orgs to approve and merge going forward, no? 🙂

iramcdonald commented 3 years ago

Hi Trishank,

Yes and no.

In this instance, the bi-weekly Uptane Standards calls have had a strong consensus for many months that the Slow Retrieval Attack prevention should be a SHALL in Uptane v2.0 (which is allowed not to be completely backward compatible).

There's no need for a lot of new text. In our bi-weekly discussions, our consensus all along has been that the lack of that SHALL was actually a bug in Uptane Standard v1.x.

OTOH, I agree with you that reviews by >=2 people should be the mechanism when there is any significant new text added to the Standard or Deployment Considerations.

Cheers,

Ira McDonald (Musician / Software Architect)

Chair - SAE Trust Anchors and Authentication TF Co-Chair - TCG Trusted Mobility Solutions WG

Co-Chair - TCG Metadata Access Protocol SG

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: @. @.>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

On Tue, Sep 28, 2021 at 3:04 PM Trishank Karthik Kuppusamy < @.***> wrote:

Hmm, nothing against this PR, but generally speaking, we should get >= 2 reviews from 2 different orgs to approve and merge going forward, no? 🙂

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/pull/216#issuecomment-929541331, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO3LXZO7LZVJPB6FJOLUEIGSTANCNFSM5CQZ66FA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

trishankatdatadog commented 3 years ago

Hi Trishank, Yes and no. In this instance, the bi-weekly Uptane Standards calls have had a strong consensus for many months that the Slow Retrieval Attack prevention should be a SHALL in Uptane v2.0 (which is allowed not to be completely backward compatible). There's no need for a lot of new text. In our bi-weekly discussions, our consensus all along has been that the lack of that SHALL was actually a bug in Uptane Standard v1.x.

Ah, my bad, missed this context.

OTOH, I agree with you that reviews by >=2 people should be the mechanism when there is any significant new text added to the Standard or Deployment Considerations.

Should we make this the default threshold, going fwd? Unfortunately, I don't think there's any way to enforce a different number per review.