Information on hosting your own local repository

[bigpod98]

As im checking this out there does not seem any information on hosting your own local repository of packages. This information could be usefull for companies or users who have a lot of their own builds and might even use their own private applications.

I am also asking this because there is option to add aditional sources of packages to winget command line app. So i went on the hunt for that info right away.

thanks for looking at my issue.

[denelon]

We're working on a REST API that would be simpler for this use case. I do clearly see a need to update the documentation here.

[doctordns]

If you are using REST APIs, doesn't that preclude using an SMB share? Or is the REST API in addition to using SMB transport of the underlying package content and meta data?

[bigpod98]

If i may guess restapi is basicly tellimg it where in storage it is and all infor required

[denelon]

I think the issue microsoft/winget-cli#160 would address the SMB concern.

[denelon]

The client today pulls a package down that is a set of pointers to the manifests. We're looking at enabling a REST API so third parties wouldn't have to build a signed package with an index similar to what we currently have. The API would support queries from the client and provide manifests for the client to use for package installation.

[chbwien]

A local repository would be very interesting for us because we are maintaining a huge repository of software for the whole university.

[denelon]

I think this may be a duplicate of microsoft/winget-cli#118

[denelon]

https://github.com/microsoft/winget-cli-restsource is a reference implementation for an HTTPS REST API source.

[denelon]

#34

Draft PR is out with documentation and a PowerShell script to ease deployment.

[doctordns]

The client today pulls a package down that is a set of pointers to the manifests. We're looking at enabling a REST API so third parties wouldn't have to build a signed package with an index similar to what we currently have. The API would support queries from the client and provide manifests for the client to use for package installation.

Please only use signed manifests.

[denelon]

@doctordns we thumbprint the manifests used in the PreIndexed package (the default "winget" source). That helps ensure they aren't modified/corrupted by the time the client receives them. The REST API hands the data to the client in JSON format. If the source is not compromised, HTTPS/TLS would protect the data in transit. Does that alleviate your concern or did I misunderstand?

[doctordns]

Not really, in my view.

If you want to use winget on the server-side, we need fully digitally signed manifests. I was long against using this tool for servers, but with signed manifests from Microsoft, winget, once we get cmdlets, seems the best way to move forward. At least for officially released and supported MSFT code - such as WAC.

[denelon]

@doctordns thanks for the clarity on this. I'll have the team look into what it would take to digitally sign manifests. This would apply to the PreIndexed default source named "winget" when it is pulling files down from Azure storage. I'm not sure what options we would have for a REST based source. I'll have to see what that would look like, and what it entails.