1. 21 Jul, 2020 5 commits
  2. 20 Jul, 2020 6 commits
  3. 19 Jul, 2020 8 commits
  4. 18 Jul, 2020 3 commits
  5. 15 Jul, 2020 1 commit
  6. 06 Jul, 2020 5 commits
  7. 05 Jul, 2020 5 commits
  8. 02 Jul, 2020 1 commit
  9. 28 Jun, 2020 1 commit
  10. 26 Jun, 2020 3 commits
  11. 25 Jun, 2020 2 commits
    • Jakub Stasiak's avatar
      Disallow ttl=None in (Multi)Fernet.decrypt_at_time() (#5280) · 7e30f0f9203f
      Jakub Stasiak authored
      * Disallow ttl=None in (Multi)Fernet.decrypt_at_time()
      Since the introduction of the _at_time() methods in #5256[1] there's
      been this little voice in the back of my mind telling me that maybe it's
      not the best idea to allow ttl=None in decrypt_at_time(). It's been like
      this for convenience and code reuse reasons.
      Then I submitted a patch for cryptography stubs in typeshed[2] and I had
      to decide whether to define decrypt_at_time()'s ttl as int and be
      incompatible with cryptography's behavior or Optional[int] and advertise
      an API that can be misused much too easily. I went ahead with int.
      Considering the above I decided to propose this patch. Some amount of
      redundancy (and a new test to properly cover the
      MultiFernet.decrypt_at_time() implementation) is a price to prevent
      clients from shooting themselves in the foot with the tll=None gun since
      setting ttl to None disabled timestamp checks even if current_time was
      [1] https://github.com/pyca/cryptography/pull/5256
      [2] https://github.com/python/typeshed/pull/4238
      * Actually test the return value here
      * Fix formatting
    • David Benjamin's avatar
      Fix up crl_delta_crl_indicator.pem. (#5283) · 26178d7b046a
      David Benjamin authored
      The CRL is missing a CRL number and should mark the delta CRL extension
      as critical. RFC 5280 says the following:
      Section 5.2.3:
      > CRL issuers conforming to this profile MUST include this extension
      > [CRL number] in all CRLs and MUST mark this extension as
      > non-critical.
      Section 5.2.4:
      > The delta CRL indicator is a critical CRL extension that identifies a
      > CRL as being a delta CRL.
      > When a conforming CRL issuer generates a delta CRL, the delta CRL
      > MUST include a critical delta CRL indicator extension.
      Sadly, RFC 5280 is often unclear about the difference between issuer
      requirements and verifier requirements, but test certificates should
      conform to issuer requirements where possible, in case the underly
      library becomes stricter. Section 5.2.4 includes further text which
      implies a delta CRL without a CRL number is unusable for a verifier
      > A complete CRL and a delta CRL MAY be combined if the following four
      > conditions are satisfied:
      > [...]
      >   (d)  The CRL number of the complete CRL is less than the CRL number
      >        of the delta CRL.  That is, the delta CRL follows the complete
      >        CRL in the numbering sequence.
      Note I have not updated the signature in crl_delta_crl_indicator.pem.
      The test does not care, and it is unclear which key to sign it with.