Just to add a voice: we’re also experiencing the same issue on our environment, using Azure Devops Pipeline integration and self-hosted build servers.
"The requested security protocol is not supported." -- Azure DevOps task fails after extension update
Sorry to hear that, we’re reverting the extension right now, then update it again with a proper fix.
Sorry for the incovenience.
Still experiencing the same issue, does the fix take some time to rollout?
Extension is rolling out currently, it can take some time for some reasons, but i expect you should have it anytime soon.
meantime that the impacted change is reverted, can you please share how you downgraded to 4.26.0? I tried appending the version at the task (after the @) but the pipeline fails.
@xsurfer if you are hosting you own Azure DevOps server, you can still uninstall manually the extension, and reinstall it by providing the vsix (you can find them here : https://github.com/SonarSource/sonar-scanner-vsts/releases)
But as i said, roll out of the bugfix in ongoing, you should have the new version soon.
Got it, and unfortunately that option won’t apply to us.
Anyway I see now my pipelines running properly.
Thanks @mickaelcaro for your help!
We are using version 4.27.0 and started getting this error. Our pipelines target @4. Has the version 4 task been rolled back also?
Thanks for your help.
Now version sq prepare 4.27.1.
It’s upgraded a couple minutes ago
Yes it is.
Apologies for the disruption this caused here. To help us understand the problem and ensure our tests run on affected environments, could anyone who received the error let us know what version of .NET and OS your agent was running on please?
Updating to the latest version (5.3.1) fixed the problem for us. Old builds might use the old version, create a new build
We are using
- .net 4.73890.0 (.net Framework )
- .NET SDK (5.0.101)
- Microsoft (R)-Build-Engine, Version 16.8.2+25e4d540b for .NET Framework
- Win Server 2016 on VMWare.
Hope this helps.
Did you updated to the newest version?
still shows 5.3.0.
On our side, we had to remove Prepare analysis on SonarQube task from the pipe and recreate it.
Right now it consumes again 5.3.0 or 4.27.0 but works.
It looks somehow that the pipe does not consume the fixed version. IMO some kind of agent cache.
Why this task does not use automatically 5.3.1 or 4.27.1?
Try to recreate prepare analysis on sonarqube task.
Disable the current one and create new. On our side it worked. (Take a look at my last post here).
I have been trying for over an hour now, and I am still seeing the SonarQube Prepare task using 4.27.0 and 5.3.0. The plugin in Azure DevOps Services updated to 5.3.1 over 6 hours ago, and I have tried with both on-prem and hosted build servers with the same error result in the prepare task. I have tried recreating the build task as well as creating a brand new pipeline, and with version 4 of the task I get 4.27.0 and version 5 of the task I get 5.3.0. Any ideas on how we are supposed to be seeing 4.27.1 and 5.3.1? Our pipelines are still not working
============================================================================== Task : Prepare Analysis Configuration Description : Prepare SonarQube analysis configuration Version : 5.3.0 Author : sonarsource Help : Version: 5.3.0. [More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html) ==============================================================================
============================================================================== Task : Prepare Analysis Configuration Description : Prepare SonarQube analysis configuration Version : 4.27.0 Author : sonarsource Help : Version: 4.27.0. [More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html) =====================
@kdodge For me this recreation worked only for 1 pipe. 2nd one started failing. Recreation didn’t help the same as cleaning build agent _tasks. For this case I uninstalled SQ extension for Azure completely (Collection Settings → Extensions), installed again and created new prepataion task. Now it works and shows version 5.3.1.
@mutleyy Wow thank you, that did the trick - uninstalling and reinstalling the entire plugin forces the new version. Just for anyone else that is concerned, you won’t lose your tasks in any classic pipelines they will just show as disabled but once the plugin is reinstalled they are back to normal.
Thanks for the help everyone, pipelines are back up and running now for us
We wanted to give an update on the issue that impacted users of the SonarScanner for .NET (and by extension, the SonarScanner for Azure DevOps) to let you know exactly what happened and what’s coming next.
For a long time now (up to and including v5.4.1 of the SonarScanner for .NET ) TLS 1.0, 1.1, and 1.2 have been the supported protocols for connecting to SonarCloud or a SonarQube server. It was not possible to use the newer TLS 1.3 — which was not ideal as TLS 1.3 offers improvements over former versions such as a faster TLS handshake and being able to use simpler, stronger cipher suites.
With Windows 11 and Windows Server 2022 supporting TLS 1.3, we thought it was time to remove this limitation — moreover, we wanted to turn control back to the Operating System about what protocols could be used.
However, we got into trouble — as our implementation tried to enable TLS 1.3 on systems where TLS 1.3 is not supported (of which there are many).
This resulted in the following exception being thrown on those systems:
Unhandled Exception: System.NotSupportedException: The requested security protocol is not supported.
This morning we re-released the SonarScanner for Azure DevOps with v5.4.1 of the SonarScanner for .NET. This should fix the immediate problem for all users.
- v5.5.1 of the SonarScanner for .NET was released today, which does not blindly try to enable TLS 1.3
- Eventually, we will cut another release of the SonarScanner for .NET with proper TLS 1.3 support (where possible) and that version will be embedded in the SonarScanner for Azure DevOps
We sincerely apologize for the inconvenience and are happy to answer any other questions.