Contributions: Oct 25 – Nov 1, 2026 9 merged, 3 in progress in workerd https://jasnell.me/contributions/2026-W44 #rss #feeds #linksharing #qwibbit

Our Response To The eMudhra Key Disclosure Incident The Go Blog Our Response To The eMudhra Key Disclosure Incident Roland Shoemaker, on behalf of the Go Security team 26 October 2026 On October 19, the Go team initiated an expedited security release to protect Go users and their applications from a critical public key infrastructure (PKI) compromise involving certificates issued by eMudhra. Within approximately seven and a half hours of being notified, we shipped a targeted patch, which was included in our first-ever URGENT track security release. Here is the context behind the incident, why Go stepped in at the runtime level to protect our users and how our incident response unfolded. eMudhra Incident On October 17, Mozilla added eight intermediate certificates (six used for TLS, and two used for code signing) issued by a root certificate controlled by eMudhra to OneCRL, effectively blocking their usage in Firefox. Soon after, a number of security researchers noticed this and began investigating what might’ve caused this. On October 19, the Go Security team was made aware of these investigations and their conclusions, which showed that the keys associated with these intermediates were trivially weak, allowing recovery of the private keys in microseconds. Due to the fact that the eMudhra root certificate was present in most trusted root programs, recovering the private keys would allow any attacker to sign arbitrary TLS certificates for any domain name, without the usual requirement to show proof of control of said domain name. This would allow an attacker to man-in-the-middle (MITM) TLS connections and present a valid certificate for a domain name they did not control, effectively allowing them to impersonate any TLS server the targeted machine attempted to connect to. Go ships a TLS certificate verifier in the standard library. When users use net/http or crypto/tls to connect to a TLS service, the verifier is called to check if the certificates the other side of the connection presents are valid. On Windows and macOS we delegate these checks to the platform APIs, and on Linux, which lacks platform APIs, we use our own verifier implementation. Since Linux does not have a uniform built-in mechanism to handle revocation checking, and in order to provide a timely fix for users on other platforms that might not receive platform updates, we decided the best way to protect Go users was to do an URGENT track security release which similarly removed trust. Incident Timeline A typical Go security release follows a multi-day process, with advanced pre-announcements in order to allow those who rely on Go to prepare. In this case, because we believed that private key exposure was imminent, our team chose to use the URGENT track for the first time in order to ship protections before active public exploitation could begin. 11:45 PDT Our Security team was alerted by an independent external researcher, citing unreported actions by Mozilla and other organizations to remove trust in eight eMudhra intermediates. It became clear quickly that this was due to weak private keys they used. 12:30 PDT Mozilla independently reported the issue to our Security team, confirming the issue, and asking that we not immediately disclose the issue, but encouraging us to release a fix as soon as possible. 14:00 PDT We finalized a patch which blocked the usage of certificates which chained to the compromised intermediates, and thanks to the researcher who initially alerted us to the issue, had a set of certificates signed using the recovered keys to test against. 15:00 PDT We began the process to release minor Go versions 1.27.3 and 1.26.10 containing our patch. Due to the urgent nature of this issue and its exploitability, and with the belief that the private keys would likely become publicly known within hours, we decided an immediate release was the most prudent option. 19:13 PDT We finalized the release and announced it publicly. At this time the underlying issue was still not widely known. In an effort to give other defenders a chance to protect as many users as possible without revealing to attackers how the issue could be exploited, our patch and communications were somewhat opaque, warning users that we were “blocking trust in a small set of intermediate certificates due to specific security concerns around their operation” and urging users to immediately upgrade to this release. In under seven and a half hours from initial notification, patched Go releases were live worldwide, giving users everything they needed to secure their deployments before the keys became public. By the morning of October 20, numerous independent researchers had publicly disclosed the weak keys. Lessons Learned and Future Improvements This was our first ever URGENT track security release, and during the release process we ran into a number of issues which caused the release to take longer than expected. While we are happy we were able to get a release out the same day we were notified of the issue, in the modern security environment we feel that we should be able to provide releases in a more compressed timeline. The issues we ran into caused our release process to take just under four and a quarter hours from start to finish. These issues had previously not been problematic, since the typical release process is split up over a number of days. We’ve subsequently made a number of changes to improve our release efficiency, which should significantly reduce the time it takes us to push out a release, enhancing our ability to quickly respond to urgent security threats. PRIVATE track security fixes are pre-announced three to seven days before their release. URGENT track fixes happen on a shorter time schedule, but we could have pre-announced the upcoming release when we began the release process, giving users at least a few hours to prepare. While on Windows and macOS we rely on the revocation mechanisms the platform APIs provide, on Linux we don’t currently have a similar mechanism. The lack of this support was one of our major drivers to issue an expedited security release, as we did not want to leave Linux users exposed to this issue longer than was necessary. Hence we are planning on prioritizing work to bring parity to revocation support on Linux, to help mitigate this class of issues in the future. Part of this work will involve investigating adding support for the upki project, which aims to “provide reliable, privacy-preserving and efficient certificate revocation” for Linux (see issue #82402). Upgrading and Verifying Your Deployments If you run Go binaries which interact with network services using TLS (such as directly via net/http or crypto/tls or via a dependency such as gRPC), ensure you are running on the latest minor releases. Binaries rebuilt with Go 1.27.3 and 1.26.10 will automatically reject certificates issued by the compromised eMudhra intermediates. You can verify your current toolchain version using go version and you can check the version of Go a binary was built with using go version -m . The govulncheck tool can also be used to determine if a binary is affected by this issue: $ GOTOOLCHAIN=go1.27.3+auto go install golang.org/x/vuln/cmd/govulncheck@latest $ govulncheck -mode=binary Securing Go Deployments Everywhere For us, securing Go and its users extends beyond fixing direct security vulnerabilities in the runtime and libraries we ship. In order to keep the ecosystem secure, we believe we also need to provide users with the right tools to write secure software, look towards the future of cryptographic algorithms and protocols, and proactively respond to ecosystem wide issues when we can. We are grateful to the independent security researchers and the Mozilla security team for this rapid notification and coordination during this incident. Previous article: Help set Go's priorities for next year Blog Index https://go.dev/blog/emudhra-incident #rss #feeds #linksharing #qwibbit

Contributions: Oct 18–25, 2026 13 merged, 5 in progress in workerd and node https://jasnell.me/contributions/2026-W43 #rss #feeds #linksharing #qwibbit

“ignore the slop” Lots of people who are against the use of AI for all its ethical and inherent issues tell me this. Just ignore it. Don’t let big AI control us. The “slop” they refer to is anything created that involved an AI, and in our case (the curl project) it is in particular vulnerability reports. “Ignoring the slop” cannot be done and it doesn’t help. Vulnerability reports created with the help of AIs point out actual problems, and sometimes vulnerabilities. Ignoring real vulnerabilities because they were found by AI does not make users safe and secure. It makes them vulnerable. We don’t want that. I personally don’t refer to this as AI slop because the reports are typically accurate and correct, even if much too wordy. I think “slop” implies that it is wrong, misleading or otherwise bad content. One can certainly object to the use of AI, but when we get real vulnerabilities reported and proven, we cannot in good faith pretend they don’t exist just because we think the tech involved in digging them up is questionable. That would be a disservice to, or even betrayal of, our users. We make curl secure for our users. Obligations An Open Source project typically gives no guarantees at all, so there are no legal requirements that force us to fix flaws. We are however a project with high goals of quality and stability and we would jeopardize our name and track record if we now would stop delivering on that. Also, a few of us involved in the project also sell curl related support and services, where at least part of that means providing secure curl releases, so we still have this contractual obligation to a set of customers. And they wouldn’t be customers in the fist place if the Open Source project didn’t already have the proven quality track record. So no, we really cannot ignore vulnerability reports. The slop is gone A sizeable portion of users seem to still believe we still suffer from a lot of made up and hallucinated reports by these AIs. We really don’t. Almost all the stupidity and lies we saw in the vulnerability reports made by AIs in the past have ceased. Since spring 2026 the slop reports are practically gone. Our current challenge is much harder: high volume, high quality. AI talks too much They always use too many words. Every report is now hundreds of lines and the explanations are convoluted and detailed (and often repeat themselves multiple times). In a good report, the human writes a first paragraph explaining the problem briefly and then they submit the full report. It’s annoying when the reporter surrender everything to the AI, including the communication part. The AIs are also still bad at figuring out exactly where the line is between a bug and a vulnerability, and if it is a vulnerability, what severity it is. This is not a surprise though, as this is also the case for human reporters. A good trend is that they often produce good reproducers or proofs of concept helping to trigger and prove the problem/vulnerability. That was a really complicated part of the reporters’ work back in the day, now it’s just a prompt or two. Everything is with AI now These days, like within the last few months, we have received hundreds of vulnerability reports submitted to curl and every single one had AI involved to some extent. It is generally easy to tell on the language and the length and details of the report. https://daniel.haxx.se/blog/2026/10/22/ignore-the-slop/ #slop #vulnerability #ignore #opensource #ais #rss #feeds #linksharing #qwibbit

Help set Go's priorities for next year The Go Blog Help set Go's priorities for next year Cameron Balahan, on behalf of the Go team 21 October 2026 Hi Gophers! The 2026 Go Developer Survey is now open. We run this survey every year to understand how you use Go and the challenges you face. Your answers directly shape how we plan and prioritize our work. Last year, 5,379 of you responded, and your top frustration was making sure your code follows best practices and Go idioms (33% of respondents). Since then, we shipped a rewritten go fix in Go 1.26 that automatically modernizes your code, and added more modernizers in Go 1.27. You can read everything we learned in the 2025 results. Take the survey here. It’s open through November 3, takes about 10–20 minutes, and every question is optional. We’ll share the results on this blog in early 2027. Please share the survey with your colleagues, friends, and online communities—the more Go developers we hear from, the better we understand what you need. Thank you for helping shape the future of Go! Previous article: Interactive refactoring in gopls Blog Index https://go.dev/blog/survey2026-announce #nextyear #cameronbalahan #set #survey #blogindex #october #developersurvey #gophers #november #interactive #rss #feeds #linksharing #qwibbit

Do minor curl vulnerabilities in the open The curl project has decided to alter its vulnerability disclosure program procedure and starting October 26 2026, we insist that all vulnerability reports submitted to us that are deemed to be severity LOW or MEDIUM should instead be submitted as issues in our GitHub repository. Only vulnerabilities deemed to be HIGH or CRITICAL will be kept private in the HackerOne tracker. Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH. Issues submitted to HackerOne we deem are LOW or MEDIUM will be requested to be resubmitted on GitHub and will be closed as informative on HackerOne (and publicly disclosed). Avalanche survival tricks This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We must act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown. Public vs private By opening up the process we allow the whole world to participate. Both in the assessment and understanding of the report and claimed vulnerability, but also in the creating and writing the advisory and figuring out details of when the issues was introduced etc. Ideally we get better help to make sure the fix is the correct one, that it fixes the problem, and any other related problem that is similar and that it does not miss a related problem sitting next to this. An obvious recent trend is that the moment we announce a new set of CVEs and their associated fixes, there is an army of AI-using researchers who throw all those at their models and harnesses to find similar mistakes or omissions in the fixes. By taking this process to the public all the way, ideally we get more help to do that scrutiny better before we ship releases. We recognize that the amount of work needed per received vulnerability report does not shrink by doing them in public, but we think that we might share the burden among more people easier, and we hope that lessons and documentation brought up in these discussions will be easier to spot and learn from. The open process can also allow distros and other users of curl to keep up with security fixes earlier and better. The risks Several people have suggested there is a risk that researchers mistakenly submit severity HIGH issues on GitHub thinking they are LOW or MEDIUM. It is basically unheard of that a researcher would have understated a reported problem so I consider that a low risk scenario. Also: there was already before this a risk that someone would submit a vulnerability report in the public, it is not a new risk. Handling some vulnerabilities in the public of course makes the immediately available for both good and bad people. This policy will give bad people a slightly longer window of opportunity to exploit weaknesses at the expense of existing curl users. That is unfortunate but we see no way of avoiding this. We limit this practice to less than HIGH for this reason: at least these problems are not terrible. Severity LOW We have discussed simply dismissing all severity LOW issues, but within the CVE program there is an appeals process and if we don’t hand out a CVE to an actual vulnerability, then someone else will do it. We thus cannot ignore true vulnerabilities, or they will come back to bite us nonetheless. We can however resist and refuse silliness and I personally aim to deny and decline more vulnerabilities harder on the basis that they do not actually hurt any users or existing applications. Crazy combos A clear trend these days is that many newly reported vulnerabilities are figured out by AI models that create crazy sequences or option combinations that do something unexpected, but the sequence is something that aren’t likely to ever be used in the real world, or the unexpected that happens is something that occurs every time so applications doing this would spot the problem immediately. I.e problems that have almost no risk to actually trigger in the real world. We save no users by insisting on doing the CVE dance for those issues. We only get work for ourselves and a whole world that has to act on them. Flow control it There is an almost infinite number of combinations you can use libcurl’s many options, protocol mixes and flexible API to do things that might not be clearly documented and the AIs will continue to try them all and together with the humans driving these checks they are super eager to treat every minor discrepancy as a vulnerability. We can’t continue down this spiraling path with our sanity intact. We don’t have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way. How to assign severity We only use these for levels in the curl project: LOW, MEDIUM, HIGH and CRITICAL. Often we refer back to recently managed vulnerabilities to see how we judged them, but we also provide a set of basic guidelines. I’m sure we can also make them better and clearer. https://daniel.haxx.se/blog/2026/10/20/do-minor-curl-vulnerabilities-in-the-open/ #low #curl #medium #high #public #open #hackerone #issues #github #ideally #rss #feeds #linksharing #qwibbit

Contributions: Oct 11–18, 2026 18 merged, 12 in progress in workerd and node https://jasnell.me/contributions/2026-W42 #rss #feeds #linksharing #qwibbit

Interactive refactoring in gopls The Go Blog Interactive refactoring in gopls Hongxiang Jiang 16 October 2026 When editing code in a modern IDE or editor, developers rely on its refactoring features to automate common transformations. Today, we are excited to introduce interactive refactoring in gopls, powered by a new capability we are proposing for the Language Server Protocol (LSP) that brings dynamic, multi-step dialogs directly into your favorite editor. Crucially, we designed this capability (in collaboration with the Dart team) not just for Go, but as an open standard for all programming languages and editor ecosystems. Working support is already available in gopls v0.24.0 and the official Go extension for VS Code v0.56.0. What is the Language Server Protocol (LSP)? The LSP is an open standard that decouples language-specific features from specific text editors. As you navigate and edit code, your editor (such as VS Code, Neovim, or Emacs) and a language server (like gopls) engage in a continuous JSON-RPC exchange to provide features like autocomplete, hover documentation, diagnostics, and code actions. Multi-step code transformation Today, almost every code transformation in the LSP is like a function of no parameters: you trigger the operation, and the server immediately computes the edits. (Renaming a symbol is the sole exception: because it is a function of one parameter, the desired new name, it required its own dedicated PrepareRename RPC in the protocol.) "Add struct tags", without questions The language server must deduce the user’s intent from context alone, namely the cursor position and the enclosing syntax tree. When that context is not enough, the server is forced into one of two choices: apply a one-size-fits-all default, or refrain from offering the transformation altogether. The limitation lies not in gopls’s ability to compute the necessary edits, but in the LSP’s lack of a mechanism for language servers to ask the user for input. For many transformations, this parameterless model works well. But many others need additional input from the user: which struct tags to add and in what naming convention, which interface to implement, which file to move a declaration to. Without a way to ask, gopls could only guess—“Add struct tags”, for example, always produced json tags in camelCase—or not offer the refactoring at all. With interactive refactoring, language servers can now easily provide new operations with one or more parameters. "Add struct tags", with questions While some language extensions have worked around this limitation by embedding custom, language-specific dialog logic directly into individual editors, doing so leaves behind other editors (such as Neovim and Emacs) that stick strictly to the LSP with minimal custom client code. More importantly, editor-specific workarounds go against the fundamental purpose of the LSP: to decouple language-specific features from editors so that each server improvement benefits every client. Our LSP interactive refactoring proposal (microsoft/language-server-protocol#1164) solves this by establishing a standard mechanism for language servers to collect user input before computing text edits. For Go developers, this unlocks a suite of long-awaited refactorings, including: golang/go#70583: Move Declaration golang/go#38028: Change Signature golang/vscode-go#1547: Implement Interface golang/vscode-go#2002: Modify Struct Tags among many others. Interactive refactorings in action Adding and removing struct tags (gopls v0.23.0) When configuring serialization formats, developers frequently need custom tags and casing conventions. Previously, running “Add struct tags” unconditionally injected json tags using camelCase formatting. With interactive refactoring: Place your cursor on any struct definition and select the “Add struct tags” code action. An input dialog appears, pre-filled with json, allowing you to customize any combination of tags (such as json,yaml,db). A second dialog lets you select your desired naming convention (such as camelCase, snake_case, or PascalCase). Gopls generates and applies the formatted struct tags across your type definition. Interactive "Add struct tags" in VS Code Here is the before-and-after transformation: type UserProfile struct { ID int64 FirstName string LastName string EmailAddr string } type UserProfile struct { ID int64 `json:"id" db:"id"` FirstName string `json:"first_name" db:"first_name"` LastName string `json:"last_name" db:"last_name"` EmailAddr string `json:"email_addr" db:"email_addr"` } Similarly, “Remove struct tags” now asks you for the specific tag keys you wish to delete (for example, removing only db tags while preserving the json tag), rather than wiping out all struct tags indiscriminately. Interactive "Remove struct tags" in VS Code Implementing interfaces with dynamic symbol search When creating a type to satisfy an interface, developers previously had to copy the interface declaration and manually turn it into a set of methods on the receiver type (or rely on external tools like impl by manually typing the receiver and qualifying the name of the interface). Since gopls v0.23.0, with interactive refactoring: Place your cursor on any concrete type and select the “Add methods to X to implement an interface…” code action. A text entry field appears, inviting you to choose the name of an interface type. It makes dynamic queries to gopls to auto-complete names of types in your workspace and the standard library (for example, maphash.Hasher). If the selected interface has type parameters, gopls asks for a concrete type argument for each type parameter (such as Foo). Gopls generates complete method stubs with appropriate receiver names and instantiated method signatures. Interactive "Add methods to implement an interface..." in VS Code type Foo struct{} type MyHasher struct{} type Foo struct{} type MyHasher struct{} // Equal implements [maphash.Hasher]. func (m *MyHasher) Equal(x Foo, y Foo) bool { panic("unimplemented") } // Hash implements [maphash.Hasher]. func (m *MyHasher) Hash(*maphash.Hash, Foo) { panic("unimplemented") } Moving declarations across files and packages (preview) Moving declarations manually by cutting and pasting can easily break references and requires tedious import cleanup across multiple files. While scheduled for an upcoming gopls release, our working implementation already demonstrates how interactive file selection streamlines cross-file and cross-package moves: Place your cursor on any top-level declaration and select the “Move declaration X” code action. A file picker dialog lets you choose an existing destination .go file or specify a new file path. Gopls moves the declaration along with its dependent declarations (such as unexported helpers or methods) while leaving unrelated symbols in place, updates references across your workspace, and cleans up imports in both the source and destination files. Interactive "Move declaration" in VS Code In the example below, we move the type Foo from package from to package to. Its method Print and the unexported constant bar, which only Foo uses, move along with it, while the unrelated function Baz stays behind: // from/from.go package from import ( "fmt" "strings" ) const bar = "bar" // Doc comment for Foo type Foo struct{} func (f Foo) Print() { fmt.Println(bar) } func Baz() string { return strings.ToUpper("baz") } // from/from.go package from import "strings" func Baz() string { return strings.ToUpper("baz") } // to/to.go package to import "fmt" const bar = "bar" // Doc comment for Foo type Foo struct{} func (f Foo) Print() { fmt.Println(bar) } Slaying the dragon (gopls v0.24.0) As a demonstration of multi-step interactive dialogs and a self-contained test case for client editor implementations, gopls v0.24.0 offers a “Slay the dragon” code action when you place your cursor on a package-level variable named dragonSlayer (for example, var dragonSlayer string). Happy hunting! What’s on the Horizon Interactive refactoring establishes a foundational capability in gopls, opening up several exciting directions on our roadmap: Change signature refactoring (#38028): Adding, removing, or reordering function parameters across a workspace requires input that cannot be deduced from syntax alone, such as the new parameter order or the default argument expression to insert at existing call sites. Interactive forms allow gopls to collect these details before rewriting the declaration and all call sites. Interactive conflict resolution: When a code transformation encounters naming collisions, identifier shadowing, or ambiguous references, gopls can ask the user for guidance, such as asking for permission to proceed or offering to rename conflicting symbols on the fly. Interactive commands beyond code edits: Because interactivity is modeled at the LSP command layer, it naturally generalizes to non-edit server operations that require user configuration, such as configuring test or benchmark runs with profiling flags (CPU, memory, tracing). Getting Started and Sharing Feedback Interactive refactoring is available in gopls v0.24.0 and vscode-go v0.56.0 (with proof-of-concept client integrations also explored for Neovim and Emacs). We would love to hear your thoughts as we continue refining interactive code actions in gopls: For general feedback or feature requests, file an issue on the Go issue tracker. To read the full technical specification—including the stateless form protocol design and alternative approaches we explored—or to join the discussion with the broader LSP community, check out the LSP Interactive Code Actions design document and the ongoing conversation in microsoft/language-server-protocol#1164. (Special thanks to Alan Donovan, Alex Putman, Brian Wilkerson, Danny Tuppeny, Hana Kim, Madeline Kalil, Peter Weinberger, and Robert Findley for their insights, discussions, feedback, and collaboration on this work.) Happy refactoring! Previous article: Better HTTP/1 connection reuse Blog Index https://go.dev/blog/interactive-refactoring #rss #feeds #linksharing #qwibbit

Contributions: Oct 4–11, 2026 18 merged, 5 in progress in node and workerd https://jasnell.me/contributions/2026-W41

OSI approved the curl license curl started out GPL licensed, as direct inheritance from its httpget days, but in October 1998 we switched to the Mozilla Public License (MPL). In 2001, we added the MIT license as an additional license to optionally use in addition to MPL. We made curl dual licensed because clearly the MPL license caused problems for some users – primarily because it was deemed not compatible with GPL. In 2002 we dropped the MPL option and curl was from then on licensed only under the MIT license. Kind of. The twist Because of reasons we cannot recall anymore, I decided to ever so slightly edit the language in the MIT license text around that time. (I strongly discourage anyone else from doing this, and if my time machine was functional I would go back and correct this decision.) The license text we then kept referring to and thinking about as an MIT license, was in fact not exactly MIT anymore. No one objected at the time. I can’t remember anyone really considering the implications at the time. Maybe because not that many people noticed or cared. It was in essence still the MIT license. Much later Decades later, the SPDX project quite correctly and ruthlessly made the distinction between a proper MIT and a modified MIT matter: they created a separate and unique identified to the license curl uses. It may be almost like MIT but they deemed the differences big enough to say that the curl license is a special beast. It is since then known as the curl license. SPDX-License-Identifier: curl Sort of MIT but not I have over the years casually kept referring to the license as MIT since it helps users understand even though it is technically incorrect. Open Source people in general tend to know the MIT license and the implications of using it. A drawback with having our own license is that it was not immediately recognized and known as Open Source or Free Software; not acknowledged and verified by FSF nor OSI. OSI approved On April 17, 2026. The Open Source Initiative approved the curl license. It is since then officially arguably slightly more Open Source than before. I don’t think anyone ever doubted or that it was actually much of a drawback in adoption or usage, but it feels good to finally have this checkmark. Why now? I write about this now (many months after the fact) because I totally forgot that this was happening and I only recently realized OSI approved it back in April. The curl license verbatim COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1996 - 2026, Daniel Stenberg, [email protected], and many contributors, see the THANKS file. All rights reserved. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. https://daniel.haxx.se/blog/2026/10/15/osi-approved-the-curl-license/