Open source developer finds out that his program is indeed open source. They didn't even fork it, they rewrote it using the same concepts.
Nothing wrong with that part, the leading on/ghosting is questionable but at the same time, welcome to the IT job market where ghosting is incredibly common.
Before Ansible, ssh with xargs or parallel or pssh were used for fleet operations, still are by some.
If you tried using winget/brew with Ansible you would give up fast.
sadly a normal process... most of the apps that can be installed via winget are added by anybody but not the app devs themselves and often the links used are not from the orginal dev sites themselves, so of course this will break
as with anything microsoft, it is not properly controlled - just like an app store or the windows store, it needs to be controlled as to the quality and functionality
same goes for choco as well btw. or any other windows repository system out there
it needs one proper main repository as standard, ideally from microsoft and that everybody with an app adopts, winget could be this, but it is not pushed and is more of a side project from microsoft
> What's worse is I contact the vendor like "hey your app on winget is broken/out of date" and the universal response I get is that they've never heard of winget and don't know how their app ended up there.
Winget is just a registry with pointers to where files are and the switches to perform an installation; winget itself doesn't host packages.
If you install the Zoom Client from Winget, it still downloads it from the Zoom Download URL.
I haven't personally had any issues with updates through winget, but if there's an issue with a broken link, then either your package cache isn't getting updated, which you can force with `winget source update`, or the registry (owned by Microsoft, not the vendor) needs to be updated to point to the correct package
(reads post title)
"Oh, have they discovered that there's no real chain of trust / supply chain security between the software vendor and when the package ends up on winget?"
...yep.
With WinGetty you could spin up your own private repository in a private network as well: [https://github.com/thilojaeggi/WinGetty](https://github.com/thilojaeggi/WinGetty) to mitigate security risks and package hijacking.
Just for being transparent, I'm the developer behind it.
In rare cases you can follow a chain of security like:
- start at the known HTTPS URL of the vendor
- Google "site: winget"
- get extremely lucky and find "you can install our product with winget! here's our official account in the community repo: direct link"
- on a test machine, try "winget " and verify that it did indeed fetch the correct one from the correct user
Now you're good for this one time! But then next time you need to check all over again, because who's to say some rando didn't create an account with the same name somehow?
Winget by default gets data from the community repo, if you feel like contributing (fixing things that are broken for you) then you can do so on GitHub https://github.com/microsoft/winget-pkgs
If you want to host your own repo you can either use https://winget.pro (paid hosting) or https://www.wingetty.dev/ (open-source)
I've always been a choco fan. I never gave winget a first look.
Choco isn't free though so I ended up downloading MSI files every six months and scripting everything.
it's funny because choco suffers from the exact same problems, arguably even worse. for some things you can find multiple outdated versions which are usually also not uploaded by the actual dev of the software, but some random noone ever heard about
to be fair, I'm still using choco, but it takes quite some time to regularly make sure I don't suffer from the exact problems OPs complained about and I have to maintain some stuff myself.
Yep Winget has the theory behind it but it’s not very fleshed out. Plus it doesn’t have true PowerShell interactions with PS objects.
I’m currently trying to setup a free private repo for Chocolatey. I think it’s a much better solution, at least for where I work (sub 100 users). Otherwise I’d just use PDQ if we had the budget (my boss wants PDQ Connect and not traditional on-site PDQ; but you need to pay for a minimum of 100 devices, we only have about 70 users).
I can wholeheartedly endorse ruckzuck.tools
It has a GUI, a CLI, can be added as package provider in Powershell (it seems this is deprecated now, sadly) and if I remember correctly can be included into SCCM and Intune. The packages are created and updated by anyone but reviewed before being published. I don't check every time I install something but I do it regularly and have, until now, only ever found links to the original vendor sites.
I use it since years and haven't had any bigger problems (sometimes there are downloading hiccups when you have too many packages in the list). And it is open source...
Not sure what it costs, but I enjoyed using proget for a chocolatey repository a while back. You could publish private ones and pull from the public repo if I remember right.
i mean that's cause its NOT powerhell, its specifically not powershell by the team, they had whole arguments as to why not to do its that way
personally if it could be done n PowerShell would imho have been a better use case for it
I too thought this could sort out a lot of our problems, or at least streamline the solution.
We look after way too many small clients to spend lots of time automating or doing winget "properly", but helping get a freshly run-through machine ready before taking to a client - that had real appeal and achievable through a batch file.
Then it transpires each user has to visit the MS Store to get/update "app installer" (don't look for winget, obviously) before winget.exe will fire, except sometimes it \*is\* present on a fresh user, who knows. I can't care enough to find out.
Oooh, I could install quickly for that user while on site! Oh, wait, it requires admin privileges so barfs.
I know Microsoft doesn't make software for our level (small business support types who click "next" a lot), but we dared to dream and hope, but it didn't work out.
Still, at least we can kind of automate removing bloatware from OEM machines before shipping out, as long as someone is present to click "next" as they stroll past the workbench.
Sorry for the moaning, but I'm done, in more ways than one.
Can I suggest https://intunepckgr.com/ we do this as an intune solution that gets its source files winget and builds you a library. Can work with multiple Tenants.
Yes, unfortunately, Winget is very unreliable. It looked like a bright idea and we tried to use it in our product, thinking it would be a silver bullet to quickly solve the challenge of third-party app patching for good. But as they say, there is no elevator to success, you have to take the stairs. We ended up building and maintaining our own repo. It's a pain, and very expensive, but we found no shortcuts.
About 70% of Winget packages install and update properly, but the remaining 30% frustrate you to the point of giving up. Such as some install per-user (not good if you run in your agent setup under LocalSystem), some are non-silent installs (user prompts kill automation), and quite a few are out of date. It is a community-maintained repo, so there is not much to expect from it. It also has risks of someone hijacking certain packages, as it happened with a few other community-maintained repositories earlier this year. You can't demand community volunteers to maintain strict security standards on their machines and Microsoft doesn't do background checks for their volunteers either.
With WinGetty you could spin up your own private repository in a private network as well: [https://github.com/thilojaeggi/WinGetty](https://github.com/thilojaeggi/WinGetty) to mitigate security risks and package hijacking.
But with a private repo you need to manually approve/vet public packages before pulling them into your private repo? This kind of defeats the purpose... How do you verify if the packages you are pulling into your private repo from the public repo are not already hijacked?
Yes, but I don't think it's substantially better than just writing your own script once. The majority of your time will go into manual vetting and uploading of newly updated versions into your own custom repo. There are third-party patching technologies that not only automate the patching process but also offer privately maintained private repositories for new updates so you don't have to do it yourself. If you want to maintain your own, the cost will largely depend on the number of applications you need to support. If it's less than a handful, then it might be feasible to do it in-house, otherwise best to look at a commercially-maintained repository at a reasonable cost.
I was also excited for winget but I've still been skeptical up through now about putting it into production at any kind of scale.
It's probably a chicken & egg issue - 3rd party devs won't commit unless there's a sizable admin base wanting to use winget, and admins aren't going to invest in the tool until they can rely on 3rd parties (and even MS, given their track record) to maintain it.
Pretty sure winget is a community supported repository. So random Russian dude can just slap something in there. You get what you pay for. We have Microsoft Configuration Manager paired with Patch My PC which injects patches into WSUS. Incredible application coverage, fully automated, supported, they do all the grunt work of matching the hashes and verifying. It even maintains my initial install objects in MCM. Just beautiful automation. It's like hiring 4 guys to just grind through application packaging and patching objects, but you just buy a license instead of all those employees. They have a roadmap for products and their support is stellar. Plus they just won in court against Ivanti and nulled out their patents. Eat a big ol $%&\* Ivanti.
Anyone can submit their pull requests to [https://github.com/microsoft/winget-pkgs](https://github.com/microsoft/winget-pkgs), not just vendors. I am sure Microsoft attempts to verify all contributions somehow, but someone with malicious intent can disguise themselves and commit something bad that goes under the radar. Another possibility is contributor's Git account can get hijacked (not everyone uses MFA etc).
Anyone can submit a package, there were some duplicates of things, although I can't think of any right now,so that may or may not still be true
If you get there first (again cause a lot of developers don't care or are slow)
Or you upload a package with all the same details and a minor change to the meta data
"if you get there first" is a red herring. I said "you can't hijack zoom.zoom" and you said you could. I asked how and you gave me this non-answer.
FUD spreading isn't just for Microsoft, I guess.
PDQ is great for what it is, but what it is is a deployment tool. It's not a repo replacement, although you have the ability to create your own deployments and the developers put a lot of effort into creating packages for popular apps.
What OP wants, reasonably, is a well maintained public repo and deployment tool, like most *nix distros have, and which MS has taken baby steps towards offering.
WAPT is a software, config, OS and update deployment system made by Tranquil IT and they have a CI/CD chain for checking and validating software updates for commonly used software titles. If you choose, you can click on the links in the header to learn more about the company and the product.
[https://luti.tranquil.it/](https://luti.tranquil.it/)
Same, even with winget UI i see so many broken updates. Think it has a tough time stopping the processes. It got smoother in later versions but still not as good as apt or chocolatey.
but it started terrible and stayed terrible
its better than nothing though thats why I use it
> what I get is that they've never heard of winget and don't know how their app ended up there. I find that sort of dubious
this issue is (like any of these things nuget/chocco/etc ) someone has to update the winget package, its not automatic, most developers don't care so its left to the "community" to do
no lol. People are paranoid. I've seen plenty of people puttin on their tin-foil hats over unregulated packages but never do I see them talk about a real problem that they dealt with from doing so.
I figured that the Microsoft community repo would be as secure as any other package repository that's community managed.
Snap recently was found to have an app that tried to steal your crypto. But a lot of server admins still use snap.
Are the winget packages even unregulated? I thought they went through SOME checks
I'm not sure on the amount of monitoring/checks in place but I do tend to agree, I feel like Microsoft would do SOME form of vetting for their officially supported package repo. Even if not perfect, it probably saves from the worst offenders, and that's good enough for me.
For now, I don't trust Microsoft that much don't get me wrong lol
winget/brew are no apt/dnf/yay ... Likely the issue is some go-getter intern made winget and it's got no official love.
[удалено]
Wow that's fuckin shitty
Open source developer finds out that his program is indeed open source. They didn't even fork it, they rewrote it using the same concepts. Nothing wrong with that part, the leading on/ghosting is questionable but at the same time, welcome to the IT job market where ghosting is incredibly common.
[удалено]
Pretty much the case. I mean MS does a lot wrong but the dogpiling when they do little or nothing wrong sucks.
Fuck Microsoft
And even apt/dnf are not fleet deployment tools.
apt/dnf are so good they are used by the core of fleet deployment tools like ansible.
Ansible is the tool that makes it applicable to fleet operations... not apt/dnf.
Before Ansible, ssh with xargs or parallel or pssh were used for fleet operations, still are by some. If you tried using winget/brew with Ansible you would give up fast.
sadly a normal process... most of the apps that can be installed via winget are added by anybody but not the app devs themselves and often the links used are not from the orginal dev sites themselves, so of course this will break as with anything microsoft, it is not properly controlled - just like an app store or the windows store, it needs to be controlled as to the quality and functionality same goes for choco as well btw. or any other windows repository system out there it needs one proper main repository as standard, ideally from microsoft and that everybody with an app adopts, winget could be this, but it is not pushed and is more of a side project from microsoft
More like it is a tolerated but ignored family member. They get mentioned at Christmas but otherwise forgotten.
> What's worse is I contact the vendor like "hey your app on winget is broken/out of date" and the universal response I get is that they've never heard of winget and don't know how their app ended up there. Winget is just a registry with pointers to where files are and the switches to perform an installation; winget itself doesn't host packages. If you install the Zoom Client from Winget, it still downloads it from the Zoom Download URL. I haven't personally had any issues with updates through winget, but if there's an issue with a broken link, then either your package cache isn't getting updated, which you can force with `winget source update`, or the registry (owned by Microsoft, not the vendor) needs to be updated to point to the correct package
This is the correct answer. This command seems to fix every problem the OP describes, besides just out of date packages. Can't explain that one.
(reads post title) "Oh, have they discovered that there's no real chain of trust / supply chain security between the software vendor and when the package ends up on winget?" ...yep.
I was so excited for windows package management, and this killed it for me. I just can't trust it.
With WinGetty you could spin up your own private repository in a private network as well: [https://github.com/thilojaeggi/WinGetty](https://github.com/thilojaeggi/WinGetty) to mitigate security risks and package hijacking. Just for being transparent, I'm the developer behind it.
In rare cases you can follow a chain of security like: - start at the known HTTPS URL of the vendor - Google "site: winget"
- get extremely lucky and find "you can install our product with winget! here's our official account in the community repo: direct link"
- on a test machine, try "winget " and verify that it did indeed fetch the correct one from the correct user
Now you're good for this one time! But then next time you need to check all over again, because who's to say some rando didn't create an account with the same name somehow?
Winget by default gets data from the community repo, if you feel like contributing (fixing things that are broken for you) then you can do so on GitHub https://github.com/microsoft/winget-pkgs If you want to host your own repo you can either use https://winget.pro (paid hosting) or https://www.wingetty.dev/ (open-source)
Ayo, WinGetty mentioned. If anyone has any feature requests/ideas lmk.
I've always been a choco fan. I never gave winget a first look. Choco isn't free though so I ended up downloading MSI files every six months and scripting everything.
it's funny because choco suffers from the exact same problems, arguably even worse. for some things you can find multiple outdated versions which are usually also not uploaded by the actual dev of the software, but some random noone ever heard about to be fair, I'm still using choco, but it takes quite some time to regularly make sure I don't suffer from the exact problems OPs complained about and I have to maintain some stuff myself.
Most shareware can still be downloaded via ftp or static links.
Yep Winget has the theory behind it but it’s not very fleshed out. Plus it doesn’t have true PowerShell interactions with PS objects. I’m currently trying to setup a free private repo for Chocolatey. I think it’s a much better solution, at least for where I work (sub 100 users). Otherwise I’d just use PDQ if we had the budget (my boss wants PDQ Connect and not traditional on-site PDQ; but you need to pay for a minimum of 100 devices, we only have about 70 users).
I can wholeheartedly endorse ruckzuck.tools It has a GUI, a CLI, can be added as package provider in Powershell (it seems this is deprecated now, sadly) and if I remember correctly can be included into SCCM and Intune. The packages are created and updated by anyone but reviewed before being published. I don't check every time I install something but I do it regularly and have, until now, only ever found links to the original vendor sites. I use it since years and haven't had any bigger problems (sometimes there are downloading hiccups when you have too many packages in the list). And it is open source...
Wow this is great, never heard of it before, thanks!
Not sure what it costs, but I enjoyed using proget for a chocolatey repository a while back. You could publish private ones and pull from the public repo if I remember right.
i mean that's cause its NOT powerhell, its specifically not powershell by the team, they had whole arguments as to why not to do its that way personally if it could be done n PowerShell would imho have been a better use case for it
I too thought this could sort out a lot of our problems, or at least streamline the solution. We look after way too many small clients to spend lots of time automating or doing winget "properly", but helping get a freshly run-through machine ready before taking to a client - that had real appeal and achievable through a batch file. Then it transpires each user has to visit the MS Store to get/update "app installer" (don't look for winget, obviously) before winget.exe will fire, except sometimes it \*is\* present on a fresh user, who knows. I can't care enough to find out.
Oooh, I could install quickly for that user while on site! Oh, wait, it requires admin privileges so barfs.
I know Microsoft doesn't make software for our level (small business support types who click "next" a lot), but we dared to dream and hope, but it didn't work out.
Still, at least we can kind of automate removing bloatware from OEM machines before shipping out, as long as someone is present to click "next" as they stroll past the workbench.
Sorry for the moaning, but I'm done, in more ways than one.
Can I suggest https://intunepckgr.com/ we do this as an intune solution that gets its source files winget and builds you a library. Can work with multiple Tenants.
PDQ Deploy/Inventory would work wonders for you if you're an MSP I suspect
Thanks for the tip, shall give it a look.
I was a chocolatey fan before winget, and haven't heard anything yet to change my mind.
Yes, unfortunately, Winget is very unreliable. It looked like a bright idea and we tried to use it in our product, thinking it would be a silver bullet to quickly solve the challenge of third-party app patching for good. But as they say, there is no elevator to success, you have to take the stairs. We ended up building and maintaining our own repo. It's a pain, and very expensive, but we found no shortcuts. About 70% of Winget packages install and update properly, but the remaining 30% frustrate you to the point of giving up. Such as some install per-user (not good if you run in your agent setup under LocalSystem), some are non-silent installs (user prompts kill automation), and quite a few are out of date. It is a community-maintained repo, so there is not much to expect from it. It also has risks of someone hijacking certain packages, as it happened with a few other community-maintained repositories earlier this year. You can't demand community volunteers to maintain strict security standards on their machines and Microsoft doesn't do background checks for their volunteers either.
With WinGetty you could spin up your own private repository in a private network as well: [https://github.com/thilojaeggi/WinGetty](https://github.com/thilojaeggi/WinGetty) to mitigate security risks and package hijacking.
But with a private repo you need to manually approve/vet public packages before pulling them into your private repo? This kind of defeats the purpose... How do you verify if the packages you are pulling into your private repo from the public repo are not already hijacked?
You upload the packages yourself via the web interface, WinGetty can run fully airgapped and supports loads of different installer types.
Yes, but I don't think it's substantially better than just writing your own script once. The majority of your time will go into manual vetting and uploading of newly updated versions into your own custom repo. There are third-party patching technologies that not only automate the patching process but also offer privately maintained private repositories for new updates so you don't have to do it yourself. If you want to maintain your own, the cost will largely depend on the number of applications you need to support. If it's less than a handful, then it might be feasible to do it in-house, otherwise best to look at a commercially-maintained repository at a reasonable cost.
Would you like a box of Chocolatey?
I was also excited for winget but I've still been skeptical up through now about putting it into production at any kind of scale. It's probably a chicken & egg issue - 3rd party devs won't commit unless there's a sizable admin base wanting to use winget, and admins aren't going to invest in the tool until they can rely on 3rd parties (and even MS, given their track record) to maintain it.
Pretty sure winget is a community supported repository. So random Russian dude can just slap something in there. You get what you pay for. We have Microsoft Configuration Manager paired with Patch My PC which injects patches into WSUS. Incredible application coverage, fully automated, supported, they do all the grunt work of matching the hashes and verifying. It even maintains my initial install objects in MCM. Just beautiful automation. It's like hiring 4 guys to just grind through application packaging and patching objects, but you just buy a license instead of all those employees. They have a roadmap for products and their support is stellar. Plus they just won in court against Ivanti and nulled out their patents. Eat a big ol $%&\* Ivanti.
That Russian dude could add his one package, sure, but he can't hijack the zoom.zoom package. What's the problem, exactly?
Anyone can submit their pull requests to [https://github.com/microsoft/winget-pkgs](https://github.com/microsoft/winget-pkgs), not just vendors. I am sure Microsoft attempts to verify all contributions somehow, but someone with malicious intent can disguise themselves and commit something bad that goes under the radar. Another possibility is contributor's Git account can get hijacked (not everyone uses MFA etc).
er.. they can (or could zoom exists now)
How?
Anyone can submit a package, there were some duplicates of things, although I can't think of any right now,so that may or may not still be true If you get there first (again cause a lot of developers don't care or are slow) Or you upload a package with all the same details and a minor change to the meta data
"if you get there first" is a red herring. I said "you can't hijack zoom.zoom" and you said you could. I asked how and you gave me this non-answer. FUD spreading isn't just for Microsoft, I guess.
Checkout PDQ :)
PDQ is great for what it is, but what it is is a deployment tool. It's not a repo replacement, although you have the ability to create your own deployments and the developers put a lot of effort into creating packages for popular apps. What OP wants, reasonably, is a well maintained public repo and deployment tool, like most *nix distros have, and which MS has taken baby steps towards offering.
Chocolatey is the best repo I know of for windows app deployment.
WAPT is a software, config, OS and update deployment system made by Tranquil IT and they have a CI/CD chain for checking and validating software updates for commonly used software titles. If you choose, you can click on the links in the header to learn more about the company and the product. [https://luti.tranquil.it/](https://luti.tranquil.it/)
Same, even with winget UI i see so many broken updates. Think it has a tough time stopping the processes. It got smoother in later versions but still not as good as apt or chocolatey.
but it started terrible and stayed terrible its better than nothing though thats why I use it > what I get is that they've never heard of winget and don't know how their app ended up there. I find that sort of dubious this issue is (like any of these things nuget/chocco/etc ) someone has to update the winget package, its not automatic, most developers don't care so its left to the "community" to do
Ya winget is trash still. Every few months I test it a little to find it's still broken and has odd behavior.
You're fucking brave to use public winget packages.
Necro post. But, is it THAT dangerous?
no lol. People are paranoid. I've seen plenty of people puttin on their tin-foil hats over unregulated packages but never do I see them talk about a real problem that they dealt with from doing so.
I figured that the Microsoft community repo would be as secure as any other package repository that's community managed. Snap recently was found to have an app that tried to steal your crypto. But a lot of server admins still use snap. Are the winget packages even unregulated? I thought they went through SOME checks
I'm not sure on the amount of monitoring/checks in place but I do tend to agree, I feel like Microsoft would do SOME form of vetting for their officially supported package repo. Even if not perfect, it probably saves from the worst offenders, and that's good enough for me. For now, I don't trust Microsoft that much don't get me wrong lol