Fix typo

"New code should be written with HttpClient" != "No new code should be written with HttpClient" So maybe "No new code should be written with WebClient" is better😄.

There is a 'No' at the start of this sentence; I believe it already says what you think you're making it say by changing it ;)

<h3>Snyk has created this PR to fix one or more vulnerable packages in the rubygems dependencies of this project.</h3>

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • Gemfile

<details> <summary>⚠️ <b>Warning</b></summary>

Failed to update the Gemfile.lock, please update manually before merging.

</details>

Vulnerabilities that will be fixed

With an upgrade:

Severity	Priority Score (*)	Issue	Breaking Change	Exploit Maturity
	461/1000 <br/> Why? Recently disclosed, Has a fix available, CVSS 3.3	Improper Input Validation <br/>SNYK-RUBY-REXML-1244518	No	No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: <img src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiJkMjQ0ZTkyMS02OTc5LTRjOTEtYjg0OC00ZDJmNGYzYzMzMzEiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6ImQyNDRlOTIxLTY5NzktNGM5MS1iODQ4LTRkMmY0ZjNjMzMzMSJ9fQ==" width="0" height="0"/> 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

The following .NET updates were released in April 2021. This issue will be updated if there are any additional releases during the month.

<h2>.NET </h2>

• .NET April 2021 Updates – 5.0.5
  • .NET 5.0.5 and .NET SDK 5.0.202 (Release Notes | Download)

<h2>.NET Support Policies</h2> Microsoft support policies are defined in the following documents:

• Microsoft .NET Support Policy
• .NET Core OS Lifecycle Policy

NuGet package restore broken on .NET 5+ with Removal of Trust of Verisign CA

NuGet package signing verification relies on the VeriSign Universal Root Certification Authority as part of establishing a chain-of-trust for NuGet packages. VeriSign Universal Root Certification Authority was recently removed from NSS and ca-certificates packages. This removal effectively breaks NuGet package signing verification, which has the result of breaking the ability to restore NuGet packages.

This break in behavior is only observed with .NET 5 and .NET 6, which have NuGet package verification enabled (and it cannot be disabled). NET 5 NuGet Restore Failures on Linux distributions has been observed on some distros already and we expect it to become pervasive quickly as more distros are updated to include more recent version of NSS and ca-certificates (with the VeriSign CA removed). We are in the process of releasing updated builds of .NET 5 and .NET 6 that have NuGet package verification disabled on Linux and macOS.

We need developers, companies, and commercial providers to install (or otherwise use) updated builds of .NET 5 and .NET 6 if you rely on those .NET versions on Linux. If you adopt the updated .NET versions soon, you should not observe a break in functional behavior, and will be able to confidently update to newer versions of NSS and ca-certificates packages.

Discussion

Please share your feedback on this topic and see what others are saying at:

https://github.com/NuGet/Home/issues/10712

Updated .NET builds

New .NET builds will be provided with NuGet package verification disabled on Linux and macOS. The following are the expected release dates:

• .NET SDK 5.0.202 -- April 6, 2021.
• .NET 6 Preview 3 -- April 8, 2021.

New container images will be published for Alpine, Debian, and Ubuntu on both of these dates, for the respective releases.

These builds include significant additional functionality beyond disabling NuGet package verification. We originally planned to release these builds as regular releases for all supported operating systems and architectures, targeting April 13th. We made two changes from our original release plan: earlier release dates and include the change in NuGet functionality for Linux and macOS.

Who is affected

.NET 5+ users will be affected on any operating system that has removed the VeriSign Universal Root Certification Authority. We are maintaining a list of Linux distros that are known to be affected.

nuget.exe is sometimes used on Linux with Mono. This scenario is not affected.

There has been an industry-wide movement to distrust the VeriSign root CA, including companies like Apple, Google, Microsoft, and Mozilla. This may mean that at anytime in the future, Apple and Microsoft can remove VeriSign Universal Root Certification Authority from their trusted root CA list.

Solution

The NuGet team has disabled the package verification feature for macOS and Linux. If needed, we will disable the feature for Windows at a later time. This change will be available in the updated .NET builds covered earlier.

We are also talking to some Linux distro package maintainers to ask them to delay the removal of the VeriSign Universal Root Certification Authority (for code signing only). Even a month of grace would help a lot, to enable .NET users on Linux to adopt the newer .NET 5 and .NET 6 builds.

To clarify, this change does not affect .NET Core 3.1 and earlier versions. It does not affect .NET Framework. It does not affect any .NET functionality on Windows, at least not at this time.

More Context

We observed NuGet Restore Issues on Debian Family Linux Distros in January, 2021. This led us to discover that there has been an industry-wide movement to remove the VeriSign Universal Root Certification Authority.

NuGet has historically relied on two key certificates:

• NuGet Microsoft Author Signing Certificate Update - Expired January 27th, 2021
• NuGet.org Repository Signing Certificate Update - Expires April 14th, 2021

After those certificates expire, the NuGet client falls back to timestamp verification, which enables package verification to still function. The timestamp verification relies on VeriSign root certificate authority. The absence of this root certificate authority being available on a machine means that timestamp verification is no longer functional, which causes package signature verification to fail.

Security is very important to us. We are putting together a plan to use a new system that will allow us to re-enable package signing verification on all supported operating systems. We will have more to share on our future plans once we are sure that all systems are once again functional.

.NET 5 NuGet Restore Failures on Linux distributions provides more details on error messages, affected environments, and solutions.

<h3>Snyk has created this PR to fix one or more vulnerable packages in the rubygems dependencies of this project.</h3>

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • Gemfile

<details> <summary>⚠️ <b>Warning</b></summary>

Failed to update the Gemfile.lock, please update manually before merging.

</details>

Vulnerabilities that will be fixed

With an upgrade:

Severity	Priority Score (*)	Issue	Breaking Change	Exploit Maturity
	576/1000 <br/> Why? Recently disclosed, Has a fix available, CVSS 5.6	Deserialization of Untrusted Data <br/>SNYK-RUBY-KRAMDOWN-1087436	Yes	No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: <img src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiJmNzAzNzlkNy0xNzI5LTRhNmItOWJiMS1hZmVmZTRjYjQ5YWIiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6ImY3MDM3OWQ3LTE3MjktNGE2Yi05YmIxLWFmZWZlNGNiNDlhYiJ9fQ==" width="0" height="0"/> 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

For all those who can't pull master, it should have renamed to main.

To preserve refspec to patches and branches, just changing the heads/master to heads/main should work.

[remote "origin"]
	url = https://github.com/dotnet/your-repo
-	fetch = +refs/heads/master:refs/remotes/origin/master
+	fetch = +refs/heads/main:refs/remotes/origin/master
	tagopt = --no-tags
[branch "master"]
	remote = origin
-	merge = refs/heads/master
+	merge = refs/heads/main

Putting this out there, if anyone else facing similar issue with git.

Another approach might be to wrap it like this: https://stackoverflow.com/a/33942013/11635 There's an evolution of that with expiration semantics too (there are some tests if one wanted to port it to C#)