Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: pyca/cryptography
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 42.0.2
Choose a base ref
Loading
...
head repository: pyca/cryptography
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 42.0.4
Choose a head ref
Loading
  • 7 commits
  • 18 files changed
  • 3 contributors

Commits on Feb 3, 2024

  1. backport: initialize openssl's legacy provider in rust (#10323) (#10333)

    * initialize openssl's legacy provider in rust (#10323)
    
    * initialize openssl's legacy provider in rust
    
    as we oxidize we need to do this here to ensure it actually happens
    
    * alex is a comment format pedant
    
    * remove the memleak tests (#10322)
    
    they are fragile, haven't caught regressions, and increasingly pointless
    as we oxidize.
    reaperhulk authored Feb 3, 2024
    Configuration menu
    Copy the full SHA
    0e0e46f View commit details
    Browse the repository at this point in the history

Commits on Feb 16, 2024

  1. fix provider loading take two (#10390) (#10395)

    we previously hoisted this into rust, but we used the try_load feature
    which supposedly retains fallbacks. Something about that doesn't behave
    the way we expect though and the machinery in providers is sufficiently
    complex that we are just going to load the default provider explicitly.
    
    this matches our behavior pre-rust.
    reaperhulk authored Feb 16, 2024
    Configuration menu
    Copy the full SHA
    396bcf6 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    c49a7a5 View commit details
    Browse the repository at this point in the history

Commits on Feb 18, 2024

  1. backport actions m1 switch to 42.0.x (#10415)

    * Check to see if we can use the hosted M1 runners (#10340)
    
    * Stop pretending to be x64 on M1 in CI (#10341)
    
    ---------
    
    Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
    reaperhulk and alex authored Feb 18, 2024
    Configuration menu
    Copy the full SHA
    df314bb View commit details
    Browse the repository at this point in the history

Commits on Feb 19, 2024

  1. Configuration menu
    Copy the full SHA
    7a4d012 View commit details
    Browse the repository at this point in the history

Commits on Feb 21, 2024

  1. Fix ASN.1 issues in PKCS#7 and S/MIME signing (#10373) (#10442)

    * Fix ASN.1 for S/MIME capabilities.
    
    The current implementation defines the SMIMECapabilities attribute
    so that its value is a SEQUENCE of all the algorithm OIDs that are
    supported.
    However, the S/MIME v3 spec (RFC 2633) specifies that each algorithm
    should be specified in its own SEQUENCE:
    
    SMIMECapabilities ::= SEQUENCE OF SMIMECapability
    
    SMIMECapability ::= SEQUENCE {
       capabilityID OBJECT IDENTIFIER,
       parameters ANY DEFINED BY capabilityID OPTIONAL }
    
    (RFC 2633, Appendix A)
    
    This commit changes the implementation so that each algorithm
    is inside its own SEQUENCE. This also matches the OpenSSL
    implementation.
    
    * Fix the RSA OID used for signing PKCS#7/SMIME
    
    The current implementation computes the algorithm identifier used
    in the `digest_encryption_algorithm` PKCS#7 field
    (or `SignatureAlgorithmIdentifier` in S/MIME) based on both the
    algorithm used to sign (e.g. RSA) and the digest algorithm (e.g. SHA512).
    
    This is correct for ECDSA signatures, where the OIDs used include the
    digest algorithm (e.g: ecdsa-with-SHA512). However, due to historical
    reasons, when signing with RSA the OID specified should be the one
    corresponding to just RSA ("1.2.840.113549.1.1.1" rsaEncryption),
    rather than OIDs which also include the digest algorithm (such as
    "1.2.840.113549.1.1.13", sha512WithRSAEncryption).
    
    This means that the logic to compute the algorithm identifier is the
    same except when signing with RSA, in which case the OID will always
    be `rsaEncryption`. This is consistent with the OpenSSL implementation,
    and the RFCs that define PKCS#7 and S/MIME.
    
    See RFC 3851 (section 2.2), and RFC 3370 (section 3.2) for more details.
    
    * Add tests for the changes in PKCS7 signing
    
    * PKCS7 fixes from code review
    
    * Update CHANGELOG
    
    Co-authored-by: Facundo Tuesca <facundo.tuesca@trailofbits.com>
    alex and facutuesca authored Feb 21, 2024
    Configuration menu
    Copy the full SHA
    aaa2dd0 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    fe18470 View commit details
    Browse the repository at this point in the history
Loading
Morty Proxy This is a proxified and sanitized view of the page, visit original site.