Skip to content
This repository has been archived by the owner on May 14, 2022. It is now read-only.

JENKINS-51577 #25

Merged
merged 1 commit into from
May 3, 2019
Merged

JENKINS-51577 #25

merged 1 commit into from
May 3, 2019

Conversation

res0nance
Copy link
Contributor

Enable strong cryptography for .NET 4.6
https://issues.jenkins-ci.org/browse/JENKINS-51577

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it have any side effects for older runtime versions

@res0nance
Copy link
Contributor Author

On a server with TLSv1.2 Enabled
On .NET 4.5 it does nothing
On .NET 4.7 it allows it to download the jar

@oleg-nenashev oleg-nenashev self-assigned this Apr 27, 2019
@oleg-nenashev
Copy link
Member

Thanks @res0nance ! This issue was around for a while, but I have never got to it. I will see whether it is possible to have a fix on the WinSW side (maybe a new executable for winsw/winsw#302), but this improvement definitely makes sense

@res0nance
Copy link
Contributor Author

@oleg-nenashev I tried to use service point manager in that code fix originally but that still refused to download the jar. Since I can't seem to compile it locally it was a little difficult to debug.

@oleg-nenashev oleg-nenashev merged commit 8cff172 into jenkinsci:master May 3, 2019
@oleg-nenashev
Copy link
Member

Thanks @res0nance ! I have released the module and created a PR against the Jenkins Core: jenkinsci/jenkins#4010

@oleg-nenashev
Copy link
Member

I'd guess this is no longer required for WinSW 2.6.0+ after winsw/winsw#394 . Could you please confirm it @res0nance @NextTurn ?

@res0nance
Copy link
Contributor Author

I'm not sure about this. That PR seems to only affect Windows 7 and Server? Perhaps the right fix is to remove that condition and this change.

Unfortunately I do not have a windows machine I can use to test due to the current working situation.

@nxtn
Copy link
Member

nxtn commented Apr 8, 2020

All-in-one article Transport Layer Security (TLS) best practices with the .NET Framework.

Summary

If your app targets .NET Framework 4.7 or later versions

Don't do anything.

If your app targets .NET Framework 4.6 - 4.6.2

Set Switch.System.Net.DontEnableSystemDefaultTlsVersions to false.

If your app targets .NET Framework 3.5

winsw/winsw#394

If your app targets, or runs on, .NET Framework 4.6 or later versions

If your app runs on .NET Framework 4.6, but targets an earlier version

This PR.

If your app runs on .NET Framework 4.7 or later versions, but targets an earlier version

Set Switch.System.Net.DontEnableSystemDefaultTlsVersions to false.

Support for TLS 1.1/1.2

Supported and enabled by default on Windows 8.0 and later versions.

Not supported on Windows Vista.

@nxtn
Copy link
Member

nxtn commented Apr 8, 2020

Anyway, I think we should set app context switches programmatically rather than depending on the use of .exe.config file.

@oleg-nenashev
Copy link
Member

Anyway, I think we should set app context switches programmatically rather than depending on the use of .exe.config file.

.exe.config is a workaround for downstream WinSW consumers who cannot add code there. Wit the new WinSW versions we indeed can start tearing down this workaround on the Jenkins side

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants