I feel their pain. I built an open source video player for esports coaches[1] that it given away for free and one the constant complaints about it is that users have to bypass warnings when installing it for the first time.
I can afford to pay for certificates (I believe I have to have one for Windows and OSX) but I refuse to for a project that I already give away my time for.
I would love to see a LetsEncrypt style service for OSS but I assume it's against the core interests of Microsoft / Apple to allow something like this as it would start to drive people away from the walled gardens of the app stores.
I've been writing software for close to 25 years and it's quite sad to watch the decline of ownership over our own machines in the same of "security".
> I would love to see a LetsEncrypt style service for OSS but I assume it's against the core interests of Microsoft / Apple to allow something like this as it would start to drive people away from the walled gardens of the app stores.
People have been asking Let's Encrypt itself for this on the Let's Encrypt forum since the project was founded.
The usual answer is that code signing certificates are (supposedly) trying to attest to a legal identity in the hope of being able to punish people offline if they publish malware, or allow people or organizations to have a policy about only installing software known to be from a certain list of publishers. DV certificates for HTTPS are trying to attest to control of a name in the DNS, which is verifiable by automated technical means, and which is not necessarily related to offline identity. (ICANN says it should be ... in an indirect way ... which isn't always complied with, and which, following increased pressure from European privacy law, is often not visible to the public.)
A Let's Encrypt certificate would confirm that a certain key is apparently controlled by someone who apparently also controls a certain DNS name. But a code signing certificate would supposedly go further and confirm that it's apparently controlled by someone acting on behalf of a certain named legal person existing in a certain jurisdiction. This is much more expensive to verify usefully, although maybe some governments will eventually have a way to automate it.
This isn't to say that either kind of certificate is necessarily ideal for all of the different uses to which relying parties end up putting it nowadays, but just that what they're attesting to, and how you would verify it, is pretty different.
> I refuse to for a project that I already give away my time for.
Maybe I’m naive but I feel like the solution is pretty obvious: just crowdsource the cost of the certificate and only sign the software as long as the money keeps coming in.
If people really do care that much they should be willing to help shoulder the cost, and if they’re not then there shouldn’t be a problem with it being unsigned.
Another pain point with this that I just remembered is that Chrome will also complain about the download if it isn't signed. This does seem to get switched off after enough downloads have been accrued.
> it's against the core interests of Microsoft / Apple to allow something like this as it would start to drive people away from the walled gardens of the app stores
For utility style apps, Microsoft's app store is a joke.
I think that a main part of LetsEncrypt security comes from renewing the certificate every 3 months. You would not be able to do that with shipped binaries.
I don't think he's saying it requires elevated privileges. When binaries aren't signed Windows will throw up a warning that it isn't signed which makes users hesitant to install.
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 worfklow isn't usable with these new rules, and I'm having a hard time with the assertion that moving builds to my desktop to use a hardware signing key and uploading them in a non automated, non transparent fashion is an improvement on security.
> moving builds to my desktop to use a hardware signing key and uploading them in a non automated, non transparent fashion is an improvement on security
For most projects it is an improvement, for better or worse.
First issue: private keys stored in files can be stolen silently, and then the only recourse is revocation. That's the main reason for the HSM requirement: malware authors have been doing this for some time now and revocation is difficult/expensive for various reasons. An HSM can also be stolen but only in the old fashioned way of breaking into your office or home and grabbing it, which you're going to notice.
You may object that the credentials for using the HSM can be stolen, and that's true, but they can also be changed easily and quickly. So if you notice that your PIN has been keylogged, you can recover from the compromise then change the PIN and you're done, no need to revoke the certificate.
Second issue: automated signing in CI can actually be risky. It means anyone who can push code to your CI system can get code signed as yourself, possibly without you even being aware of it. The key is held online at all times, so obviously if the CI system gets hacked then it's game over, but even without that it boils down to anyone who can push code into the system becoming a weak point, especially because CI systems are running lots of arbitrary code without being closely monitored. CI signing is at best 1-factor security.
If you sign locally then the key can be (literally) offline until the moment you do a release, and access to it can be constrained via 2-factor auth: the key is something you have, the credential is something you know. So this is quite secure.
For signing nightly dev builds, internal tools and other transient binaries that shouldn't get out into the wild anyway, you can self-sign which is free.
"Cloud HSMs" are allowed by the CA/B rules which wholly negate the benefit for that second issue and bring us back into the situation where anyone who checks code into CI can sign with the key. The CA/B rules are really just concerned with the first issue, right?
I highly recommend signing dev builds with your proper key because building a reputation of signing legitimate binaries is a strong signal for Microsoft smartscreen.
I'm in exactly the same boat; doing the same thing to store my OV .pfx certificate in a GitHub Actions secret. My certificate expires in November 2024 and I'm undecided what I'll do. It was hard enough to get a certificate as a solo developer and not a corporation.
Still, though, it should just be a matter of money. The $629/year cloud-hosted HSM mentioned in the OP will do it. If you pay that, you can use this procedure to make it work with GitHub Actions with the same sort of signtool or Set-AuthenticodeSignature command that you use now: https://docs.digicert.com/en/software-trust-manager/ci-cd-in...
I’ve found the easiest option available here is through using Azure KeyVault to store the keys. I use a custom module to sign my PowerShell scripts and dlls [1] for this because I can integrate it with OIDC to sign the code using the keys stored in the Azure HSM. While the builtin pwsh Set-Authenticode cmdlet can’t do this currently there are other options that rely on Window’s authenticode APIs like AzureSignTool [2] that I highly recommend.
While I’m unsure if Azure is suitable for actual companies I think the risk is ok for what I need it for and the API quality as well as OIDC support make it quite nice to use with GHA.
It’s astonishing that a project as critical and widely used as ImageMagick can’t even scrape together $629 for something as essential as a software signature.
It’s a glaring example of how the tech industry fails to financially support the very open-source projects that it relies so heavily upon.
Despite offering incredible value, these projects often can’t capture enough of it to sustain themselves.
It’s a sobering reminder that something significant needs to change in how we approach and value open-source contributions.
> can’t even scrape together $629 for something as essential as a software signature
I don't think the $629 itself is the problem, but rather that they're being forced to spend it on something that many people don't agree is "essential" in any way. Is it about security, or is it about crying "security" to push through a pay-to-play market?
> but rather that they're being forced to spend it on something that many people don't agree is "essential" in any way.
Putting the price aside just for a second, are there really people out there who think that code signing isn't worthwhile? Remember paint.net/filezilla having ad links to "Download Now" that would download... not paint.net or filezilla?
And moreso for a cross-platform tool. Essentially it's forcing devs to spend money on the Windows platform only, where they might prefer to spend it in a way that benefits all their users.
Yeah, I mean people should definitely be paying ImageMagick. Or perhaps it's more true to say, "ImageMagick should definitely figure out a way to become a business."
But that's a thin line. Free certificates negate security.
Instead, there are various foundations that sponsor popular open source projects for costs like signing certificates and hosting. I'm sure one of these should be trustworthy enough to obtain a signing certificate themselves so they can issue and revoke certs to various projects without much cost.
Good point about the size of fees. However, I don’t mostly view the problem as the tech industry failing to fund open source.
I think that framing overly emphasizes an existing problem, which is the perception that OSS is sort of a charity. This misperception only reinforces the negative sense of entitlement that people have towards open source.
A couple of ways that the sense of entitlement manifests itself is the expectation that OSS should be free and, if money is involved, then it should be in the form of pay-what-you-want donations, or subscriptions, not tied to a specific exchange of value. The concept of funding can encompass this vagueness.
The word ‘Transactions’, I think, is a more precise and correct term, as it more clearly relates to desired and sustainable goal of a defined and measured exchange of value.
So instead of the issue being merely the providing of funding, rather, I see it as an issue with the open-source community not fully recognizing that it’s an industry in its own right.
This lack of awareness hampers its ability to participate effectively in the marketplace, including financial transactions to sustain itself.
On another note, I share your view that these fees are troublesome. While I agree that small fees can serve as proof of identity—verifying that the software indeed comes from the claimed source, which seems to be one main intent of signatures—I don’t understand why these fees have to be exorbitant.
It seems more like artificial price inflation, perhaps even a form of cartel behavior.
I have to pay money to access the Internet. That seems like a much bigger deal for a more core service than this. If we want to talk about financial gate keeping this isn’t in the first ten thousand items I in the list.
Yet you didn't really make it for "Free". That's part of the lie (innocent here surely) that developers time is "limiteless and cost free". Lies such as these lead to and support the abusive and exploitative sense of entitlement that many, unfortunately, take towards OSS.
It's costs are many. If you have a more humane bent you will consider the psychological toll, and note the many "I'm leaving OSS" posts one can observe. If you have a different bent you may appreciate the more economic cost incurred by this lack of market efficiency: an exploitative market that fails to ensure commensurate exchange of value does not have much future.
At best, "cost free" OSS is a short-term play, murkily backed by the same "robber baron" attitudes than underpin the exploitation of workers (and the gaslighting of the whole class to believe they can expect nothing more), throughout human history.
Let's not permit OSS to go down this sad, tired and disastrous path. You can't grow the productive output of a market unless you respect property rights and exchange of value.
"Freedom for whom?" For the developers whose time they invested. For the users who are not "free" of their problems that prompt them to see these "free" solutions?
Nothing about OSS is free. "Free" is a lie. Pernicious, in that it was passed off under the guise of some ideal, yet it undermines the long term sustainability of the field by supporting a sense of entitlement.
Step one would probably be to stop the incessant shitting on everyone that suggests source available developers do, in fact, have a right to find ways to extract value out of their code, and that the OSI is probably the cause of all the funding woes.
But since we’re still not past even this after YEARS, I have little faith that we’ll ever get there.
It's clearly an impassioned topic for you, but it's important to remember that your passion may be clouding your judgement.
While indeed methods exist, many problems remain, and it's useful to note that not all systems currently used may be appropriate for all creators.
Your suggestion that complaints about current solutions are invalid, implies a lack of empathy with those who aren't served by existing mechanisms. This view could come across as too one-sided, which might hamper its ability to be taken seriously.
Similarly, your comment seeks to curtaIl any critic of OSI licenses, and while it's true they provide many protections and benefits, it's also true that many new licenses and mechanisms are being used as a result of gaps in the current approach.
Failing to understand the concerns of other segments of the ecosystem with which you may not be acquainted, does not mean their complaints are without merit. You may take it as an opportunity to better grasp the realities facing creators to give you a clearer understanding of the issue overall.
Ha! Your username is hilarious. Have you seen those cat-cucumber videos? What is up with that?? Hahaha :)
Thanks for your comment; it's certainly thought-provoking. You're advocating for a more strategic look at the challenges open source projects face, which I appreciate. Also, I like your "Socratic"-style! :)
Firstly, you mention that framing this as a "money problem" pits us against bigger players with more resources. While that's a concern, the idea that you can't succeed if you don't already have money is fundamentally flawed. Every large business started small. In the realm of open source, financial challenges aren't unsolvable; they require a new transactional approach.
On the security aspect, yes, established authorities have a stronghold, but that's not unbreakable. Look at services like Let's Encrypt, which offers free SSL certificates at scale. They emerged as a disruptor, challenging the established norms in a market that was seemingly locked down.
And to your final point, about "the house always wins," I'd say this defeatist attitude is the real obstacle. The notion that we can't or shouldn't try to change the system is harmful. You say the house always wins, but who exactly are the "insiders" here? Are we just supposed to accept the status quo, or should we aim for innovation that could make the system more equitable?
So, back to you: what solutions do you see? Or at least, what approach do you think has a fighting chance? I'm genuinely curious to hear your perspective.
I have a point I wish to add that doesn't neatly fit in reply to anyone else, so I'll just reply myself, here:
Restricting the meaning of the word "free" to one defined by "FS" orthodoxy, is very not free, wouldn't you agree? Haha :)
Indeed the word free has many meanings, and consequently care must be taken to avoid confusion. Defining free in a way that only aligns with a particular ideology may be seen as self-serving, or confusing and deceptive. It's important to avoid such biases in order to clearly examine the real issues.
It's understandable, given the dependency of big business on price-free software, that business would not want the "price-free" nature of much software to change. A "price awakening" among creators would directly threaten the bottom lines of these companies. Unfortunately, it seems they are also abusing the ideology of "FS" to create confusing false notions of a "noble software creators who gives away their creations without extracting any money". This is abusive, and exploitative, and it must stop. The way it will stop will be creators waking up. The way they will wake up will be thinking clearly, not simply subjugating themselves to, or repeating, misapplications of "FS" ideology.
Specifically, my commentary here seeks to expose the costs that occur throughout the lifecycle of software creation, and avoid the confusing false equivalences with "FS" ideology. It is by hiding or ignoring those costs that exploitation of creators is permitted to flourish. Training creators to think in ways that do not account costs to their time, or to their creations, or, that make it unacceptable to do so, is abusive. It's a gaslighting mindset that seeks to prevent creators from capturing the value they have a right to.
It's important to avoid deliberately misusing the idealism of a "FS" movement to suggest money should not be exchanged, as this is abusive to creators.
Deliberate blurring of meanings, and the creation of false equivalences and reductions, is deceptive tactic is designed to confuse in order to prevent clear understanding of the issues. This in turn can hamper people asserting their right. In this context, the ideology of the "FS" movement, is often used to create a confusing equivalence with price-free. This in turn suggests there virtue in not requesting payment for software. Overall, this abuse of "FS" ideology is done in order to continue to exploit creators.
In short, the very ideology of freedom you tout is abused as to restrict creators, and oppress their right to financial self-determination. And the "FS" movement is misused in this way to create an ideological fake justification for not capturing value from software. It's important to not participate in the perpetuation of such harmful lies and misuses of principles.
While the ideologies of free software are commendable, they must not be used to repress the freedom of creators to earn from their creations, as is attempted to be done with the line of argument espoused in your comment.
It can be difficult to see people earning from their creations, and it's understandable to have fear that you will not be able to afford software if this idea of charging for it spreads. However, it's important to understand that the current situation is abusive and must be terminated. Exploitation is not sustainable, and the software economy must respect the rights of all participants in order to be just.
I challenge folks to advocate for a more positive and inclusive stance on this issue, that supports creators and clear thinking about the issues involved! :) Dispelling muddy thinking must be a top priority of anyone who aligns with that, and to that end, I encourage you all to re-evaluate your injection of "FS" points into these moments. :)
Doesn't capture enough value. Not proportional to creative output as it should be. Fair idea for just general living, everyone should receive that. But, if you create value, you get rewarded. Capitalism FTW
My desktop text editor, KeenWrite, uses Wine, rcedit-x64.exe, osslsigncode, and a shell script to sign the Windows binary. First, rcedit-x64.exe tags the binary with identifying information:
Echoing what Rodeoclash wrote: Having to pay to play on Windows for an open-source project that makes $0 is a decline of ownership over our own machines.
I've been through hell and back on both Windows and MacOS with application signing. It's only getting worse.
First thing I have to note is that this really makes me want to offer anything as a web app. The browser offers a much better experience in so many ways and security is a well thought out integrated experience unlike these 25 year old operating systems bolting security on as an after thought. Clearly no one at Apple cares about this but that would be funny if this was the crack in the dam that broke down their hardware software monopoly.
Second thing is why can't a third party offer this as a service? I'm not limited in the number of apps I can sign technically, right? Why would people using my app care that the certificate says it is signed by me instead of (trusted by the os) ABC, corp that (Microsoft|Apple) says in their overlaid dialog they trust. They could revoke something in the chain but it's technically possible right? Is this explicitly prohibited in some EULA I accepted in a brain fog?
I've gone through exactly that decision tree for Pianojacq and even though it made a lot of stuff much harder (notably: database work) I'm really happy with the result and apparently so are the users. Funny thing: I recently had someone tip me off to start using it :) They were quite surprised I was the main author.
Wouldn’t this be a liability though? In this scenario are you just blindly signing whatever? If yes, that’s obviously not good. The alternative is you have a long review and audit process but in the event something falls through the cracks, this still bites you.
I would be happy to pay for the service. It wouldn't be just the cost of the certificate. It would be the months of labor spent fighting the operating systems and their intricacies. This feels like knowledge that could be managed at scale much better than me doing it in isolation. The cost to me is much greater than just the cost of the certificate, though it's an issue for open source work. And I would be so happy to subsidize that work through a reputable service that was consistent and did that fighting for me.
Seeing as we're now HTTPSing everything under the sun including the malicious, I don't see the problem signing every single binary under the sun regardless malevolence.
WASM and WebGPU are closing the performance gaps between browser and native. It's getting to the point where if it's not a device driver, it can probably be recompiled for use client-side in the browser.
Yet another bytecode runtime, as many others since the 1960's, and a GPU technology based on 2015's hardware capabilities, only supported currently by ChromeOS (nee Web).
I recently went through this same issue at my company - only found out about the change in requirements when I couldn't renew my cert at the previous provider.
There is surprisingly little info available on how to do code signing for Windows now. I don't want to use a physical device - with fully remote teams it's not feasible. Eventually settled on Azure KeyVault with Digicert (I don't like Comodo aka Sectigo). There is really little info available on how to get it all to work together, and you have to spent around $600 before you can even try and see whether it can work.
Now that it's all configured, the setup works well. The new setup of doing the signing via Azure is more secure than storing the private keys on the CI system. But I never thought that signing an app for Windows would be more difficult than signing for macOS or iOS.
Hey, is there any chance you could do a writeup on how you did things? due to the lack of information you mention, I think it might be useful for a lot of people there, including me.
I'm probably not gonna get to a full post anytime soon, but I'll summarize here. This is from memory, so I may have some things wrong.
1. DigiCert CS certificate. You can validate your organization before paying anything, but it felt like we ended up in a low-priority queue because of that. After not hearing back for 2-3 weeks, I emailed support, then got validated in a day or two.
2. Azure KeyVault: "Premium" pricing model, since you need RSA 3072-bit or RSA 4096-bit HSM-backed keys. Generate a CSR here. There are a couple of annoying steps such as getting the access control setup right, but nothing too complicated.
3. Once you have a validated org and paid for the CS certificate, you can upload the CSR to DigiCert, and download the certificate.
4. "Merge" the certificate on Azure KeyVault.
5. Create an "application" on Azure which gives you API credentials. You need to copy a whole bunch of IDs:
# key vault:
azure-key-vault-url
azure-key-vault-certificate
# client application:
azure-key-vault-tenant-id
azure-key-vault-client-id
azure-key-vault-client-secret
You use the above with AzureSignTool to do the signing, e.g. from you CI system.
It's not the way the OP did it, but there's a blog post here on how to ship apps using cloud signing with the Conveyor tool. The title talks about Electron but it should work for any kind of app (not tested with .net)
It appears legit, in that vim and transmission link back to it.
Right now the "foundation" is run by the SignPath company. But TBF they say they hope the foundation will eventually scale, and become independent and community run.
So much for 'Developers, developers, developers!'.
If there is one thing that seems to be common amongst large tech companies it is that it all starts out looking great, then after a few years the rot sets in and if they manage to hang on long enough eventually they turn into parasitic entities. There is no way that a company the size of Microsoft could not come up with a way of working that would enable the FOSS world that they claim to be such huge supporters of to deploy on their platform without hassle or cost. All of this friction in the name of security always accidentally helps the bottom line.
Readit News
I can afford to pay for certificates (I believe I have to have one for Windows and OSX) but I refuse to for a project that I already give away my time for.
I would love to see a LetsEncrypt style service for OSS but I assume it's against the core interests of Microsoft / Apple to allow something like this as it would start to drive people away from the walled gardens of the app stores.
I've been writing software for close to 25 years and it's quite sad to watch the decline of ownership over our own machines in the same of "security".
[1] https://www.vodon.gg/
People have been asking Let's Encrypt itself for this on the Let's Encrypt forum since the project was founded.
The usual answer is that code signing certificates are (supposedly) trying to attest to a legal identity in the hope of being able to punish people offline if they publish malware, or allow people or organizations to have a policy about only installing software known to be from a certain list of publishers. DV certificates for HTTPS are trying to attest to control of a name in the DNS, which is verifiable by automated technical means, and which is not necessarily related to offline identity. (ICANN says it should be ... in an indirect way ... which isn't always complied with, and which, following increased pressure from European privacy law, is often not visible to the public.)
A Let's Encrypt certificate would confirm that a certain key is apparently controlled by someone who apparently also controls a certain DNS name. But a code signing certificate would supposedly go further and confirm that it's apparently controlled by someone acting on behalf of a certain named legal person existing in a certain jurisdiction. This is much more expensive to verify usefully, although maybe some governments will eventually have a way to automate it.
This isn't to say that either kind of certificate is necessarily ideal for all of the different uses to which relying parties end up putting it nowadays, but just that what they're attesting to, and how you would verify it, is pretty different.
Edit: There seems to be a longer discussion about related points in this thread already at https://news.ycombinator.com/item?id=38056024
I'm fine with "installer have been signed with somebody who owns imagemagick.org"
Maybe I’m naive but I feel like the solution is pretty obvious: just crowdsource the cost of the certificate and only sign the software as long as the money keeps coming in.
If people really do care that much they should be willing to help shoulder the cost, and if they’re not then there shouldn’t be a problem with it being unsigned.
For utility style apps, Microsoft's app store is a joke.
Deleted Comment
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.
https://github.com/technion/rustypwneddownloader/blob/main/....
This worfklow isn't usable with these new rules, and I'm having a hard time with the assertion that moving builds to my desktop to use a hardware signing key and uploading them in a non automated, non transparent fashion is an improvement on security.
For most projects it is an improvement, for better or worse.
First issue: private keys stored in files can be stolen silently, and then the only recourse is revocation. That's the main reason for the HSM requirement: malware authors have been doing this for some time now and revocation is difficult/expensive for various reasons. An HSM can also be stolen but only in the old fashioned way of breaking into your office or home and grabbing it, which you're going to notice.
You may object that the credentials for using the HSM can be stolen, and that's true, but they can also be changed easily and quickly. So if you notice that your PIN has been keylogged, you can recover from the compromise then change the PIN and you're done, no need to revoke the certificate.
Second issue: automated signing in CI can actually be risky. It means anyone who can push code to your CI system can get code signed as yourself, possibly without you even being aware of it. The key is held online at all times, so obviously if the CI system gets hacked then it's game over, but even without that it boils down to anyone who can push code into the system becoming a weak point, especially because CI systems are running lots of arbitrary code without being closely monitored. CI signing is at best 1-factor security.
If you sign locally then the key can be (literally) offline until the moment you do a release, and access to it can be constrained via 2-factor auth: the key is something you have, the credential is something you know. So this is quite secure.
For signing nightly dev builds, internal tools and other transient binaries that shouldn't get out into the wild anyway, you can self-sign which is free.
Still, though, it should just be a matter of money. The $629/year cloud-hosted HSM mentioned in the OP will do it. If you pay that, you can use this procedure to make it work with GitHub Actions with the same sort of signtool or Set-AuthenticodeSignature command that you use now: https://docs.digicert.com/en/software-trust-manager/ci-cd-in...
While I’m unsure if Azure is suitable for actual companies I think the risk is ok for what I need it for and the API quality as well as OIDC support make it quite nice to use with GHA.
[1] https://github.com/jborean93/PowerShell-OpenAuthenticode [2] https://github.com/vcsjones/AzureSignTool
So all that would change is where the signing part happens, either in the cloud or on your local runner...
Not sure which way to lean if this is an improvement or not security wise :-)
It’s a glaring example of how the tech industry fails to financially support the very open-source projects that it relies so heavily upon.
Despite offering incredible value, these projects often can’t capture enough of it to sustain themselves.
It’s a sobering reminder that something significant needs to change in how we approach and value open-source contributions.
I don't think the $629 itself is the problem, but rather that they're being forced to spend it on something that many people don't agree is "essential" in any way. Is it about security, or is it about crying "security" to push through a pay-to-play market?
Putting the price aside just for a second, are there really people out there who think that code signing isn't worthwhile? Remember paint.net/filezilla having ad links to "Download Now" that would download... not paint.net or filezilla?
See my other comment for how i consider this may be cartel behavior: https://news.ycombinator.com/item?id=38056460
Deleted Comment
Instead, there are various foundations that sponsor popular open source projects for costs like signing certificates and hosting. I'm sure one of these should be trustworthy enough to obtain a signing certificate themselves so they can issue and revoke certs to various projects without much cost.
I see it as a failure to provide security systems like this without the need for financial gatekeeping.
$629.00 isn't a trivial amount of money.
I think that framing overly emphasizes an existing problem, which is the perception that OSS is sort of a charity. This misperception only reinforces the negative sense of entitlement that people have towards open source.
A couple of ways that the sense of entitlement manifests itself is the expectation that OSS should be free and, if money is involved, then it should be in the form of pay-what-you-want donations, or subscriptions, not tied to a specific exchange of value. The concept of funding can encompass this vagueness.
The word ‘Transactions’, I think, is a more precise and correct term, as it more clearly relates to desired and sustainable goal of a defined and measured exchange of value.
So instead of the issue being merely the providing of funding, rather, I see it as an issue with the open-source community not fully recognizing that it’s an industry in its own right.
This lack of awareness hampers its ability to participate effectively in the marketplace, including financial transactions to sustain itself.
On another note, I share your view that these fees are troublesome. While I agree that small fees can serve as proof of identity—verifying that the software indeed comes from the claimed source, which seems to be one main intent of signatures—I don’t understand why these fees have to be exorbitant.
It seems more like artificial price inflation, perhaps even a form of cartel behavior.
I refuse to accept this as a normal thing to do. Microsoft inflicted this upon the Windows ecosystem themselves.
It's costs are many. If you have a more humane bent you will consider the psychological toll, and note the many "I'm leaving OSS" posts one can observe. If you have a different bent you may appreciate the more economic cost incurred by this lack of market efficiency: an exploitative market that fails to ensure commensurate exchange of value does not have much future.
At best, "cost free" OSS is a short-term play, murkily backed by the same "robber baron" attitudes than underpin the exploitation of workers (and the gaslighting of the whole class to believe they can expect nothing more), throughout human history.
Let's not permit OSS to go down this sad, tired and disastrous path. You can't grow the productive output of a market unless you respect property rights and exchange of value.
Nothing about OSS is free. "Free" is a lie. Pernicious, in that it was passed off under the guise of some ideal, yet it undermines the long term sustainability of the field by supporting a sense of entitlement.
Can’t edit now. Thank you for clarifying!
But since we’re still not past even this after YEARS, I have little faith that we’ll ever get there.
While indeed methods exist, many problems remain, and it's useful to note that not all systems currently used may be appropriate for all creators.
Your suggestion that complaints about current solutions are invalid, implies a lack of empathy with those who aren't served by existing mechanisms. This view could come across as too one-sided, which might hamper its ability to be taken seriously.
Similarly, your comment seeks to curtaIl any critic of OSI licenses, and while it's true they provide many protections and benefits, it's also true that many new licenses and mechanisms are being used as a result of gaps in the current approach.
Failing to understand the concerns of other segments of the ecosystem with which you may not be acquainted, does not mean their complaints are without merit. You may take it as an opportunity to better grasp the realities facing creators to give you a clearer understanding of the issue overall.
If you frame it as “security” problem, you are already nothing compared to those who are believed to have the final say on “security”.
Before you play, remember that the house always wins.
Thanks for your comment; it's certainly thought-provoking. You're advocating for a more strategic look at the challenges open source projects face, which I appreciate. Also, I like your "Socratic"-style! :)
Firstly, you mention that framing this as a "money problem" pits us against bigger players with more resources. While that's a concern, the idea that you can't succeed if you don't already have money is fundamentally flawed. Every large business started small. In the realm of open source, financial challenges aren't unsolvable; they require a new transactional approach.
On the security aspect, yes, established authorities have a stronghold, but that's not unbreakable. Look at services like Let's Encrypt, which offers free SSL certificates at scale. They emerged as a disruptor, challenging the established norms in a market that was seemingly locked down.
And to your final point, about "the house always wins," I'd say this defeatist attitude is the real obstacle. The notion that we can't or shouldn't try to change the system is harmful. You say the house always wins, but who exactly are the "insiders" here? Are we just supposed to accept the status quo, or should we aim for innovation that could make the system more equitable?
So, back to you: what solutions do you see? Or at least, what approach do you think has a fighting chance? I'm genuinely curious to hear your perspective.
Restricting the meaning of the word "free" to one defined by "FS" orthodoxy, is very not free, wouldn't you agree? Haha :)
Indeed the word free has many meanings, and consequently care must be taken to avoid confusion. Defining free in a way that only aligns with a particular ideology may be seen as self-serving, or confusing and deceptive. It's important to avoid such biases in order to clearly examine the real issues.
It's understandable, given the dependency of big business on price-free software, that business would not want the "price-free" nature of much software to change. A "price awakening" among creators would directly threaten the bottom lines of these companies. Unfortunately, it seems they are also abusing the ideology of "FS" to create confusing false notions of a "noble software creators who gives away their creations without extracting any money". This is abusive, and exploitative, and it must stop. The way it will stop will be creators waking up. The way they will wake up will be thinking clearly, not simply subjugating themselves to, or repeating, misapplications of "FS" ideology.
Specifically, my commentary here seeks to expose the costs that occur throughout the lifecycle of software creation, and avoid the confusing false equivalences with "FS" ideology. It is by hiding or ignoring those costs that exploitation of creators is permitted to flourish. Training creators to think in ways that do not account costs to their time, or to their creations, or, that make it unacceptable to do so, is abusive. It's a gaslighting mindset that seeks to prevent creators from capturing the value they have a right to.
It's important to avoid deliberately misusing the idealism of a "FS" movement to suggest money should not be exchanged, as this is abusive to creators.
Deliberate blurring of meanings, and the creation of false equivalences and reductions, is deceptive tactic is designed to confuse in order to prevent clear understanding of the issues. This in turn can hamper people asserting their right. In this context, the ideology of the "FS" movement, is often used to create a confusing equivalence with price-free. This in turn suggests there virtue in not requesting payment for software. Overall, this abuse of "FS" ideology is done in order to continue to exploit creators.
In short, the very ideology of freedom you tout is abused as to restrict creators, and oppress their right to financial self-determination. And the "FS" movement is misused in this way to create an ideological fake justification for not capturing value from software. It's important to not participate in the perpetuation of such harmful lies and misuses of principles.
While the ideologies of free software are commendable, they must not be used to repress the freedom of creators to earn from their creations, as is attempted to be done with the line of argument espoused in your comment.
It can be difficult to see people earning from their creations, and it's understandable to have fear that you will not be able to afford software if this idea of charging for it spreads. However, it's important to understand that the current situation is abusive and must be terminated. Exploitation is not sustainable, and the software economy must respect the rights of all participants in order to be just.
I challenge folks to advocate for a more positive and inclusive stance on this issue, that supports creators and clear thinking about the issues involved! :) Dispelling muddy thinking must be a top priority of anyone who aligns with that, and to that end, I encourage you all to re-evaluate your injection of "FS" points into these moments. :)
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/installe...
Then osslsigncode applies the certificate:
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/scripts/...
Echoing what Rodeoclash wrote: Having to pay to play on Windows for an open-source project that makes $0 is a decline of ownership over our own machines.
First thing I have to note is that this really makes me want to offer anything as a web app. The browser offers a much better experience in so many ways and security is a well thought out integrated experience unlike these 25 year old operating systems bolting security on as an after thought. Clearly no one at Apple cares about this but that would be funny if this was the crack in the dam that broke down their hardware software monopoly.
Second thing is why can't a third party offer this as a service? I'm not limited in the number of apps I can sign technically, right? Why would people using my app care that the certificate says it is signed by me instead of (trusted by the os) ABC, corp that (Microsoft|Apple) says in their overlaid dialog they trust. They could revoke something in the chain but it's technically possible right? Is this explicitly prohibited in some EULA I accepted in a brain fog?
There is surprisingly little info available on how to do code signing for Windows now. I don't want to use a physical device - with fully remote teams it's not feasible. Eventually settled on Azure KeyVault with Digicert (I don't like Comodo aka Sectigo). There is really little info available on how to get it all to work together, and you have to spent around $600 before you can even try and see whether it can work.
Now that it's all configured, the setup works well. The new setup of doing the signing via Azure is more secure than storing the private keys on the CI system. But I never thought that signing an app for Windows would be more difficult than signing for macOS or iOS.
Somewhere at Microsoft two sales guys are high-fiving each other upon reading this comment. Mission. Fucking. Accomplished.
1. DigiCert CS certificate. You can validate your organization before paying anything, but it felt like we ended up in a low-priority queue because of that. After not hearing back for 2-3 weeks, I emailed support, then got validated in a day or two.
2. Azure KeyVault: "Premium" pricing model, since you need RSA 3072-bit or RSA 4096-bit HSM-backed keys. Generate a CSR here. There are a couple of annoying steps such as getting the access control setup right, but nothing too complicated.
3. Once you have a validated org and paid for the CS certificate, you can upload the CSR to DigiCert, and download the certificate.
4. "Merge" the certificate on Azure KeyVault.
5. Create an "application" on Azure which gives you API credentials. You need to copy a whole bunch of IDs:
# key vault:
azure-key-vault-url
azure-key-vault-certificate
# client application:
azure-key-vault-tenant-id
azure-key-vault-client-id
azure-key-vault-client-secret
You use the above with AzureSignTool to do the signing, e.g. from you CI system.
https://hydraulic.dev/blog/21-shipping-electron-apps-from-ci...
From their website:
If it's legit, then it could be a useful option.Right now the "foundation" is run by the SignPath company. But TBF they say they hope the foundation will eventually scale, and become independent and community run.
If there is one thing that seems to be common amongst large tech companies it is that it all starts out looking great, then after a few years the rot sets in and if they manage to hang on long enough eventually they turn into parasitic entities. There is no way that a company the size of Microsoft could not come up with a way of working that would enable the FOSS world that they claim to be such huge supporters of to deploy on their platform without hassle or cost. All of this friction in the name of security always accidentally helps the bottom line.
That said - and maybe I'm missing something - but why did did ImageMagick wait til the _day of expiration_ to make this post?!