Conversation
| @@ -0,0 +1,22 @@ | |||
| // Licensed to the .NET Foundation under one or more agreements. | |||
There was a problem hiding this comment.
I'm not sure what the "remove" is for. If it's the file, OK. If it's the license header, no... it should still be around.
There was a problem hiding this comment.
I meant the whole file, initially it was doing a bit more but after couple of iterations it ended up being redundant...
| } | ||
| // user explicitly asks for TLS 1.3 but their policy is not compatible with TLS 1.3 | ||
| throw new SslException( | ||
| SR.Format(SR.net_ssl_encryptionpolicy_notsupported, policy)); |
There was a problem hiding this comment.
This seems like a thing that we might want to change later. If I said, TLS 1.2 or TLS 1.3 and then didn't include any TLS 1.3 ciphersuites then the "TLS 1.2" part of the or still seems to apply, just as if the remote didn't support TLS 1.3, or the TLS 1.3 ciphersuites I did.
That said, if the TLS 1.3 rules are "if both sides support TLS 1.3, but can't agree on a ciphersuite, fail", then maybe this is okay?
Exception now and no-exception-later is the happier path, so this is fine if we can't justify my thought experiment.
There was a problem hiding this comment.
@bartonjs actually this happens when user wants TLS1.3 (protocols include it) but user specified ciphersuites in such a way that TLS1.3 cannot happen (none TLS 1.3 ciphersuites included in a policy) - so user contradicted themselves
There was a problem hiding this comment.
so user contradicted themselves
Yeah, I know. The cases where this would come up seem vanishingly small, but the easy one is trying to build something like SslLabs, where you connect, see what ciphersuite got negotiated, remove it from the allow list, and try again. When the last TLS 1.3 ciphersuite gets removed the next call throws.
The throw just means that we're pushing the knowledge of TLS 1.3 vs prior ciphersuites onto the caller. Which, given we are encouraging people to just use system defaults (after configuring their system, if they don't like the out-of-the-box answer), seems okay for now.
There was a problem hiding this comment.
I got mixed feelings for that - if user doesn't want to know about TLS 1.3 they should use None for protocols in which case we won't throw.
Perhaps let's leave as is and perhaps change it when someone complains this is not intuitive?
I don't feel strongly either way - allowing this would simplify a code a bit but feels to me that asking for TLS 1.3 and not passing any ciphers which could allow us to do so is a user bug - for scenarios like SslLabs they will have to understand the cipher suites either way...
src/Native/Unix/System.Security.Cryptography.Native/configure.cmake
Outdated
Show resolved
Hide resolved
src/System.Net.Security/src/System/Net/Security/CipherSuitesPolicy.Linux.cs
Outdated
Show resolved
Hide resolved
src/System.Net.Security/src/System/Net/Security/CipherSuitesPolicy.Linux.cs
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,22 @@ | |||
| // Licensed to the .NET Foundation under one or more agreements. | |||
There was a problem hiding this comment.
I'm not sure what the "remove" is for. If it's the file, OK. If it's the license header, no... it should still be around.
src/System.Net.Security/src/System/Net/Security/TlsCipherSuiteData.OpenSslName.Lookup.Linux.cs
Outdated
Show resolved
Hide resolved
src/System.Net.Security/tests/FunctionalTests/SslStreamNegotiatedCipherSuiteTest.cs
Outdated
Show resolved
Hide resolved
|
finally green on the CI. Left:
|
|
/azp run |
|
test this please |
|
/azp help |
Supported commands
help:
Get descriptions, examples and documentation about supported commands
Example: help "command_name"
run:
Run all pipelines or a specific pipeline for this repository using a comment. Use
this command by itself to trigger all related pipelines, or specify a pipeline
to run.
Example: "run" or "run pipeline_name"
See additional documentation.
|
|
/azp run corefx-ci |
|
@safern @dotnet/dnceng how do I get this picked up by CI? this has already been running correctly, then it got green and it doesn't get picked up by CI anymore |
|
Maybe it is related to it being a draft PR? Can you try closing and reopening? |
|
/azp run |
|
/azp run |
|
/azp run |
|
@safern probably related, but seems we shouldn't be doing anything special for draft PRs, right? people use them to test stuff on CI, everything else I can do locally without opening any PR |
No description provided.