winget-cli
winget-cli copied to clipboard
microsoft
Proposal: Allow code self-signed certificates with user approve
Description of the new feature/enhancement
Right now there is no way to install UWP or packaged side-loaded application without any certificate. However It is possible to distribute application with self-signed certificate, which should be manually installed by user (MSIX/APPX doesn't support it unfortunately). WinGet could solve that problem with providing ability to install certificate (or allow unsigned packages at all) with additional user approve.
Cases when developer distribute app with self-signed certificate:
- It is unofficial fork of another application, which couldn't be submitted to the store.
- Test version for end user testing.
- Install on devices without Store installed (LTSB/LTSC).
- Indie developers that can't/don't want to distribute application through the store and can't/don't want to buy expensive certificates.
Proposed technical implementation details (optional)
Add SelfSignedCertificate property per Installers' element in manifest. When user install package with self-signed certificate, winget will ask user confirmation, that he trust specific publisher, and certificate can be installed as trusted by winget.
Other notes
- It could be disabled by default and require additional setting up in system or winget.
- This feature is for CLI. Official package source (winget-pkgs) could be strict. Unofficial sources should be allowed to distribute packages with self-signed certificates.
Certificates are a problematic issue since some developers have created vulnerabilities with trusted root certificates in the past, e.g. Lenovo Superfish and Sennheiser HeadSetup.
I believe you're strictly speaking about code signing certificates instead of web server certificates though. Is that assumption correct?
This is related to #498 . If we want to run our own internal repository then we need the ability to trust apps from the internal repository, self signed or not signed at all. There should be some clear warnings when adding a trusted repository.
Agreed. Certificates are great for the end user ensuring they're installing what they want to install, however, there is a huge list of softwares which cannot be added to the repository now because the developers or author simply don't care about its inclusion into the repository. For the average user to submit a software to the repository, they would need to purchase a code signing key for between $60-500/yr just to add software to the community repository.
Not really an amazing option. Microsoft could launch a trusted user program where developers can apply, authenticate, and identify, and then Microsoft could endorse their self signed keys, perhaps? A terribly difficult setup, but :shrug:.
Please do not do this. While it may be the case that this helps a few, it opens a huge security hole that threat actors WILL employ. It runs a coach and horses around corporate security policies- with no apparent way to block it. And frankly if any publisher cannot afford a public signing key, yet expects one to load their stuff, just say no. If this is to be implemented, I would simply ban, and advise my clients to ban, the use of winger totally. Imho this is a bad idea.
Then even after 34 years in computing, Microsoft has yet again developed another completely useless technology. A product like this cannot and will not survive without community support. If someone wants to take the time to add software they care about to a repository for the benefit of all, it should absolutely be encouraged when it can be done in a secure way. Code signing keys simply aren't the way to go. Neither is relying on publishers to also publish to winget separately than their other delivery channels. Especially considering that I've been in software for more than 20 years and can tell you from experience that nobody gives a crap about proprietary Microsoft MSI/MSIX outside of an enterprise environment.
IMO this entire deployment is nothing more than a way for Microsoft to push the Microsoft store in a new way to attempt to capitalize on it and to safe guard losing users to WSL/Linux in general.
You can theorize about which attack vectors can be used against users, but the fact remains that the AUR, and other repositories have been used successfully for decades due to the lack of Microsoft sponsored software. There are even third party CLI application managers and installers for Windows such as Chocolatey and Scoop. Which are entirely successful and reasonably secure which also accept user submissions. To say it can't be done securely is frankly bull-crap. winget is almost a complete clone of Scoop with the inclusion of a bunch of dumb Microsoft tech. IMHO it is far far far more secure to check an applications hash than to rely on outdate and expensive PKIs. Many publishers already release hash information with their releases and would require only that the end user ensure the hashes match if they doubt the origin of an install. Something users already do.
I'm beyond frustrated with this project. I was talking on another thread about EXE installers and auto-covnerting packers. Somebody mentioned msix and I only just tried now it out properly, it works, its a little clunky but it works.
Now I realize the glaring flaws with msix. Of course, there is a glaring flaw, its a Microsoft product.
The first thing is the signign issue. Good fine, make sure stuff is signed ot make it secure, so how do I sign my
test package.
Ah yes, I need to get the massive huge, proprietary Windows 10 SDK just to get this 1 SignTool command listed here.
I haven't yet done this, clearly I'm being lazy, but I have other stuff I need to sort out for personal reasons, on top of all this extra cruft just to try this one tiny thing.
And it's just like, I'm only creating this package, for me, for me to test, as a 1 time off,
and I need to sign it.. Because?
Not even a really long straight of telling telling me this is a really bad idea but I still have the option?
And of course this was just a test if I could get a quick and dirty yaml that doesn't seem to work and checking if it was the
msix package or not,
which was really to test how well winget could handle local package installation.
How many steps do we want to stump / allow for contribution? Is fast iteration unheard of? Is the concept of freedom of a software to allow for flexabiltiy non-existent in Microsoft Land?
And of course, on top of all of this what I'm reading here is that not even signed certifacates is good enough for some formats, specificaly MSIX, the one I personally care about. How are you supposed to test something if you have to go through a huge number of steps to get through?
In it's current state at best winget matches the very hacky implimentation of Chocolatey, at worst it falls behind and may even be a hinderance, where people struggle to get any kind of usage out of it and waste trying to make it work.
If you're that worried about security, how about you introduce the concept of local packages. Why my 2MB text editor needs fully Administrator level access to be installed I don't know, its something that always grinds my gears about almost all package managers. To say that's "it's a security risk" is frankly a bit maddening considering the troughs of other security risks out there, you can't force consumers to stop being stupid, and making life hard for everybody else because of it can sometimes be a waste of time.
The only secure machine is the one that's unplugged and thrown in a fire. Don't compromise on usability because of security. EDIT. Ok that was a bit ranty, but it frustrates me to know end when ok-ish software with a lot of development time in it is is make completely worthless by a few very small design decisions. Single decisions like this shouldn't make a whole project worthless.
Installers needing administrator access isnt the fault of the package manager, more the package itself. There is no reason most installers request admin, other than the fact that they default to installing to the whole box and have no option for user-only. just my two cents
There are often good reasons why an installer needs elevated permissions, so this comment might be a little unfair. It might be installing code into protected folders or modifying protected parts of the registry. Both would be just fine if the installer runs elevated but not otherwise. And then there is inertia (our installers have always worked this way).
I think winget has to cater for the existing landscape - with loads of different approaches the team kind of has to follow. Maybe, one day MSIX becomes the next defacto standard packaging format with awesome benefits. But until the rapture, winget needs to handle things like certs and elevation.
I suppose this boils down to the difference between a very cool power toy for developers to get some stuff onto their machine vs an Enterprise managed cross-platform package management solution. Self-signed certs are great for development and developers. It enables them to test things without needing a public cert - I do this all the time. But if the developer then wishes to publish the solution to a public repository, IMHO,. the cost of the cert is all part of the cost of doing business.
With all that said, this proposal is about a year old. There have been numerous arguments for/against. I think we are in danger of just repeating ourselves. Can the team take a view on this: either by saying that yes, this is something the team wants to do (and assigns it to a milestone), or by formally saying no.
Ok yes, the comment about elevated privillages was a little unfair, its a little more complex than that. It's just funny to talk about security when other things could be done, like suggesting a local install for self-contained software.
I think, a package manager comes with the stigma that it should be accessible so people can share their software easilly, or at the very least facilitating unofficial packges and repositories if people want to ignore warnings... as oppose to, having a command like Microsoft Store, if they wanted a command line Microsoft store then why didn't they say that?
It seems like a lot of unnececary friction that is likely to reduce the usefulness of the software, to the point where its just not used in the mainstream, ever.
to the point where its just not used in the mainstream, ever.
This is possibly one of the most useful tools that Microsoft has designed in the past 10 years other than the new updated Terminal and I don't know of anyone at all that uses it, or even so much as speaks of it. It's not social software. No-one is going to use it.
If I have to go to the internet to download application installers for my favorite software anyways, then why use this tool at all? You're essentially installing an application that manages some of your applications.... That's not a good use case.
As it stands, winget has access to 85 application installers, the majority of which come directly from Microsoft... Something like PatchMyPC has well over 300.
It's just not competitive by any standard whatsoever.
@Mallchad installing with a local manifest is a supported scenario: winget install -m <pathToManifest>.
Private repositories are also supported via REST API. We have provided a reference implementation.
@zQueal how are you defining "application installer"? There are over 1,900 packages (unique "PackageIdentifier") in the community repository today.
I'm not sure a package manager is really targeted as being a "social tool". The initial set of use cases were primarily related to improving developer productivity. The "core" functionality for install, upgrade, export, import, and uninstall have been implemented. The goal is for these to work with any package on Windows. Clearly we have more work to do.
Most of the current work is around improving how manifests map to Apps in "Add / Remove Programs (ARP)". The initial work to support dependencies is in progress. We've also heard from several IT Professionals so the work for native PowerShell has moved up in priority as well.
@Mallchad installing with a local manifest is a supported scenario:
winget install -m <pathToManifest>. Sorry, doesn't this just allow installing a package from a local source? I was being a bit flippant in my suggestion about non-admin installs...
I'll look into the private repositories when I get a chance, I'd be interesting to how it behaves with package signing.
There are over 1,900 packages (unique "PackageIdentifier") in the community repository today.
Looks as if each version number is a unique package indenter, so I'm not sure if this is meant to be intentionally misrepresentative or not, but it certainly is misrepresentative.
winget list | wc -l 85
Winget seems to offer 85 unique softwares to install from what I can tell.
@zQueal
The manifests are located in the packages repository.
winget list displays what you have installed on your system.
winget search with no arguments will display all packages.
If you're including versions of manifests there are more than 6,800.
I have now been caught out by this issue! Our org certificate (Kiwix) expired yesterday, and suddenly all my UWP packages are now uninstallable from winget, even those that were submitted prior to the expiry. This seems very problematic... The packages that we release via the Microsoft Store are still working because the Store provides its own code signing, but since UWP packages in winget need to be sideloadable, we signed these with the now expired org certificate. Is there another solution that would prevent this from happening?
While Kiwix is sorting out a new certificate, I expect that the new one will not fix the previous packages uploaded to winget, and I'll have to resubmit (I think) each of the most current packages (three apps). I don't know if there is anything I can do about the previous packages. I can't re-build them because the code they were built from is now obsolete, and I'm not sure it's possible to "re-sign" previously signed packages without rebuilding. This makes the concept of winget being a proper historical archive a bit problematic...
@denelon do you have any advice?
@Jaifroid did you sign with timestamp? Any program signed with timestamp will not fail when the certificate expires because the OS can validate that the cert was valid at the time of signature. If winget is expiring timestamped signatures then that would be a major bug affecting all software,
https://comodosslstore.com/resources/how-to-avoid-code-signing-certificate-expired-issues/
@A9G-Data-Droid I have to confess I merely imported our org certificate into Visual Studio, and it took care of the rest. Clearly I needed to have looked into the options more carefully... But I think the broader issue (i.e. this issue) still stands. Thanks for the tip about timestamp. I'd have thought it ought to be the default in IDEs... But nothing is ever that simple.
@Jaifroid, yeah it can't be defaulted because it needs a timestamp server to sign with you. Microsoft could provide one by default and tell you that you need to turn it on. There might be anti-trust reasons why they can't. I would use the timestamp server of the company who sold the certificate.
I've been doing some research, and timestamping AppxBundle is not easy. Guess what, SignTool doesn't support doing so! Fiendishly complicated blog post about it here: https://blog.jayway.com/2017/01/16/time-stamping-appx-packages/
Which kind of underlines the need for WinGet to provide some kind of repo-side signing just like the Microsoft Store does.
@Jaifroid I'll look into some options for what we can detect in terms of checking to see if a .appxbundle is signed with timestamp. If it's something we can detect in validation, at least we could produce a warning in the validation pipeline output.
Hi @Jaifroid
It should just be an extra parameter(/t for timestamp server) to Signtool to get appxbundle signed with timestamp
signtool sign /a /v /fd sha256 /f <Path to signing cert> /t <Timestamp Server Url> test.appxbundle
Thanks
@yao-msft The thing is, I compile my appxbundles with Visual Studio, and because the app is html/js this has to be VS2017. VS2107, AFAIK, has no way to add the timestamp. However, I will look in to adding it as an extra build step by re-signing the bundles with signtool.
@Jaifroid I'll look into some options for what we can detect in terms of checking to see if a .appxbundle is signed with timestamp. If it's something we can detect in validation, at least we could produce a warning in the validation pipeline output.
@denelon this would be helpful, thanks.
There are even third party CLI application managers and installers for Windows such as Chocolatey and Scoop. Which are entirely successful and reasonably secure which also accept user submissions. To say it can't be done securely is frankly bull-crap.
wingetis almost a complete clone of Scoop with the inclusion of a bunch of dumb Microsoft tech.
@zQueal this is completely untrue if you actually spent your time using scoop and winget and relied on them. I have seen this online so many times and people always miss the point and think one has weed out the other. Fundamentally, they both are very different and solve two different problems but need each other because they both can't do each others job.
Firstly, Scoop is meant for portable apps and to use them from the shell directly after installing it, like a unix app. There are lot of Windows apps(and many of them command line) that are distributed as portable exes. scoop will shim them to its shims directory automatically. It can also install fonts. But scoop is very bad at managing installers and apps that register themselves to Windows appearing in the Programs and Features list. Or apps that update themselves automatically. For example VCRedist can be installed from scoop, but uninstalling it from Programs and Features will not uninstall it from scoop. scoop can't manage apps that automatically update themselves or register themselves to Windows and can be managed from Programs and Features.
Winget is meant for apps that come with a installer and can be managed by "Programs and Features". It even uses the ProductCode to uninstall an app, the string that identifies the app in the registry and is used by "Programs and Features" to uninstall your app(or you can use msiexec with the ProductCode to uninstall the app from Command Line. Infact winget can uninstall anything that has a ProductCode even if it is not in the winget-pkgs and winget list will list every app on "Programs and Features". The app will not install in some "winget directory" but in the default directory of the installer(or a custom one that you specify from the CLI). And it does not matter if the app self-updates, the version registered on "Programs and Features" is the version that winget thinks the app is registered on. I wrote this mess of a manifest for a UWP app when I thought scoop could be the ultimate package manager for Windows but then winget did it with one line - InstallerType: msix(and you can even install from the store. You are no longer telling the package manager to pass command line arguments on the installer like /verylient(or use a PowerShell script), you are just telling it that the installer is an inno package. And thats what winget does, it manages apps bundled with inno/nullsoft/msi/msix etc. packages and manages them, while the Windows Store is a repository for msix packages.
I use both scoop and winget, and never understood discussions like this around how one is better than the other(even Ash258 understands the differences, and you will know him if you used scoop and followed the scoop-project). Everything that can be fully managed by scoop, I install them from scoop. But anything that is registered to "Programs and Features", should be installed from Winget. This why I am puzzled by why scoop-nonportable is an official bucket. In my opinion, scoop should only contain portable apps that it can manage in its official buckets.
IMO this entire deployment is nothing more than a way for Microsoft to push the Microsoft store in a new way to attempt to capitalize on it and to safe guard losing users to WSL/Linux in general.
Thats such a terrible take on the subject. winget is an essential tool for windows that finally did something that many of us were wishing to see on a package manager for windows. If they actually turn Windows Store into a GUI for winget I am all for it, don't see the issue with that(or like this app, even better if they add Scoop to it since winget will never come close to it for managing portable apps).
And don't you dare mention Chocolatey as the better tool. Its full of outdated packages that rely on the maintainers whims to get updated(which is the first person who uploaded it to Chocolatey), confusing manifest-spec based on nuget and certain features behind a paywall. People love mentioning Keivan Beigi whose AppGet inspired winget(heck AppGet itself was full of outdated manifests and could neither uninstall nor update apps, it was nice concept that winget turned into a functioning product), but never seen anyone mention his rants about Chocolatey's issues. Chocolatey is inferior to scoop for portable apps and inferior to Windows when installing apps with an installer.
Fundamentally, they both are very different and solve two different problems
lol
Firstly, Scoop is meant for portable apps
lol
scoop can't manage apps that automatically update themselves
lol
I use both scoop and winget, and never understood https://github.com/ScoopInstaller/Scoop/issues/3992 around how one is better than the other(even Ash258 understands the differences, and you will know him if you used scoop and followed the scoop-project). Everything that can be fully managed by scoop, I install them from scoop. But anything that is registered to "Programs and Features", should be installed from Winget.
lol
Thats such a terrible take on the subject. winget is an essential tool for windows
lol amazing how we've been without winget for 35 years and have gotten along just fine considering winget is essential.
And don't you dare mention Chocolatey as the better tool.
lmao
The sheer ridiculousness of your reply is pretty stunning. Winget is a windows package manager built by Microsoft to be apart of the operating system. Scoop is a CLI application installer that's just another application package on your system.
The lack of perspective here is amazing. Especially considering all of your arguments which are 'pro' winget pretty much empirically support my major gripe with it to begin with;
winget is almost a complete clone of Scoop with the inclusion of a bunch of dumb Microsoft tech.
Love how you are not able to provide any rebuttal other than spamming lol. The only similarity between scoop and winget is that they install apps from the command line, like any other package manager. This is the first time I am hearing such a take, particularly from someone who probably never used scoop. I also love how you mention the community repo of aur and then praise Chocolatey which is completely opposite and it's almost impossible to contribute to a package abandoned by it's maintainer. I guess someone told you how Chocolatey is some amazing package manager for Windows but forgot to tell you about the mess known as its nuspec manifests. After I switched to scoop I never looked back at Chocolatey. And for the record I hated Chocolatey before winget was a thing.
lol amazing how we've been without winget for 35 years and have gotten along just fine considering winget is essential.
And for 35 years we have been downloading binaries from the web after googling them instead being able to comfortably use the command line.
The sheer ridiculousness of your reply is pretty stunning. Winget is a windows package manager built by Microsoft to be apart of the operating system. Scoop is a CLI application installer that's just another application package on your system.
Whether it is made by Microsoft has nothing to do with how I judge a product(otherwise I would not be using Windows in the first place). winget is the best tool to manage non-portable apps.
The lack of perspective here is amazing. Especially considering all of your arguments which are 'pro' winget pretty much empirically support my major gripe with it to begin with;
I mentioned good points of both scoop and winget. Winget is good for apps where you have to use an installer, scoop is good for portable apps(try being a firefox user only through scoop), I even linked to a very popular scoop manitainer who said the exact same thing. I have added packages to scoop(and even some to winget) and maintain my own scoop bucket, and I use both scoop and winget.
I see benefits to all the package managers I've looked at and worked with. Each of them was designed to solve the problem of managing software from a slightly different perspective and with slightly different use cases. Each of them has slightly different goals and approaches. There may not be a "one best option" in this space. I've often suggested to users that they should use the tool that solves their particular needs.
We're just trying to provide a native solution that supports meeting software developers where they are. We have certain unique constraints with respect to providing a solution that is native to Windows. Those constraints add a bit of complexity that we have to deal with and we're learning about the various edge cases and classes of problems unique to our constraints. There are many different package managers. Everyone is welcome to have an opinion, and to use the tool that meets their needs. Let's just try to keep the discussion civil, and if this needs further discussion, please create a new discussion so we're respecting the (e-mail inboxes) users who are looking at this issue related to code with self-signed certificates.