[release/8.0] Avoid rooting X509Certificate2 in SslSessionCache by github-actions[bot] · Pull Request #101144 · dotnet/runtime

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

github-actions · 2024-04-16T21:06:09Z

Backport of #101120 to release/8.0-staging

Fixes#101090

/cc @rzikm

Customer Impact

X509Certificates imported from PFX may be temporarily stored on disk. We extended their lifetime in .NET 8.0 (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 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).

…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

dotnet-policy-service · 2024-04-16T21:06:41Z

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:21:02Z

Approved via email

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

rzikmand others added 2 commits April 16, 2024 21:06

Avoid rooting X509Certificate2 in SslSessionCache
8ad6adb

Update src/libraries/System.Net.Security/src/System/Net/Security/SslS…
8b1efc5
…treamPal.Windows.cs Co-authored-by: campersau <buchholz.bastian@googlemail.com>

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

rzikm changed the title ~~[release/8.0-staging] Avoid rooting X509Certificate2 in SslSessionCache~~[release/8.0] Avoid rooting X509Certificate2 in SslSessionCacheApr 17, 2024

rzikm self-assigned this Apr 17, 2024

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

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

karelz approved these changes Apr 17, 2024
View reviewed changes

wfurt 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 0b84eae into release/8.0-stagingApr 23, 2024

jkotas deleted the backport/pr-101120-to-release/8.0-staging branch April 27, 2024 22:49

rzikm modified the milestones: 8.0.x, 8.0.6 May 16, 2024

github-actionsBot locked and limited conversation to collaborators Jun 15, 2024

karelz modified the milestones: 8.0.6, 8.0.7 Jun 25, 2024

Uh oh!

Conversation

github-actionsBot commented Apr 16, 2024• edited by rzikm 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 16, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

github-actionsBot commented Apr 16, 2024• edited by rzikm 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 16, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

github-actionsBot commented Apr 16, 2024• edited by rzikm 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 16, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

github-actionsBot commented Apr 16, 2024• edited by rzikm 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 16, 2024

Uh oh!

rzikm commented Apr 18, 2024

Uh oh!

github-actionsBot commented Apr 16, 2024•
edited by rzikm
Loading

github-actionsBot commented Apr 16, 2024•
edited by rzikm
Loading

github-actionsBot commented Apr 16, 2024•
edited by rzikm
Loading

github-actionsBot commented Apr 16, 2024•
edited by rzikm
Loading

github-actionsBot commented Apr 16, 2024•
edited by rzikm
Loading

github-actionsBot commented Apr 16, 2024•
edited by rzikm
Loading