Live data from Hacker News

The Windows installer of ImageMagick will no longer be signed

github.com

151–160 of 364 posts

Re: The Windows installer of ImageMagick will no longer be signed

#151
post #90

Earlier quoted context omitted.

How could it not? It is adding software to the system software set, accessible by all users of the system. And many programs require some kind of integration into the OS, such as file type associations or context menu entries, which even a single user shouldn't have access to do.

This way of working should have been left behind in the previous century. Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app. Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago. A image edit…

> Sandboxing should be default

This is exactly how Qubes OS works. My daily driver, can't recommend it enough.

Re: The Windows installer of ImageMagick will no longer be signed

#152

Why do we let any random application open its own files and folders at will? The actual selection and opening of files and other resources should be the job of the operating system. GUI programs should be able to call "open" "save" and other dialogs to get handles to files, not just their names. The OS should limit access to resources to those it provides (as capability tokens) and nothing else. For CLI programs, the…

Because we're using operating systems rooting from 80-s and nobody's going to rewrite them from the scratch along with all the software running on top of them. Web applications are the best thing we could get.

Well, if Ubuntu Snaps are any indication, then I'm happy for the 1980s OS design. I mean, it's cool that you can get a sandboxed program with simple CLI comamnd. It sucks that it's completely useless until you figure out how to give it access to the host file system, because guess what, most software that's useful for anything other than entertainment needs to interoperate with other software using files.

To be fair, Android does it better in that at least the apps can call into system file picker, which lets me simultaneously navigate the host FS and grant the app access to specific files or folders (and it explains what it's doing).

Still, I'm worried, because decisions about future OS and platform architectures are increasingly made by people who grew up in the "apps era", and likely internalized the misguided idea that "data produced by a program belongs to that program", further disempowering the users (including, ultimately, themselves). This is in opposition to the idea that made computing ubiquitous and a tool for people to improve their lives: the idea that data is independent of the software that produced it; that the data files are owned by the user, can be copied and moved around using generic means, and worked on in many different software tools.

Re: The Windows installer of ImageMagick will no longer be signed

#153
post #40

Seems like security is slowly eating the software world. At some point security will be so onerous that it will take more effort than the actual software being secured. Software was more fun in the good old days before there was a huge criminal industry exploiting it. Alas, it was bound to happen eventually. That said, seems like you could bring down that price by hosting the key yourself with a yubikey or cloud hsm…

The issue here is the high financial burden to have a secure/signed release, not the security itself.

High financial burden? It’s something like $600. For me, the tragedy is that something as useful and valuable as ImageMagick is scraping by with so little support from end users and other companies and projects that use it.

Re: The Windows installer of ImageMagick will no longer be signed

#154
post #116

Earlier quoted context omitted.

> Let that stick in your brain for next time you wonder why Windows still hasn't gotten a competent package manager that can wrangle dependencies. winget?

Winget just runs installers and uninstallers. I don't think it wrangles dependencies. That is, it won't install a dependency as its own package, nor will it uninstall a dependency when the last dependent is uninstalled.

Honestly, winget at this point is (or is about to be) suffering from the same trust issues GP described. I recently tried to provision a new Windows install with some software, and for many common tools, I found that winget offered suspiciously many similarly named options to choose from. Sometimes all the options look off in some way, like having weird vendor names.

For me, this is a regression compared to just downloading installers from the web - at least I find it easier to find the official site of the product (and distinguish it from fake sites with malware), and pull it from there. Or, increasingly often, get an installer from a Github release.

Re: The Windows installer of ImageMagick will no longer be signed

#155
post #98

Earlier quoted context omitted.

Sigstore doesn’t seem to verify actual legal identity, just control over a GitHub account or similar. It therefore doesn’t provide the same level of assurance as a code-signing certificate. OSs thus do well to not bundle their CA certificate as a trusted root.

I don't think your OS intends to imply or guarantee a legal entity relationship with every CA certificate in your trust store. It's not even clear what that guarantee, as an end user, would get you: the presence of a legal entity doesn't somehow make that entity accountable to you or your locality.

> I don't think your OS intends to imply or guarantee a legal entity relationship with every CA certificate in your trust store.

I get the feeling that it's exactly what Windows "intends to imply or guarantee", it's just taking a long time to get there. The whole code signing part is trying to create a reality where to be able to create software for Windows, you need to be a business entity, and need to have business relationships with Microsoft - directly, or transitively. Basically, a corporate web of trust.

Re: The Windows installer of ImageMagick will no longer be signed

#156

Earlier quoted context omitted.

I think it would be fine to have code signing certificate ensures that signer controls a certain DNS name. I'm fine with "installer have been signed with somebody who owns imagemagick.org"

Yes, but most people aren’t. It also significantly reduces the usefulness of code signing for the vast majority. And your justification for that is that it personally wouldn’t be a big deal to you, someone that has an abnormal understanding of the technologies at play.

Why is it any less useful than some entity name? You can be pretty sure that google.com is controlled by Google, and if the domain on the app is g00gle.ru, that's going to fool exactly the same people as if the scammer's company name was Googel.

Re: The Windows installer of ImageMagick will no longer be signed

#157
post #90

Earlier quoted context omitted.

How could it not? It is adding software to the system software set, accessible by all users of the system. And many programs require some kind of integration into the OS, such as file type associations or context menu entries, which even a single user shouldn't have access to do.

This way of working should have been left behind in the previous century. Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app. Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago. A image edit…

Windows has already made that journey years ago. The MSIX system works the way you suggest:

• Admin privs aren't needed

• Packages declare what integration points they need in an XML file

It's similar to the way macOS, iOS and Android work. You can also (starting soon in Win11) declare that the app will be sandboxed.

However, developers have to actually use this system and most don't know it exists or how to use it.

The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor [1], which is a product my company makes. It can make these MSIX files along with all the new formats it requires for things like icons, and it can do so from Linux or macOS or whatever the developers prefer to use. So you can do releases locally without needing CI/CD or cloud signing.

Now, they'd like to have releases be done by GitHub Actions instead of using local hardware, and that would require a cloud signing service as they say. Conveyor can use those too. But that's not a technical requirement anymore, because it doesn't use any of the native toolchains so you don't need to release Windows binaries from Windows (or Mac from Mac). Conveyor can create all the files for installing and updates, and then upload them to a GitHub Release or ordinary web server, and it's free for open source projects. Given that they're initiating the release process from a laptop anyway, they can do it all locally.

Conveyor can also self-sign but that's more just to enable the tracking of permissions and things for all software. Self signed binaries still trigger warnings obviously.

[1] https://conveyor.hydraulic.dev/

Re: The Windows installer of ImageMagick will no longer be signed

#158

Why do we let any random application open its own files and folders at will? The actual selection and opening of files and other resources should be the job of the operating system. GUI programs should be able to call "open" "save" and other dialogs to get handles to files, not just their names. The OS should limit access to resources to those it provides (as capability tokens) and nothing else. For CLI programs, the…

You may be interested in trying Qubes OS, which provides security through compartmentalization: https://qubes-os.org

Re: The Windows installer of ImageMagick will no longer be signed

#159

Earlier quoted context omitted.

Yes, but most people aren’t. It also significantly reduces the usefulness of code signing for the vast majority. And your justification for that is that it personally wouldn’t be a big deal to you, someone that has an abnormal understanding of the technologies at play.

Why is it any less useful than some entity name? You can be pretty sure that google.com is controlled by Google, and if the domain on the app is g00gle.ru, that's going to fool exactly the same people as if the scammer's company name was Googel.

Because domain names are cheap and can be purchased in bulk.

TLS certificates are for encryption. You don't care if the endpoint is "bad" in some way, only that you are communicating with it securely.

Code signing certificates are to make bans stick. Totally different purpose.

Re: The Windows installer of ImageMagick will no longer be signed

#160
post #90

Earlier quoted context omitted.

This way of working should have been left behind in the previous century. Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app. Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago. A image edit…

> Sandboxing should be default. Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website. Even in Linux and using the Snap sandbox (ubuntu), there are significant i…

Does this also affect non-store sandboxes? I think it's pro-only, but windows supports sandboxing for any kind of app.
Post reply on HN