Skip to content

GitLab

C
cryptography
Switch branch/tag
  1. 21 Jul, 2020 5 commits
  3. 20 Jul, 2020 6 commits
  5. 19 Jul, 2020 8 commits
  7. 18 Jul, 2020 3 commits
  9. 15 Jul, 2020 1 commit
  11. 06 Jul, 2020 5 commits
  13. 05 Jul, 2020 5 commits
  15. 02 Jul, 2020 1 commit
  17. 28 Jun, 2020 1 commit
  19. 26 Jun, 2020 3 commits
  21. 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
provided.

[1] https://github.com/pyca/cryptography/pull/5256
[2] https://github.com/python/typeshed/pull/4238

* Actually test the return value here

* Fix formatting
      7e30f0f9203f
    • 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
anyway:

> 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.
      26178d7b046a