Add test coverage for DirectoryServices.TransformControls by edwardneal · Pull Request #107201 · dotnet/runtime

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

edwardneal · 2024-08-30T17:10:05Z

Relates to PR #101512.

This PR introduces test coverage for DirectoryServices.TransformControls. The method parses five types of control - AsqResponseControl, DirSyncResponseControl, PageResultResponseControl, SortResponseControl and VlvResponseControl.

Each control splits the parsing attempt into three groups:

Conformant: values which conform to the relevant spec, and which we expect to pass.
Invalid: various combinations of poorly-structured values. These should always fail with a BerConversionException.
Nonconformant: values which aren't spec-compliant, but which are parsed anyway because BerConverter is forgiving.

These tests pass on my Windows PC, with different handling for OpenLDAP and earlier versions of Windows. There are a few interesting variations.

Platform variations

Windows mandates that a SEQUENCE's length completely covers the length of its contents. An OCTET STRING with a length which extends beyond the length of its containing SEQUENCE will fail to parse. OpenLDAP does not implement this restriction - if the OCTET STRING overruns the SEQUENCE, it'll be parsed and returned.
On versions of Windows prior to Windows 10, when a zero-length OCTET STRING is parsed as a string (format specifier of a) it will return null. After Windows 10 and in OpenLDAP, it returns a zero-length string. This is a behavioural difference between .NET and .NET Framework (which always returns an empty string.)
OpenLDAP seems to validate a BER element's tag, where Windows does not. If BerConverter expects to find an optional OCTET STRING but actually encounters trailing bytes, OpenLDAP will return null but Windows will return an empty string.
- I expect this is because the trailing bytes' values are 0x80. Windows treats this as a length, where bit 7 is set (indicating a long-form length) and bits 0-6 are zero (indicating that the next zero bytes of the buffer contain the length.)

Errata

If an OCTET STRING contains a trailing 0x80 byte which is an invalid Unicode character, BerConverter won't handle the DecoderFallbackException - that exception will just bubble up to the caller. There's a test to verify this behaviour, but I'm pretty sure this is a bug.

dotnet-policy-service · 2024-08-30T17:10:33Z

Tagging subscribers to this area: @dotnet/area-system-directoryservices, @jay98014
See info in area-owners.md if you want to be subscribed.

* There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes.

Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

buyaa-n · 2024-09-11T22:51:37Z

Thank you @edwardneal looks its covered scenarios well, overall the PR LGTM

Not sure if we should fix it or leave it as is, tag @bartonjs @jay98014 @steveharter @kumarravik78c for opinions about this

buyaa-n

Thank you @edwardneal

buyaa-n · 2024-09-26T18:32:31Z

We can fix this later if needed, going to merge this PR to unblock #101512.

edwardneal · 2024-09-27T05:47:10Z

Thanks @buyaa-n; I can see that my tests passed, so I'll merge into the other PR and re-test in the next few days.

) * Added tests for server response DirectoryControls * Addressing platform inconsistencies * There are looser rules in OpenLDAP when an octet string exceeds the length of its containing sequence. * Windows 8.1 and below treats trailing 0x80 bytes differently to every other platform. * Added a test which covers an octet string containing invalid Unicode bytes. * Handle differing .NET Framework behaviour Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length * Update SortResponseControlTests.cs

Added tests for server response DirectoryControls
fa7a2af

ghost added the area-System.DirectoryServices label Aug 30, 2024

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Aug 30, 2024

build-analysisBot mentioned this pull request Aug 30, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

edwardneal added 2 commits August 31, 2024 08:32

Handle differing .NET Framework behaviour
10ae098
Also handle changes to the "a" format string: Winldap in Windows 10 is stricter when a SEQUENCE's contents overflow its length

build-analysisBot mentioned this pull request Aug 31, 2024
Assertion failed (pThread->m_StateNC & Thread::TSNC_OwnsSpinLock) == 0#104449
Closed

Update SortResponseControlTests.cs
cbd5135

edwardneal marked this pull request as ready for review September 1, 2024 06:42

edwardneal mentioned this pull request Sep 1, 2024
Switch DirectoryControl to use AsnWriter, AsnDecoder #101512
Merged

buyaa-n requested review from bartonjs, jay98014, kumarravik78c and steveharter September 11, 2024 22:52

buyaa-n approved these changes Sep 26, 2024
View reviewed changes

buyaa-n merged commit 52a51e8 into dotnet:mainSep 26, 2024

edwardneal deleted the directorycontrol-transformcontrols-tests branch September 27, 2024 05:45

github-actionsBot locked and limited conversation to collaborators Oct 27, 2024