Bump pyspnego from 0.8.0 to 0.9.1

[dependabot]

Bumps pyspnego from 0.8.0 to 0.9.1.

Release notes

Sourced from pyspnego's releases.

v0.9.1

What's Changed

• Set NTLM Negotiate Version field by @​jborean93 in jborean93/pyspnego#65

0.9.1 - 2023-06-14

• Always set the NTLMSSP_REQUEST_VERSION flag on the NTLM Negotiate message
  • This aligns the behaviour with how SSPI generates this message

Full Changelog: jborean93/pyspnego@v0.9.0...v0.9.1

v0.9.0

What's Changed

• Fix up try/import checks by @​jborean93 in jborean93/pyspnego#62
• Add support for DCE style authentication. by @​jborean93 in jborean93/pyspnego#63
• Prepare for v0.9.0 release by @​jborean93 in jborean93/pyspnego#64

0.9.0 - 2023-04-29

• Added the spnego.ContextReq.dce_style flag to enable DCE authentication mode
  • This is used in protocols like RPC/DCE
• The value for spnego.iov.BufferType.sign_only on SSPI has changed from representing SECBUFFER_MECHLIST to SECBUFFER_READONLY_WITH_CHECKSUM
  • This is to better match what sign_only means when using it with GSSAPI
  • It is needed to support RPC encryption and signature headers on SSPI
  • The use of SECBUFFER_MECHLIST is not seen in any examples in the wild and is most likely an internal flag
• Added the IOV buffer type spnego.iov.BufferType.data_readonly
  • For SSPI this corresponds to SECBUFFER_DATA | SECBUFFER_READONLY
  • For GSSAPI this corresponds to GSS_IOV_BUFFER_TYPE_EMPTY
  • As GSSAPI has no actual equivalent to this the empty buffer type is used which in testing results in compatible buffers
  • This is used for DCE/RPC wrapping when the PDU header and sec trailer are not signed but are included in the wrap_iov buffers.
• Added limited support for wrap_iov and unwrap_iov in the Python NTLM context provider.
  • This currently only supports spnego.iov.BufferType.header, spnego.iov.BufferType.data, spnego.iov.BufferType.sign_only, spnego.iov.BufferType.data_readonly, and spnego.iov.BufferType.stream
  • header
    • wrap_iov: Used to place the resulting signature in the buffer
    • unwrap_iov: Used as the signature source for validation
  • data
    • wrap_iov: Data to be encrypted/sealed
    • unwrap_iov: Data to be decrypted/unsealed
  • sign_only
    • wrap_iov: Data to be included in the signature/header generation
    • unwrap_iov: Data to be included in the signature/header verification
  • data_readonly is treated the same as sign_only
  • stream
    • wrap_iov: Not supported
    • unwrap_iov: Contains the full value to decrypt with the headers in the beginning, must be coupled with a subsequent data buffer of the type data to place the decrypted value into
  • The behaviour used here is modelled as closely as possible to how SSPI works but not all the permutations have been tested.
  • The header/signature will be generated from the data, sign_only, data_readonly values concat together in the order they are provided.
• Added the query_message_sizes() function on a context to retrieve the important message sizes
  • Currently this only contains the size of the message header, also known as the signature or security trailer

... (truncated)

Changelog

Sourced from pyspnego's changelog.

0.9.1 - 2023-06-14

• Always set the NTLMSSP_REQUEST_VERSION flag on the NTLM Negotiate message
  • This aligns the behaviour with how SSPI generates this message

0.9.0 - 2023-04-29

• Added the spnego.ContextReq.dce_style flag to enable DCE authentication mode
  • This is used in protocols like RPC/DCE
• The value for spnego.iov.BufferType.sign_only on SSPI has changed from representing SECBUFFER_MECHLIST to SECBUFFER_READONLY_WITH_CHECKSUM
  • This is to better match what sign_only means when using it with GSSAPI
  • It is needed to support RPC encryption and signature headers on SSPI
  • The use of SECBUFFER_MECHLIST is not seen in any examples in the wild and is most likely an internal flag
• Added the IOV buffer type spnego.iov.BufferType.data_readonly
  • For SSPI this corresponds to SECBUFFER_DATA | SECBUFFER_READONLY
  • For GSSAPI this corresponds to GSS_IOV_BUFFER_TYPE_EMPTY
  • As GSSAPI has no actual equivalent to this the empty buffer type is used which in testing results in compatible buffers
  • This is used for DCE/RPC wrapping when the PDU header and sec trailer are not signed but are included in the wrap_iov buffers.
• Added limited support for wrap_iov and unwrap_iov in the Python NTLM context provider.
  • This currently only supports spnego.iov.BufferType.header, spnego.iov.BufferType.data, spnego.iov.BufferType.sign_only, spnego.iov.BufferType.data_readonly, and spnego.iov.BufferType.stream
  • header
    • wrap_iov: Used to place the resulting signature in the buffer
    • unwrap_iov: Used as the signature source for validation
  • data
    • wrap_iov: Data to be encrypted/sealed
    • unwrap_iov: Data to be decrypted/unsealed
  • sign_only
    • wrap_iov: Data to be included in the signature/header generation
    • unwrap_iov: Data to be included in the signature/header verification
  • data_readonly is treated the same as sign_only
  • stream
    • wrap_iov: Not supported
    • unwrap_iov: Contains the full value to decrypt with the headers in the beginning, must be coupled with a subsequent data buffer of the type data to place the decrypted value into
  • The behaviour used here is modelled as closely as possible to how SSPI works but not all the permutations have been tested.
  • The header/signature will be generated from the data, sign_only, data_readonly values concat together in the order they are provided.
• Added the query_message_sizes() function on a context to retrieve the important message sizes
  • Currently this only contains the size of the message header, also known as the signature or security trailer

Commits

• 3c1d1a8 Set NTLM Negotiate Version field (#65)
• c3db058 Prepare for v0.9.0 release (#64)
• 617a72a Add support for DCE style authentication. (#63)
• 95d9878 Fix up try/import checks (#62)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)