Skip to content

🚨 [security] Update nokogiri 1.15.4 → 1.19.4 (minor)#393

Open
depfu[bot] wants to merge 1 commit into
masterfrom
depfu/update/nokogiri-1.19.4
Open

🚨 [security] Update nokogiri 1.15.4 → 1.19.4 (minor)#393
depfu[bot] wants to merge 1 commit into
masterfrom
depfu/update/nokogiri-1.19.4

Conversation

@depfu

@depfu depfu Bot commented Jun 19, 2026

Copy link
Copy Markdown

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

↗️ nokogiri (indirect, 1.15.4 → 1.19.4) · Repo · Changelog

Security Advisories 🚨

🚨 Nokogiri: Possible Use-After-Free when setting an attribute value via `Nokogiri::XML::Attr#value=` or `#content=`

Summary

Nokogiri’s CRuby native extension could leave a Ruby wrapper pointing to freed memory when replacing the value of an XML attribute. If Ruby code had already accessed an attribute child node, Nokogiri::XML::Attr#value= could free the underlying native child node while the wrapper remained reachable through the document node cache. A later use of the freed child node or a Ruby GC mark could dereference an invalid pointer, causing an invalid read and a possible segfault.

Nokogiri 1.19.4 preserves any already-wrapped attribute child nodes before replacing the attribute value.

JRuby is not affected.

Severity

The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must directly access an attribute's child node and then replace that same attribute's value via Attr#value= or #content=. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. Already-wrapped attribute child nodes are preserved before the value is replaced.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround, avoid accessing attribute child nodes directly via Attr#child or similar before mutating the same attribute’s value.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Possible Use-After-Free when `Nokogiri::XML::Document#encoding=` raises an exception

Summary

Calling Document#encoding= with an invalid encoding (e.g., a non-string, or a string containing a null byte) raises an exception, but only after freeing the document's current encoding string without replacing it. The document is left referencing freed memory, so the next call to Document#encoding reads invalid memory, which can cause a segfault or leak freed bytes into a Ruby String.

Affects the CRuby (libxml2) implementation only; JRuby is not affected.

Severity

The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must pass an invalid encoding to Document#encoding=, rescue the resulting exception, and then continue using the same document. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. The document no longer references freed memory after the exception is raised.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

If users are unable to upgrade, avoid passing attacker-controlled values to Document#encoding=. Applications that only assign developer-authored encodings are not directly exposed.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Possible Use-After-Free in XInclude Processing

Summary

XInclude substitution performed by Nokogiri::XML::Node#do_xinclude replaced each <xi:include> in place, freeing the include node along with its children (such as <xi:fallback> and its descendants) and any namespaces declared on them. If an application had already exposed one of those nodes or namespaces to Ruby, the corresponding Ruby object was left pointing at freed memory. Using the object could result in invalid reads or writes to memory.

Nokogiri 1.19.4 substitutes each <xi:include> on a defensive copy by default, so the structures libxml2 frees are never the ones bound to live Ruby objects.

Only the CRuby implementation is affected; JRuby is not affected.

Severity

The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must parse a document without XInclude, traverse into an <xi:include> subtree to expose its nodes or namespaces to Ruby, and only then invoke XInclude processing. The common case, requesting XInclude at parse time, operates on a freshly parsed document whose nodes are not yet exposed to Ruby and is not affected. Nokogiri 1.19.4 makes this pattern safe by default and requires no change to application code.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround for earlier versions, perform XInclude substitution at parse time (with the xinclude parse option) rather than calling #do_xinclude on a document that has already been traversed. A freshly parsed document has no nodes exposed to Ruby, so the substitution is safe.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Possible Use-After-Free when directly using `NokogirI::XML::XPathContext` beyond document lifetime

Summary

Nokogiri::XML::XPathContext did not keep its source document alive for garbage collection. If an XPathContext outlived its document and the document was collected, evaluating an XPath expression could read invalid memory and potentially segfault.

This is only reachable when application code constructs an XPathContext directly and lets the document become unreachable while continuing to use the context. The normal Document#xpath, #css, and related search methods are not affected, and it is not triggerable by malicious document input.

Nokogiri 1.19.4 makes XPathContext keep its source document alive for as long as the context exists.

Only the CRuby implementation is affected. JRuby is not affected.

Severity

The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must construct an XML::XPathContext directly and continue using it after allowing its source document to be garbage-collected. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. The context now keeps its source document alive for as long as it exists.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround, ensure the source document remains referenced for as long as any XPathContext created from it is in use. The standard Document#xpath, #css, and related search methods already do this and are unaffected.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Possible Use-After-Free when setting `Document#root=` to an invalid node type

Summary

Nokogiri::XML::Document#root= validated only that the new root was a Nokogiri::XML::Node, allowing a DTD node to be set as the document root. The result is a heap use-after-free during garbage collection or finalization, leading to an invalid memory read or potentially a segfault.

Nokogiri 1.19.4 restricts Document#root= to element nodes, raising TypeError for any other node type.

This memory-safety issue affects only the CRuby implementation (libxml2). The JRuby implementation was not affected; the same input validation was added there for behavioral parity.

Severity

The Nokogiri maintainers have evaluated this as low severity. This is only triggered by a programming error. It requires application code to assign a non-element node such as a DTD as the document root via Document#root=. Nokogiri 1.19.4 now raises TypeError instead of allowing a use-after-free. It cannot be triggered by untrusted input or through normal use of the public API.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround, applications that cannot upgrade should avoid assigning a DTD (or any non-element node) via Document#root=.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Possible Out-of-Bounds Read in `Nokogiri::XML::NodeSet#[]`

Summary

Nokogiri::XML::NodeSet#[] (and its alias #slice) checked the requested index against the node set's bounds using a 32-bit-truncated copy of the index. A large negative index could pass the check and then be used at full width, reading outside the node set's storage. On CRuby this is an out-of-bounds read that typically crashes the process; on JRuby it is not memory-unsafe but returns an incorrect node.

Nokogiri 1.19.4 performs the bounds check against the full-width index.

Severity

The Nokogiri maintainers have evaluated this as medium severity.

Exploitation requires an application to pass an attacker-controlled integer to NodeSet#[]. The primary impact is a controlled crash (denial of service), with potential for memory disclosure on CRuby.

On JRuby, Nokogiri is not affected by this vulnerability.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

As a workaround, applications that index a NodeSet with externally-supplied integers can validate the index against node_set.length before use, or avoid passing untrusted values as an index.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: Null Pointer Dereference calling methods on uninitialized wrapper classes

Summary

Nokogiri contains a bug when calling certain methods on allocated-but-uninitialized native wrapper classes that inherit from Nokogiri::XML::Node. This caused a NULL pointer dereference that could crash the process.

Nokogiri 1.19.4 checks for missing native data pointers and raises a RuntimeError.

JRuby is not affected.

Severity

The Nokogiri maintainers have evaluated this as low severity. This is only triggered by a programming error. It requires application code to call .allocate directly on a native-backed class and then invoke methods on the resulting uninitialized object. It cannot be triggered by untrusted input or through normal use of the public API.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

Avoid calling .allocate directly on Nokogiri native-backed classes. Use the documented constructors and factory methods instead.

Credit

This issue was responsibly reported by Zheng Yu from depthfirst.com.

🚨 Nokogiri: XML::Schema on JRuby allows network requests when NONET is set, bypassing CVE-2020-26247

Summary

The NONET parse option, which Nokogiri turns on by default for Nokogiri::XML::Schema (see CVE-2020-26247), was not correctly enforced on the JRuby implementation. As a result, a schema parsed with default options could still cause external resources to be fetched over the network, potentially enabling SSRF or XXE attacks.

Nokogiri 1.19.4 replaces the scheme denylist with an allowlist. When NONET is enabled, only local resources (a file: scheme, or a relative or absolute path with no scheme) are resolved, and every network scheme is blocked, case-insensitively. This brings the JRuby behavior in line with CRuby.

Only the JRuby implementation is affected. CRuby is not affected, because libxml2's xmlNoNetExternalEntityLoader blocks all network schemes at the I/O layer regardless of scheme or case.

Severity

The Nokogiri maintainers have evaluated this as low severity (CVSS 2.6, CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N). It is a bypass of CVE-2020-26247, which was scored the same way.

Mitigation

Upgrade to Nokogiri 1.19.4 or later.

There are no known workarounds for affected versions.

This change properly enforces NONET on JRuby, which is a breaking change for any code that (perhaps unknowingly) relied on the previous behavior to load network resources with default parse options. If you trust your input and want to allow external resources to be accessed over the network, you can explicitly disable NONET, exactly as documented for CVE-2020-26247:

  1. Ensure the input is trusted. Do not enable this option for untrusted input.
  2. Pass a Nokogiri::XML::ParseOptions with the NONET flag turned off:
# allows resources to be accessed over the network for trusted input
schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)

References

Credit

This issue was responsibly reported by @bilerden.

🚨 Nokogiri XSLT transform has a memory leak

Summary

Nokogiri's Nokogiri::XSLT::Stylesheet#transform leaks a small heap allocation when passed a Ruby string parameter containing a null byte.

For applications that pass attacker-controlled input through XSLT.transform parameters, this may be a vector for a denial of service attack against long-running processes.

Mitigation

Upgrade to Nokogiri >= 1.19.3.

Users may also be able to mitigate this issue without upgrading by validating untrusted transform parameters before passing them to Nokogiri::XSLT::Stylesheet#transform.

Severity

The Nokogiri maintainers have evaluated this as Moderate Severity, CVSS 5.3.

Each leaked allocation is approximately 24–32 bytes, so meaningful memory growth requires sustained attacker-controlled traffic at high call rates. The bug does not cause memory corruption, information disclosure, or any change in the behavior of the transform itself, and the string-handling exception is raised as expected.

Applications that do not pass raw attacker-controlled bytes to XSLT parameters are unlikely to be affected in practice.

Resources

Credit

This vulnerability was responsibly reported by @Captainjack-kor.

🚨 Nokogiri CSS selector tokenizer has regular expression backtracking

Summary

Nokogiri's CSS selector tokenizer contains regular expressions whose construction may result in exponential regex backtracking on adversarial selectors. Three ReDoS vectors are addressed in this release:

  1. String-literal tokenization on certain unterminated quoted-string input.
  2. String-literal tokenization on a separate class of hex-escape-rich input.
  3. Identifier tokenization on hex-escape-rich input.

The public CSS selector methods that funnel through the affected tokenizer are Nokogiri::CSS.xpath_for, Node#css, Node#at_css, Searchable#search, and CSS::Parser#parse.

Mitigation

Upgrade to Nokogiri >= 1.19.3.

If users are unable to upgrade, two options are available:

  • Avoid the use of attacker-controlled text in CSS selectors. Applications that only pass developer-authored selectors to Nokogiri are not directly exposed.
  • Set global Regexp.timeout (Ruby 3.2+, JRuby 9.4+) to bound parse time.

Severity

The Nokogiri maintainers have evaluated this as High Severity (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

An attacker able to inject user-supplied text into a CSS selector parse method can cause exponential backtracking, resulting in a potential denial of service.

Resources

Credit

Vector 1 was responsibly reported by @colby-swandale. Vectors 2 and 3 were discovered by @flavorjones during the response to the original report.

🚨 Nokogiri does not check the return value from xmlC14NExecute

Summary

Nokogiri's CRuby extension fails to check the return value from xmlC14NExecute in the method Nokogiri::XML::Document#canonicalize and Nokogiri::XML::Node#canonicalize. When canonicalization fails, an empty string is returned instead of raising an exception. This incorrect return value may allow downstream libraries to accept invalid or incomplete canonicalized XML, which has been demonstrated to enable signature validation bypass in SAML libraries.

JRuby is not affected, as the Java implementation correctly raises RuntimeError on canonicalization failure.

Mitigation

Upgrade to Nokogiri >= 1.19.1.

Severity

The maintainers have assessed this as Medium severity. Nokogiri itself is a parsing library without a clear security boundary related to canonicalization, so the direct impact is that a method returns incorrect data on invalid input. However, this behavior was exploited in practice to bypass SAML signature validation in downstream libraries (see References).

Credit

This vulnerability was responsibly reported by HackerOne researcher d4d.

🚨 Nokogiri patches vendored libxml2 to resolve multiple CVEs

Summary

Nokogiri v1.18.9 patches the vendored libxml2 to address CVE-2025-6021, CVE-2025-6170, CVE-2025-49794, CVE-2025-49795, and CVE-2025-49796.

Impact and severity

CVE-2025-6021

A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.

NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/17d950ae

CVE-2025-6170

A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.

NVD claims a severity of 2.5 Low (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/5e9ec5c1

CVE-2025-49794

A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the <sch:name path="..."/> schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.

NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5

CVE-2025-49795

A NULL pointer dereference vulnerability was found in libxml2 when processing XPath XML expressions. This flaw allows an attacker to craft a malicious XML input to libxml2, leading to a denial of service.

NVD claims a severity of 7.5 High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/62048278

CVE-2025-49796

A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.

NVD claims a severity of 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H)

Fixed by applying https://gitlab.gnome.org/GNOME/libxml2/-/commit/81cef8c5

Affected Versions

  • Nokogiri < 1.18.9 when using CRuby (MRI) with vendored libxml2

Patched Versions

  • Nokogiri >= 1.18.9

Mitigation

Upgrade to Nokogiri v1.18.9 or later.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against patched external libxml2 libraries which will also address these same issues.

References

🚨 Nokogiri updates packaged libxml2 to v2.13.8 to resolve CVE-2025-32414 and CVE-2025-32415

Summary

Nokogiri v1.18.8 upgrades its dependency libxml2 to v2.13.8.

libxml2 v2.13.8 addresses:

Impact

CVE-2025-32414: No impact

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

There is no impact from this CVE for Nokogiri users.

CVE-2025-32415: Low impact

In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

In the upstream issue, further context is provided by the maintainer:

The bug affects validation against untrusted XML Schemas (.xsd) and validation of untrusted
documents against trusted Schemas if they make use of xsd:keyref in combination with recursively
defined types that have additional identity constraints.

MITRE has published a severity score of 2.9 LOW (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) for this CVE.

🚨 Nokogiri updates packaged libxslt to v1.1.43 to resolve multiple CVEs

Summary

Nokogiri v1.18.4 upgrades its dependency libxslt to v1.1.43.

libxslt v1.1.43 resolves:

Impact

CVE-2025-24855

CVE-2024-55549

🚨 Nokogiri updates packaged libxml2 to 2.13.6 to resolve CVE-2025-24928 and CVE-2024-56171

Summary

Nokogiri v1.18.3 upgrades its dependency libxml2 to v2.13.6.

libxml2 v2.13.6 addresses:

Impact

CVE-2025-24928

Stack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix.

CVE-2024-56171

Use-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of xsd:keyref in combination with recursively defined types that have additional identity constraints.

🚨 Nokogiri updates packaged libxml2 to v2.12.7 to resolve CVE-2024-34459

Summary

Nokogiri v1.16.5 upgrades its dependency libxml2 to 2.12.7 from 2.12.6.

libxml2 v2.12.7 addresses CVE-2024-34459:

Impact

There is no impact to Nokogiri users because the issue is present only in libxml2's xmllint tool which Nokogiri does not provide or expose.

Timeline

  • 2024-05-13 05:57 EDT, libxml2 2.12.7 release is announced
  • 2024-05-13 08:30 EDT, nokogiri maintainers begin triage
  • 2024-05-13 10:05 EDT, nokogiri v1.16.5 is released and this GHSA made public

🚨 Nokogiri update packaged libxml2 to v2.12.5 to resolve CVE-2024-25062

Summary

Nokogiri upgrades its dependency libxml2 as follows:

  • Nokogiri v1.15.6 upgrades libxml2 to 2.11.7 from 2.11.6
  • Nokogiri v1.16.2 upgrades libxml2 to 2.12.5 from 2.12.4

libxml2 v2.11.7 and v2.12.5 address the following vulnerability:

Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

JRuby users are not affected.

Mitigation

Upgrade to Nokogiri ~> 1.15.6 or >= 1.16.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile
and link Nokogiri against patched external libxml2 libraries which will also address these same
issues.

Impact

From the CVE description, this issue applies to the xmlTextReader module (which underlies Nokogiri::XML::Reader):

When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

Timeline

  • 2024-02-04 10:35 EST - this GHSA is drafted without complete details about when the upstream issue was introduced; a request is made of libxml2 maintainers for more detailed information
  • 2024-02-04 10:48 EST - updated GHSA to reflect libxml2 maintainers' confirmation of affected versions
  • 2024-02-04 11:54 EST - v1.16.2 published, this GHSA made public
  • 2024-02-05 10:18 EST - updated with MITRE link to the CVE information, and updated "Impact" section
  • 2024-03-16 09:03 EDT - v1.15.6 published (see discussion at #3146), updated mitigation information
  • 2024-03-18 22:12 EDT - update "affected products" range with v1.15.6 information

🚨 Nokogiri update packaged libxml2 to v2.12.5 to resolve CVE-2024-25062

Summary

Nokogiri upgrades its dependency libxml2 as follows:

  • Nokogiri v1.15.6 upgrades libxml2 to 2.11.7 from 2.11.6
  • Nokogiri v1.16.2 upgrades libxml2 to 2.12.5 from 2.12.4

libxml2 v2.11.7 and v2.12.5 address the following vulnerability:

Please note that this advisory only applies to the CRuby implementation of Nokogiri, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

JRuby users are not affected.

Mitigation

Upgrade to Nokogiri ~> 1.15.6 or >= 1.16.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile
and link Nokogiri against patched external libxml2 libraries which will also address these same
issues.

Impact

From the CVE description, this issue applies to the xmlTextReader module (which underlies Nokogiri::XML::Reader):

When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

Timeline

  • 2024-02-04 10:35 EST - this GHSA is drafted without complete details about when the upstream issue was introduced; a request is made of libxml2 maintainers for more detailed information
  • 2024-02-04 10:48 EST - updated GHSA to reflect libxml2 maintainers' confirmation of affected versions
  • 2024-02-04 11:54 EST - v1.16.2 published, this GHSA made public
  • 2024-02-05 10:18 EST - updated with MITRE link to the CVE information, and updated "Impact" section
  • 2024-03-16 09:03 EDT - v1.15.6 published (see discussion at #3146), updated mitigation information
  • 2024-03-18 22:12 EDT - update "affected products" range with v1.15.6 information
Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ racc (indirect, 1.7.1 → 1.8.1) · Repo · Changelog

Release Notes

1.8.1

What's Changed

New Contributors

Full Changelog: v1.8.0...v1.8.1

1.8.0

What's Changed

  • Generate jar to build gem by @nobu in #255
  • Fix trivial typos by @ydah in #257
  • Try to fix test failure with Ruby 3.3 by @hsbt in #260
  • Reformat the rdoc so it renders correctly both locally and on github. by @zenspider in #258
  • Allow racc cmdline to read from stdin if no path specified. by @zenspider in #259
  • Add more grammars by @nurse in #222
  • Exclude 2.5 on macos-latest by @nobu in #263
  • Drop code for Ruby 1.6 by @nobu in #264
  • Refactor command line options by @nobu in #265
  • Change encode EUC-JP to UTF-8 by @ydah in #267
  • Organize README.ja.rdoc by @ydah in #266
  • Support error_on_expect_mismatch declaration in Racc grammar file by @yui-knk in #262
  • Bump up v1.8.0 by @yui-knk in #268

New Contributors

Full Changelog: v1.7.3...v1.8.0

1.7.3

What's Changed

Full Changelog: v1.7.2...v1.7.3

1.7.2

What's Changed

New Contributors

Full Changelog: v1.7.1...v1.7.2

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

@depfu depfu Bot added the depfu label Jun 19, 2026
@depfu depfu Bot mentioned this pull request Jun 19, 2026
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

depfu

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants