[release/6.0] Avoid rooting X509Certificate2 in SslSessionCache by rzikm · Pull Request #101167 · dotnet/runtime

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

rzikm · 2024-04-17T08:02:36Z

Backport of #101120 to release/6.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates may be stored on disk. We extended their lifetime in .NET 6.0.27 (Feb release) (see details below) and they might not be deleted by the process. For short-lived processes, it may lead to disk space exhaustion.
Reported by a large service -- operating in environment with limited disk space and short-lived processes.

Technical details

PR #79898 fixed SslStream.IsMutuallyAuthenticated property for scenarios with TLS resumed sessions -- we found out that in some older windows versions we cannot reliably query whether the resumed session used a client certificate (important information for the property to be accurate). As a workaround, we added a reference to the X509Certificate instance on the record in the internal TLS session cache, which prolongs the lifetime of the X509Certificate.

X509Certificates constructed by importing PFX certificate have their keys stored in a key file on disk. Dispose() of the certificate is implemented such that the key file is cleaned up. Keeping a reference to the certificate from TLS session cache prevents this cleanup to happen (regardless whether user properly disposed of the certificate). The key file will then outlive the process it was created in. In scenarios with many short-lived processes which do mutually-authenticated HTTPS requests with such certificates will lead to accumulation of those files, potentially exhausting disk space.

Since we don't use the value of the certificate in any part of the code, only the knowledge whether one was used or not, we can replace the cert reference by a simple bool flag which does not extend the lifetime of the certificate.

Regression

Yes, introduced in .NET 6.0.27 (Feb release) - fixes to SslStream.IsMutuallyAuthenticated in servicing PR #92684. Original regression .NET 8 in PR #79898.

Testing

Verified on the provided isolated repro from the original issue #101090.
E2E verification done by reporting customer via provided private bits.

Risk

Low, the issue is well understood and the fix is small and contained to affected code path (using client certificates on Windows).

…et#101120) * Avoid rooting X509Certificate2 in SslSessionCache * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com> --------- Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-17T08:03:10Z

Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

rzikm · 2024-04-18T11:20:54Z

Approved via email

rzikm · 2024-04-23T10:28:22Z

CI Failures are known and unrelated

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

ghost added the area-System.Net.Security label Apr 17, 2024

dotnet-policy-serviceBot assigned rzikm Apr 17, 2024

build-analysisBot mentioned this pull request Apr 17, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed

karelz added this to the 6.0.x milestone Apr 17, 2024

rzikm requested a review from wfurt April 17, 2024 13:28

wfurt approved these changes Apr 17, 2024
View reviewed changes

karelz approved these changes Apr 17, 2024
View reviewed changes

rzikm added the Servicing-approved Approved for servicing release label Apr 18, 2024

rzikm merged commit 223f182 into dotnet:release/6.0-stagingApr 23, 2024

github-actionsBot locked and limited conversation to collaborators May 24, 2024

karelz modified the milestones: 6.0.x, 6.0.32 Jun 25, 2024

Uh oh!

Conversation

rzikm commented Apr 17, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Technical details

Regression

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented Apr 17, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

rzikm commented Apr 23, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

rzikm commented Apr 17, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Technical details

Regression

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented Apr 17, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

rzikm commented Apr 23, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

rzikm commented Apr 17, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Technical details

Regression

Testing

Risk

Uh oh!

dotnet-policy-serviceBot commented Apr 17, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

rzikm commented Apr 23, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

rzikm commented Apr 17, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Customer Impact

Technical details

Regression

Testing

rzikm commented Apr 17, 2024•
edited
Loading

rzikm commented Apr 17, 2024•
edited
Loading

rzikm commented Apr 17, 2024•
edited
Loading

rzikm commented Apr 17, 2024•
edited
Loading

rzikm commented Apr 17, 2024•
edited
Loading