Skip to content

refactor(pkce): use OpenSSL for PKCE primitives - #38

Open
LimiNode wants to merge 2 commits into
mainfrom
refactor/pkce-openssl
Open

refactor(pkce): use OpenSSL for PKCE primitives#38
LimiNode wants to merge 2 commits into
mainfrom
refactor/pkce-openssl

Conversation

@LimiNode

@LimiNode LimiNode commented Sep 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Owner

Summary

  • rename the PKCE utility header to utils/pkce.hpp
  • replace the hmac-cpp PKCE dependency with OpenSSL RAND_bytes and EVP_Digest
  • remove the hmac-cpp submodule and CMake fallback
  • eliminate modulo bias in verifier generation while preserving the 43..128 length contract
  • add the RFC 7636 Appendix B S256 test vector
  • keep MSVC compatibility with the Windows max macro

Verification

  • auth suite: 5/5 passed
  • C++11 standalone PKCE test: passed
  • C++11 full smoke build: passed
  • OAuth PKCE example build: passed
  • all 7 CI jobs passed on head b2ecf40

Packaging integration is continued in #37.

@LimiNode
refactor(pkce): use OpenSSL for PKCE primitives
28a0d62 
Constraint: preserve C++11 support and the existing verifier length contract.

Rejected: hmac-cpp dependency | redundant with the existing OpenSSL dependency and unavailable in official vcpkg.

Directive: keep cryptographic helpers private under kurlyk::utils::detail.

Confidence: high

Scope-risk: moderate
@LimiNode
fix(pkce): avoid Windows max macro expansion
b2ecf40 
Constraint: preserve MSVC support without defining global Windows macro policy.

Confidence: high

Scope-risk: narrow
@LimiNode LimiNode mentioned this pull request Sep 19, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@LimiNode