Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable installing binaries from multiple domains #2123

Open
richlander opened this issue Feb 8, 2025 · 6 comments
Open

Enable installing binaries from multiple domains #2123

richlander opened this issue Feb 8, 2025 · 6 comments

Comments

@richlander
Copy link
Member

richlander commented Feb 8, 2025

Related: #2121
Blocking: dotnet/core#9724

The following are safe domains:

  • download.visualstudio.microsoft.com
  • builds.dotnet.microsoft.com

This code needs to change:

if(!(installerUrl as string).startsWith('https://download.visualstudio.microsoft.com/'))
{
const releaseJsonErr = new DotnetInvalidReleasesJSONError(new EventBasedError('DotnetInvalidReleasesJSONError',
`The url: ${installerUrl} is hosted on an unexpected domain.
We cannot verify that .NET downloads are hosted in a secure location, so we have rejected .NET. The url should be download.visualstudio.microsoft.com.
Please report this issue so it can be remedied or investigated.`), getInstallFromContext(this.context));

I'm hoping we can target this change for 2.2.8. I'd propose merging the PR above one week after the extension was released. After a week, we're likely well into the long tail.

@baronfel
Copy link
Member

Frankly I'm not sure we should be applying any additional checks on the content of the releases.json file. If a) we have that file, and b) we can use a MS public signature to verify the contents (this would require publishing sidecar signature files) then we should just trust it.

@richlander
Copy link
Member Author

That is a good point. We should be doing something similar to:

dotnet/core#7641 (comment)

I can imagine two things:

  • Validate the signature / checksum.
  • Validate that the domain ends in microsoft.com.

Validating the specific domain seems like tighter coupling (as demonstrated) than we need/want.

@nagilson
Copy link
Member

We can certainly simplify the check to be whether the domain ends in microsoft.com.

We do validate the hashes on the files but we need to make sure that the releases.json is valid as well, do we have an easy place to get hashes for that as of right now? If that is on a web store as well, then that would need to be validated.

@richlander
Copy link
Member Author

I'm hoping to get checksums deployed beside each asset. I have a tracking issue for it. I'm hope that will happen this month.

@nagilson
Copy link
Member

Extracting the domain from a string is actually a pretty hard problem with a lot of edge cases. I think I'm going to add builds.dotnet.microsoft.com to the list of acceptable terms for now as a stopgap and then if the checksums come out this month we can change to doing that.

@richlander
Copy link
Member Author

StartsWith has a lot going for it w/rt simplicity.

nagilson added a commit to nagilson/vscode-dotnet-runtime that referenced this issue Feb 10, 2025
Resolves dotnet#2126
Resolves dotnet#2125

Workaround fix for dotnet#2123

We have a list of possible safe domains as part of our threat model which is needed to verify the source of truth when we run executables with elevated permission. In the past releases json only hosted downloads on `download.visualstudio.microsoft.com` but now it can be `builds.dotnet.microsoft.com`. I've added some more urls to our azure front door and other CDNs in the event that we decide to change to those.

The long term fix for this would be if signatures are ever published for releases.json to verify those instead, but that is not ready yet and this change needs to go in.
nagilson added a commit that referenced this issue Feb 11, 2025
* Support other possible future domains for the installer files.

Resolves #2126
Resolves #2125

Workaround fix for #2123

We have a list of possible safe domains as part of our threat model which is needed to verify the source of truth when we run executables with elevated permission. In the past releases json only hosted downloads on `download.visualstudio.microsoft.com` but now it can be `builds.dotnet.microsoft.com`. I've added some more urls to our azure front door and other CDNs in the event that we decide to change to those.

The long term fix for this would be if signatures are ever published for releases.json to verify those instead, but that is not ready yet and this change needs to go in.

* Fix the test

* Change URLs to possible likely download stores

Co-authored-by: Rich Lander <[email protected]>

---------

Co-authored-by: Rich Lander <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants