GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [3.6] bpo-40791: Make compare_digest more constant-time. (GH-23438) by miss-islington · Pull Request #23767 · python/cpython

Conversation

@miss-islington

@miss-islington miss-islington commented Dec 14, 2020 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

The existing volatile left/right pointers guarantee that the reads will all occur, but does not guarantee that they will be used. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between result and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre [email protected]
(cherry picked from commit db95802)

Co-authored-by: Miss Islington (bot) [email protected]

https://bugs.python.org/issue40791

Automerge-Triggered-By: GH:tiran

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@miss-islington
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438)
e04f8ea
The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit db95802)

Co-authored-by: Miss Islington (bot) <[email protected]>
@bedevere-bot bedevere-bot mentioned this pull request Dec 14, 2020
[3.7] bpo-40791: Make compare_digest more constant-time. (GH-20444) #23438
Merged
@bedevere-bot bedevere-bot added type-bug An unexpected behavior, bug, or error type-security A security issue labels Dec 14, 2020
@the-knights-who-say-ni the-knights-who-say-ni added the CLA signed label Dec 14, 2020
@miss-islington

miss-islington commented Dec 14, 2020

Copy link
Copy Markdown
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-bot bedevere-bot added the awaiting review label Dec 14, 2020
@miss-islington

miss-islington commented Dec 14, 2020

Copy link
Copy Markdown
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1 similar comment
@miss-islington

miss-islington commented Dec 14, 2020

Copy link
Copy Markdown
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

tiran
tiran approved these changes Dec 14, 2020
View reviewed changes
@bedevere-bot bedevere-bot added awaiting merge and removed awaiting review labels Dec 14, 2020
@tiran tiran added the 🤖 automerge label Dec 14, 2020
@miss-islington

miss-islington commented Dec 14, 2020

Copy link
Copy Markdown
Contributor Author

@miss-islington and @benjaminp: Status check is done, and it's a success ✅ .

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@miss-islington

miss-islington commented Dec 14, 2020

Copy link
Copy Markdown
Contributor Author

Sorry, I can't merge this PR. Reason: You're not authorized to push to this branch. Visit https://docs.github.com/articles/about-protected-branches/ for more information..

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ned-deily
ned-deily merged commit 8bef9eb into python:3.6 Dec 14, 2020
@bedevere-bot bedevere-bot removed the awaiting merge label Dec 14, 2020
@miss-islington
miss-islington deleted the backport-db95802-3.6 branch December 14, 2020 17:05
@ssbr ssbr mannequin mentioned this pull request Aug 24, 2023
hmac.compare_digest could try harder to be constant-time. #84968
Closed
rickprice pushed a commit to ActiveState/cpython that referenced this pull request Apr 11, 2024
@miss-islington @ssbr @rickprice
CVE-2022-48566 Cherry-pick 8bef9eb
0691da3
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
@rickprice rickprice mentioned this pull request Apr 11, 2024
CVE-2022-48566 Cherry-pick 8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a ActiveState/cpython#44
Merged
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Jun 26, 2024
@miss-islington @ssbr @icanhasmath
CVE-2022-48566 Cherry-pick 8bef9eb
aa83358
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
rickprice pushed a commit to ActiveState/cpython that referenced this pull request Jun 26, 2024
@miss-islington @ssbr @rickprice
CVE-2022-48566 Cherry-pick 8bef9eb
ffb4085
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Jul 30, 2024
@miss-islington @ssbr @icanhasmath
CVE-2022-48566 Cherry-pick 8bef9eb
320504a
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Jul 30, 2024
@miss-islington @ssbr @icanhasmath
CVE-2022-48566 Cherry-pick 8bef9eb
ec30afa
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Aug 6, 2024
@miss-islington @ssbr @icanhasmath
CVE-2022-48566 Cherry-pick 8bef9eb
b6fac51
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
icanhasmath pushed a commit to ActiveState/cpython that referenced this pull request Aug 7, 2024
@miss-islington @ssbr @icanhasmath
CVE-2022-48566 Cherry-pick 8bef9eb
976efb3
bpo-40791: Make compare_digest more constant-time. (pythonGH-23438) (pythonGH-23767)

The existing volatile `left`/`right` pointers guarantee that the reads will all occur, but does not guarantee that they will be _used_. So a compiler can still short-circuit the loop, saving e.g. the overhead of doing the xors and especially the overhead of the data dependency between `result` and the reads. That would change performance depending on where the first unequal byte occurs. This change removes that optimization.

(This is change GH-1 from https://bugs.python.org/issue40791 .)
(cherry picked from commit 3172936)

Co-authored-by: Devin Jeanpierre <[email protected]>
(cherry picked from commit 8bef9eb)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@tiran tiran tiran approved these changes
Reviewers whose approvals may not affect merge requirements

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

type-bug An unexpected behavior, bug, or error type-security A security issue

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

5 participants

@miss-islington @tiran @ned-deily @the-knights-who-say-ni @bedevere-bot
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.