Add spec for proxy support

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.

[Flor Chacón (florelis)]

Adding spec for #190

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

I think if we do the proxy configuration at wininet, DO, restclient level, then winget configuration should already be covered. Is there something I missed?

[Flor Chacón (florelis)]

I'm not familiar with the configuration code so I may be wrong, but the way I understand it is that that part of the code is mostly independent of the "package manager" side of things and some of it is written in .net. That's why I didn't include it in this.

I also don't know what network connections are done on that side. The only one that comes to mind is downloading the PS modules for each resource. If that's the only one, I don't see much case on going through the work of making it available on that side

[JohnMcPMS]

If PowerShell allows control over a proxy, then we could tunnel settings along to it. Currently, the proxy would only affect the ability to retrieve a configuration document from the internet.

[Flor Chacón (florelis)]

I'm fine with extending the use of proxies to configuration, but it doesn't make much sense to me if it will only affect retrieving the configuration file.

The Install-Module cmdlet has a -Proxy argument but it "ignores this parameter since it's not supported by Install-PSResource," so it doesn't really help.

Apparently we could also set the WebRequest.DefaultWebProxy property to set it for the whole PSSession, but we'd need to try it to be sure it works for this.

[yao-msft]

btw, I'm fine with leaving configuration as future. I was just asking a naive question and I did not mean to add scope on this work.

[Kaleb Luedtke (Trenly)]

I believe there is an option to use DefaultNetworkCredentials when creating a proxy connection. Will this / should this be used in the initial implementation to enable domain-joined accounts to use their domain proxy? Just thinking that it may reduce the need to fully support authentication while providing a solution that addresses many enterprise security items

[Flor Chacón (florelis)]

I started implementing the feature and just now realized that this is not possible in all cases the way we currently do things. I was assuming it would be basically what Zuo Zongyuan (@eternalphane) did in #1776, i.e., adding the proxy argument in the call to InternetOpen(), but we have several other ways of fetching remote content and not all of them expose functionality to specify proxy.

• Delivery Optimization cannot use a custom proxy, only the system-wide one.
• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.
• The MSIX deployment APIs take a URI and have no option to configure a custom proxy. (I was assuming they took a stream and I could pass the proxied stream, but was wrong..)
• cpprestsdk can take a custom proxy to use
• Windows.Web.Http.HttpClient that we use for getting headers (for source update), downloading source MSIX packages and some other things, only allows us to use the system-wide proxy, not to set a custom one.

So, we can implement the feature for REST API requests and for downloading non-msix installers with wininet.
We definitely cannot implement the feature for using DO, or for MSIX installers (unless we download them first, but then we lose streaming installs).
And for the things that use HttpClient, we can't unless we decide to re-implement it using wininet or something else.

Would we be comfortable with saying "proxy is only used for non-MSIX installers (where it also forces the use of wininet over DO) and REST sources"? Or how else could we move the feature forward?

[Demitrius Nelon (denelon)]

Flor Chacón (@florelis) these are fantastic call-outs.

I think we should proceed with an experimental feature for proxy with the parts we can implement, and clearly state and link to the remaining details in Issues here (even if they are just to track work external to WinGet so the community can see as they are resolved).

Those other issues should be referenced in "Future Considerations" with links to the issues and we can continue to make progress over time. I have a fairly strong belief that anything we can implement will add value, and it will just continue getting better as we are able to track and close any remaining gaps.

[JohnMcPMS]

• wininet can use a custom proxy (that's InternetOpen()), but we basically only use it to download installers.

It is used to download things other than installers, like manifests and the index. Installers should be using DO.

[Flor Chacón (florelis)]

The way I actually implemented this in #4203 was having set and reset subcommands for settings so that we can do
winget settings set [--setting] <SomeAdminSetting> [--value] <SomeValue> or winget settings set [--setting] <SomeAdminSetting>. Currently the only admin setting that can be used there would be DefaultProxy, but I think it could be extensible.