If libsodium is useful to you, please keep in mind that it is maintained by one person, for free, in time I could spend with my family or on other projects. The best way to help the project would be to consider sponsoring it, which helps me dedicate more time to improving it and making it great for everyone, for many more years to come.
Frank does great work that is critical to many businesses, and should get funded to do it professionally.
However, donating money to an open collective is prohibitively hard for most big companies. Maybe the world should be different (or maybe not, since it would be easy for employees to embezzle money if they could direct donations easily), but that's how it works currently.
AFAICT, there is also no fiscal sponsor, so the donation matching suggested in a sister comment won't apply.
This is why Geomys (https://geomys.org) works the way it does, and why it has revenue (ignoring the FIPS and tlog sides of the business) which is 30-50x of some GitHub Sponsors "success stories": we bill in a way that's compatible with how companies do business, even if effectively we provide a similar service (which is 95% focused on upstream maintenance, not customer support).
I am not saying it's for everyone, or that Frank should necessarily adopt this model, or that it's the only way (e.g. the Zig foundation raises real amounts of money, too), but I find it frustrating to see over and over again the same conversation:
- "Alice does important maintenance work, she should get professionally funded for it!"
- "How does Alice accept/request funding?"
- "Monthly credit card transactions anchored at $100/mo that are labeled donations"
- no business can move professional amounts of money that way
- "Businesses are so short-sighted, it's a tragedy of the commons!"
Anyone who solicits donations should also sell overpriced books of some sort, because it’s often very easy to get even a $500 book approved as an expense where a $5 “donation” causes hell.
With the year prominently displayed, i.e. "20XX Edition", to reflect when it was current. To help people track how long it has been since they dona-bought their last copy. And so purchase documentation explains repeat purchases.
> However, donating money to an open collective is prohibitively hard for most big companies.
You are absolutely correct. However, that's the mechanism that Frank has made available, and that's what the comment I was replying to was asking, so I was just connecting the dots between the question and answer.
While it might be frustrating to see non-viable options presented as ways to fund critical FOSS, it's even more frustrating to see blame effectively being placed on the maintainer; particularly because, if companies like Apple really wanted to fund this work, I'm pretty sure they could figure something out.
Anyway, looking at the model you propose, it seems like the main difference is that Frank just doesn't explicitly say "you can retain my services"? Is that all that's stopping Apple from contacting him and arranging a contract?
> if companies like Apple really wanted to fund this work, I'm pretty sure they could figure something out.
Having spent the last ~6 years in big tech consistently frustrated by the rigidity of the processes and finding clever ways to navigate (see: wade through the bullshit), this isn’t as easy as you’d hope. The problem is that someone has to spend a non-trivial amount of time advocating internally for something like this (a “non-standard process”) which generally means asking pinging random people across finance, procurement, and legal how to deal with it and 99% of people will just throw up their hands (especially in this case because they don’t understand the importance of it). If things don’t fit a mold in these big companies, they fall into the event horizon and are stretched out to infinity.
Couldn’t you just go up your chain to the VP or whatever and use their backing / negotiating at the VP level to organize? It might not work for random projects but if Apple is using libsodium for security this could presumably be pitched as an investment into their own software supply chain.
Filippo is another maintainer, of extremely similar open source software with entirely the same customer base, offering (important) advice to a peer, so I don't think policing his tone is helpful here.
I know who he is and what he does. I think we probably disagree on whether that makes the comment in better or worse taste.
Otherwise, I agreed with him, and am genuinely curious whether the stopping factor here is maintainers like Frank simply not saying "you can email me to retain my services"
> if companies like Apple really wanted to fund this work, I'm pretty sure they could figure something out
A reminder that companies are not a hive mind.
Many people at Apple surely would love to funnel piles of money to open source. Maybe some of them even work in the Finance or Procurement or Legal departments. But the overwhelming majority of Apple’s procurement flow is not donations, and so it is optimized for the shape of the work it encounters.
I bet there are plenty of people working at Chick-fil-A who wish it was open on Sundays. But it’s not ~“blaming the user” to suggest that as it stands, showing up on Sunday is an ineffective way to get chicken nuggets.
The idea that donations are the only way they could fund this work is what I was talking about. I'm sure Apple has various contractors and other forms of employees.
It's like suggesting that Chic-Fil-A really does want to open on Sunday, but the only thing stopping them is customers not telling them they want it open on Sunday.
Given the increasing obviousness that there's functionally no oversight of NGOs and government funding, perhaps we just need some NGOs and get government grants for these critical services.
If you donate via GitHub Sponsors to https://github.com/jedisct1 from an individual / personal account GitHub won't take a cut (or pays for it from their own purse) for any credit card processing fees.
I'm planning to spend my evening checking every other Ed25519 implementation I can find to see if this check is missing any where else in the open source ecosystem.
I found several libraries that simply didn't implement the check, but none that implemented in incorrectly in the same way as the vulnerability discussed above.
> Did you also check all of the libraries that implement the check differently to libsodium?
Yes, but it was a breadth-first search sourced from the ianix webpage, so I certainly missed some details somewhere. I'll continue to search over the coming weeks in my spare time (if I can get any).
> Please read it and let me know and I'm very sorry for the last report :) also please don't close it as N/A and please don't publish it without my confirm to do not harm my Reputation on hacker on community
I was 90% sure it was a troll too, but based on this second report I'm not so sure anymore.
I'd been staying out of this conflict, partly because I'm not really in the know on WP Engine's behavior behind-the-scenes and, as weird as Mullenweg's plays have been, I don't like to comment on things I'm not fully read into.
But, this touches on a particular hobby horse of mine. It involves some old conflicts too, but I don't want to ruminate on them.
From about 2016 to 2019, I was heavily involved with trying to remedy what I considered an existential threat to the Internet: WordPress's auto-updater.
If that sounds alarming, consider the enormity of WordPress's market share. Millions of websites. W3Techs estimates it powers about 43% of websites whose server-side stack is detectable. At the time, it was a mere 33%.
For the longest time, the auto-updater would pull an update file from WordPress.org, and then install it. There was no code-signing of any form until I got involved. So if you pop one server, you get access to potentially millions.
Now imagine all of those webservers conscripted into a DDoS botnet.
Thus, existential threat to the Internet.
Eventually, we solved the immediate risk and then got into discussing the long tail of getting theme and plugin updates signed too.
You can read my ideas to solve this problem for WordPress (and the PHP ecosystem at large) here: https://gossamer.tools
Here's the part that delves into old drama: Mullenweg was so uncooperative that I wrote a critical piece called #StopMullware (a pun on "malware") due to his resistance to even commit to solving the damn problem. On my end, I reimplemented all of libsodium in pure PHP (and supported all the way back to 5.2.4 just to cater to WordPress's obsession with backwards compatibility to the lowest common denominator), and just needed them to be willing to review and accept patches. Even though I was shouldering as much of the work as I logically could, that wasn't enough for Matt. After he responded to my criticism, I took it down, since he committed in writing to actually solving the problem. (You can read his response at https://medium.com/@photomatt/wordpress-and-update-signing-5... if you care to.)
The reason I'm bringing this old conflict up isn't to reopen old wounds. It's that this specific tactic that Mullenweg employed would have been mitigated by solving the supply chain risk that I was so incandescent about in 2016.
(If you read my proposals from that era, you'll notice that I cared a lot about the developers controlling their keys, not WordPress.)
I don't keep up-to-date on Internet drama, so maybe someone already raised this point elsewhere. I just find it remarkable that the unappreciated work for WordPress/PHP I did over the years is relevant to Mullenweg's current clusterfuck. Incredible.
Since my knowledge on the background noise that preceded this public conflict is pretty much nil, I have no reason to believe WP Engine hold any sort of moral high ground. And I don't really care either way.
Rather, I'd like to extend an open invitation: If anyone is serious about leading the community to fork off WordPress, as I've heard in recent weeks, I'm happy to talk at length about my ideas for security enhancements and technical debt collection. If nothing else comes of this, I'd like to minimize the amount of pain experienced by the community built around WordPress, even if its leadership is frustrating and selfish.
Very interesting. I’ve been writing code for a while but if I’m honest I have no idea how code signing works. Any good resource on how it works especially in php?
That doesn't move the needle as far as restoring the trust you've broken.
You should negotiate with WP Engine to drop their suit contingent on your resignation. Maybe they'll go for it. Resigning is the only thing that would prove you're serious about allowing your power to be checked. And perhaps the only thing that would stop you from cutting a huge settlement check (probably within weeks and not the years you've anticipated).
Do you think that's something you're capable of? Do you care more about the future of WordPress and of open source than you do about your own power and rivalries? Will you prove it to us?
To be frank I don't believe you will. I'm pretty cynical about this kind of thing. But I've been wrong before. It would take a very strong person to admit, not just publicly but to their bitter rivals, that they had lost control and damaged their own life's work.
But if that person is you - it wouldn't be much, but you'd have my admiration.
---
Stark: Make peace with the Lannisters, you say? With the people who tried to murder my boy?
Baelish: We only make peace with our enemies, my lord.
> In this lawsuit against you and your mother, is it you or her who is accused of sexual harassment and racism?
Both (and the company through which they employed the plaintiff) are accused of the various discrimination, harassment, wage theft, etc., violations.
(EDIT: Though his mother is apparently accused of doing the direct racially- and religiously-bigoted statements, and the persistent graphic descriptions of Matt's sexual escapades, Matt's role -- other than as ultimately responsible as employer -- is participating directly in retaliation by taking complaints about the behavior back to his mother who accelerated rather than taking action to curtail them.)
> I don’t have access to read the case details.
You don't need access, you just need to go straight to the court site instead of a third-party aggregator.
And, if you had a nickel for every currently-active lawsuit against Matt and his mom for that kind of thing filed on June 9, 2022, you'd have two nickels, which isn't a lot, but it's interesting that there is more than one...
Am I reading this correctly? This guy owns an LLC through which he directly employs a personal healthcare team for his mother? And Mr. "Post-Economic" couldn't pay his nurses a fair wage?
> PLEASE TAKE NOTICE that Defendants hereby respectfully object to the Case Management Order, Notice of Time and Place of Trial and Trial Related Orders dated May 23, 2024. Since the filing of Defendants’ Case Management Conference Statement on May 21, 2024, Mira Hashmall, lead counsel for Defendants, has had a 5-7 day trial scheduled with a start date of March 17, 2025. With the trial in this matter starting on March 10, 2025, and trial in Case No. CGC-22-600095 starting on March 24, 2025, that would be three back-to-back trials and potential overlap amongst them.
In the years since I wrote that, several people have pointed out that "versioned protocols" are just a safe form of "crypto agility". However, when people say "crypto agility', they usually mean something like what JWT does.
> But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition.
This makes sense in situations where you have versioned protocols :)
This doesn't work if you're required to support RSA with PKCS1v1.5 padding until the heat death of the universe.
Hmmm, some recent protocols (thinking of MLS[1] here) have moved into a middle territory where they have a lot of options for piecing together a cryptographic suite, but then version that whole suite within the protocol. You can still change suites without changing the protocol, but it's not nearly as 'agile' as earlier suite and primitive negotiations.
Maybe something more like "cryptographic mobility" instead of "agility"? You can carefully decamp and move from one suite (versioned protocol) to another without changing all your software, but you're not negotiating algorithms and semantics on the fly.
> So I'm not so sure what's the point of encryption at rest in AWS except just to tick off a compliance and regulatory checklist.
> The private key is with them anyway, just don't encrypt and save few milliwatts of power.
"Them" is Amazon, a company with over 1 million employees, last I checked.
It's perfectly reasonable to trust the KMS team to keep your keys secure, even if you don't trust the RDS team to never try to look at your data.
I know it's tempting to think of all of AWS as a sort of "Dave" who wears multiple hats, but we're talking about a large company. Protecting against other parts of the same company is still a worthwhile and meaningful security control.
> It's perfectly reasonable to trust the KMS team to keep your keys secure, even if you don't trust the RDS team to never try to look at your data.
If the database is live, then the data is able to be decrypted and who knows where it ends up. Encryption at rest solves only the threat scenario where the RDS team has access to the database storage layer. It doesn't do anything to mitigate any threats after it has been read from storage.
As a customer, I don't know neither I do care how they have teamed up internally. Not my problem.
From my perspective, the secret keys I don't have. Just AWS has and they can decrypt whatever and whenever they want maybe because they have a warrant or some three letter agency has them do it.
> The author is confusing "it costs us nothing (now that encryption can be done in hardware and is integrated into most desktop operating systems) and protects in some scenarios, so yeah, we just decided to mandate it always be done" with "PEOPLE THINK ENCRYPTION AT REST IS A MAGIC BULLET LOOK AT ME I'M INSIGHTFUL, POST LINKS TO MY BLOG ON LINKEDIN!"
What in the article gave you that impression?
I do not hold this confusion in my mind, nor did I deliberately encode such a statement in my blog. I'm curious why you think this is what I was saying.
> The whole post is insulting to the intelligence of even a fairly junior desktop support technician.
If that was true, every time someone posts "Show HN: My Hot New Database Encryption Library in Haskell", they would be mitigating the confused deputy attack by design, rather than what we see today: Namely, failing to even protect against padding oracle attacks.
That's what the article was actually talking about.
If you're using a secure disk encryption technology, and you manage to clear the keys from the TPM or overwrite the header containing the KDF salts and other metadata, that should render the device data unrecoverable.
> I find it very hard to believe Amazon's or Google's servers do not already have full disk encryption.
I am confident that they do. Even better, they can be configured to use your KMS key rather than the service key, and you can configure KMS to use external key stores (i.e., an HSM in your datacenter outside of AWS's control, that you could theoretically pull the plug on at any time).
Hope that helps.
reply