🚨 [security] Update mariadb 2.5.6 → 3.5.3 (major)

[depfu]

---

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

---

---

🚨 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 upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ mariadb (2.5.6 → 3.5.3) · Repo · Changelog

Security Advisories 🚨

🚨 MariaDB's connector leaks the cleartext password to an MitM despite `ssl: true`

Summary

When SSL/TLS is enabled but no CA / server certificate is provided, the
connector verifies the server's identity using fingerprint validation. The
check is effective, the connection is ultimately rejected when it fails,
but it happens after the authentication exchange. As a result, the
credentials are sent before validation occurs, so an active man-in-the-middle
who presents their own certificate receives the password in the handshake
before the connection is aborted.

Impact

The credentials are transmitted to the peer before the server's identity is
validated. An on-path attacker (MitM) presenting any certificate can capture
the account password, even though the connection then fails the fingerprint
check and is closed. The disclosed credentials can subsequently be used to
authenticate directly against the server.

• Attacker requirement: active man-in-the-middle position on the network path
• Affected configuration: SSL/TLS enabled without a CA / server certificate

Affected versions

• < 3.2.4
• 3.3.0 – 3.3.2
• 3.4.0 – 3.4.5
• 3.5.0 – 3.5.2

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to one of these (or later)
on your branch.

Workarounds

Until you can upgrade, configure certificate verification explicitly, provide
the server/CA certificate and use a verifying SSL mode (e.g. VERIFY_CA /
VERIFY_FULL).

Reported by haaahaaahiihiiii (no GitHub account).

🚨 MariaDB has Cleartext Transmission of Sensitive Information and Insufficiently Protected Credentials

Summary

When PAM (dialog) authentication is used, the connector can be coerced into sending the account password in cleartext over an insecure connection. A hostile or man-in-the-middle server can trigger this with the default configuration, disclosing the user's password.

Details

The mysql_clear_password plugin is gated behind a secure connection: the driver refuses to transmit the password in cleartext over plain TCP. The sibling PAM plugin handler (SendPamAuthPacketFactory, server-side plugin name dialog) did not override that gate and inherited the default value false, so it was not subject to the same secure-transport requirement.

As a result, a hostile or man-in-the-middle server can issue an Authentication Switch Request for the dialog plugin over plain TCP, and the driver responds with the user's password in cleartext. With the default configuration (sslMode=DISABLE, restrictedAuth=null) this is reachable with no non-default options.

Am I affected?

You are affected if all of the following hold:

You use mariadb Connector/Node.js at a version below the patched release(s).
Connections can occur over an insecure transport: plain TCP (sslMode=DISABLE), or a TLS mode that establishes server identity only via self-signed-certificate fingerprint validation.
An attacker can occupy an on-path (MITM) position, or otherwise cause the client to connect to a server they control, and present an Authentication Switch Request for the dialog plugin.

Connections over properly verified TLS or a local Unix socket are not exposed to this vector.

Impact

Disclosure of the authenticating account's password in cleartext to an on-path or hostile server. The captured credentials can then be reused to authenticate to the database (and, if reused elsewhere, beyond it).

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch (3.5.x → 3.5.3, 3.4.x → 3.4.6, 3.3.x → 3.3.3, 3.2.x and earlier → 3.2.4). PAM (dialog) is now treated exactly like mysql_clear_password: it may only run over a secure transport. SendPamAuthPacketFactory overrides the secure-required flag to true, and the authentication dispatcher permits a secure-required plugin only when the connection is TLS or a local Unix socket. The pre-existing check that blocks non-MITM-proof plugins when server identity relies solely on self-signed-certificate fingerprint validation continues to apply. Net effect: PAM is allowed over TLS or a Unix socket, and rejected over plain TCP or fingerprint-only connections.

Workarounds

If you cannot upgrade immediately:

• Restrict the permitted authentication plugins via restrictedAuth so dialog cannot be negotiated over an insecure transport.
  Avoid PAM (dialog) authentication over plain TCP.

###Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

🚨 MariaDB has possible SQL injection in Buffer parameter escaping under big5/gbk/sjis/cp932/gb18030 client charsets

Summary

A SQL injection is possible when the connector escapes Buffer parameters client-side under a multi-byte client character set whose trail-byte range overlaps the ASCII backslash (0x5C): big5, gbk, sjis, cp932, and gb18030. Under these charsets, an attacker-controlled lead byte can absorb the escape byte the connector inserts, leaving the following quote unescaped so it terminates the string literal and injected SQL is parsed.

Details

When binding a Buffer (binary) parameter, the connector escapes the value byte-by-byte, inserting a backslash (0x5C) before quote (0x27) and backslash bytes. This is correct under single-byte and UTF-8–family charsets, but unsafe under client charsets whose multi-byte trail-byte range includes 0x5C.

On the server, the SQL lexer performs multi-byte character recognition (my_ismbchar) before it interprets escape sequences. If character_set_client is one of the affected charsets and the attacker controls a byte the lexer treats as a valid lead byte, the sequence <0x5C> is consumed as a single multi-byte character. The escaping backslash inserted by the connector is swallowed as that character's trail byte, so the following 0x27 is no longer escaped — it closes the string literal, and the remaining bytes are parsed as SQL.

This is the well-known multi-byte escaping bypass (the same class that historically affected addslashes / mysql_real_escape_string under GBK/Big5), here applied to the connector's client-side Buffer escaping path.

Am I affected?

You are affected if all of the following hold:

You use mariadb Connector/Node.js at a version below the patched releases listed below.
The connection's client character set is one of big5, gbk, sjis, cp932, or gb18030. This is not the default (the default is utf8mb4).
Untrusted data can reach a Buffer-typed query parameter.

Applications using utf8mb4 (or any charset whose trail-byte range does not include 0x5C) are not affected by this vector. Parameters bound through the binary/server-side prepared-statement path are also not affected, because those values are sent out-of-band and are never escaped into the SQL text.

Impact

SQL injection. An attacker able to influence the contents of a Buffer parameter can break out of the intended string literal and inject arbitrary SQL, leading to unauthorized read or modification of data and, depending on the database account's privileges, further compromise.

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch:

• 3.5.x → 3.5.3
• 3.4.x → 3.4.6
• 3.3.x → 3.3.3
• 3.2.x and earlier → 3.2.4 (or any newer release)

Workarounds

If you cannot upgrade immediately:

Use server-side prepared statements (execute) so parameters are bound via the binary protocol rather than escaped into the SQL text.
Avoid passing untrusted data as Buffer parameters under the affected charsets.

Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

🚨 MariaDB's connector leaks the cleartext password to an MitM despite `ssl: true`

Summary

When SSL/TLS is enabled but no CA / server certificate is provided, the
connector verifies the server's identity using fingerprint validation. The
check is effective, the connection is ultimately rejected when it fails,
but it happens after the authentication exchange. As a result, the
credentials are sent before validation occurs, so an active man-in-the-middle
who presents their own certificate receives the password in the handshake
before the connection is aborted.

Impact

The credentials are transmitted to the peer before the server's identity is
validated. An on-path attacker (MitM) presenting any certificate can capture
the account password, even though the connection then fails the fingerprint
check and is closed. The disclosed credentials can subsequently be used to
authenticate directly against the server.

• Attacker requirement: active man-in-the-middle position on the network path
• Affected configuration: SSL/TLS enabled without a CA / server certificate

Affected versions

• < 3.2.4
• 3.3.0 – 3.3.2
• 3.4.0 – 3.4.5
• 3.5.0 – 3.5.2

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to one of these (or later)
on your branch.

Workarounds

Until you can upgrade, configure certificate verification explicitly, provide
the server/CA certificate and use a verifying SSL mode (e.g. VERIFY_CA /
VERIFY_FULL).

Reported by haaahaaahiihiiii (no GitHub account).

🚨 MariaDB has Cleartext Transmission of Sensitive Information and Insufficiently Protected Credentials

Summary

When PAM (dialog) authentication is used, the connector can be coerced into sending the account password in cleartext over an insecure connection. A hostile or man-in-the-middle server can trigger this with the default configuration, disclosing the user's password.

Details

The mysql_clear_password plugin is gated behind a secure connection: the driver refuses to transmit the password in cleartext over plain TCP. The sibling PAM plugin handler (SendPamAuthPacketFactory, server-side plugin name dialog) did not override that gate and inherited the default value false, so it was not subject to the same secure-transport requirement.

As a result, a hostile or man-in-the-middle server can issue an Authentication Switch Request for the dialog plugin over plain TCP, and the driver responds with the user's password in cleartext. With the default configuration (sslMode=DISABLE, restrictedAuth=null) this is reachable with no non-default options.

Am I affected?

You are affected if all of the following hold:

You use mariadb Connector/Node.js at a version below the patched release(s).
Connections can occur over an insecure transport: plain TCP (sslMode=DISABLE), or a TLS mode that establishes server identity only via self-signed-certificate fingerprint validation.
An attacker can occupy an on-path (MITM) position, or otherwise cause the client to connect to a server they control, and present an Authentication Switch Request for the dialog plugin.

Connections over properly verified TLS or a local Unix socket are not exposed to this vector.

Impact

Disclosure of the authenticating account's password in cleartext to an on-path or hostile server. The captured credentials can then be reused to authenticate to the database (and, if reused elsewhere, beyond it).

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch (3.5.x → 3.5.3, 3.4.x → 3.4.6, 3.3.x → 3.3.3, 3.2.x and earlier → 3.2.4). PAM (dialog) is now treated exactly like mysql_clear_password: it may only run over a secure transport. SendPamAuthPacketFactory overrides the secure-required flag to true, and the authentication dispatcher permits a secure-required plugin only when the connection is TLS or a local Unix socket. The pre-existing check that blocks non-MITM-proof plugins when server identity relies solely on self-signed-certificate fingerprint validation continues to apply. Net effect: PAM is allowed over TLS or a Unix socket, and rejected over plain TCP or fingerprint-only connections.

Workarounds

If you cannot upgrade immediately:

• Restrict the permitted authentication plugins via restrictedAuth so dialog cannot be negotiated over an insecure transport.
  Avoid PAM (dialog) authentication over plain TCP.

###Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

🚨 MariaDB's connector leaks the cleartext password to an MitM despite `ssl: true`

Summary

When SSL/TLS is enabled but no CA / server certificate is provided, the
connector verifies the server's identity using fingerprint validation. The
check is effective, the connection is ultimately rejected when it fails,
but it happens after the authentication exchange. As a result, the
credentials are sent before validation occurs, so an active man-in-the-middle
who presents their own certificate receives the password in the handshake
before the connection is aborted.

Impact

The credentials are transmitted to the peer before the server's identity is
validated. An on-path attacker (MitM) presenting any certificate can capture
the account password, even though the connection then fails the fingerprint
check and is closed. The disclosed credentials can subsequently be used to
authenticate directly against the server.

• Attacker requirement: active man-in-the-middle position on the network path
• Affected configuration: SSL/TLS enabled without a CA / server certificate

Affected versions

• < 3.2.4
• 3.3.0 – 3.3.2
• 3.4.0 – 3.4.5
• 3.5.0 – 3.5.2

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to one of these (or later)
on your branch.

Workarounds

Until you can upgrade, configure certificate verification explicitly, provide
the server/CA certificate and use a verifying SSL mode (e.g. VERIFY_CA /
VERIFY_FULL).

Reported by haaahaaahiihiiii (no GitHub account).

🚨 MariaDB has Cleartext Transmission of Sensitive Information and Insufficiently Protected Credentials

Summary

When PAM (dialog) authentication is used, the connector can be coerced into sending the account password in cleartext over an insecure connection. A hostile or man-in-the-middle server can trigger this with the default configuration, disclosing the user's password.

Details

The mysql_clear_password plugin is gated behind a secure connection: the driver refuses to transmit the password in cleartext over plain TCP. The sibling PAM plugin handler (SendPamAuthPacketFactory, server-side plugin name dialog) did not override that gate and inherited the default value false, so it was not subject to the same secure-transport requirement.

As a result, a hostile or man-in-the-middle server can issue an Authentication Switch Request for the dialog plugin over plain TCP, and the driver responds with the user's password in cleartext. With the default configuration (sslMode=DISABLE, restrictedAuth=null) this is reachable with no non-default options.

Am I affected?

You are affected if all of the following hold:

You use mariadb Connector/Node.js at a version below the patched release(s).
Connections can occur over an insecure transport: plain TCP (sslMode=DISABLE), or a TLS mode that establishes server identity only via self-signed-certificate fingerprint validation.
An attacker can occupy an on-path (MITM) position, or otherwise cause the client to connect to a server they control, and present an Authentication Switch Request for the dialog plugin.

Connections over properly verified TLS or a local Unix socket are not exposed to this vector.

Impact

Disclosure of the authenticating account's password in cleartext to an on-path or hostile server. The captured credentials can then be reused to authenticate to the database (and, if reused elsewhere, beyond it).

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch (3.5.x → 3.5.3, 3.4.x → 3.4.6, 3.3.x → 3.3.3, 3.2.x and earlier → 3.2.4). PAM (dialog) is now treated exactly like mysql_clear_password: it may only run over a secure transport. SendPamAuthPacketFactory overrides the secure-required flag to true, and the authentication dispatcher permits a secure-required plugin only when the connection is TLS or a local Unix socket. The pre-existing check that blocks non-MITM-proof plugins when server identity relies solely on self-signed-certificate fingerprint validation continues to apply. Net effect: PAM is allowed over TLS or a Unix socket, and rejected over plain TCP or fingerprint-only connections.

Workarounds

If you cannot upgrade immediately:

• Restrict the permitted authentication plugins via restrictedAuth so dialog cannot be negotiated over an insecure transport.
  Avoid PAM (dialog) authentication over plain TCP.

###Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

🚨 MariaDB's connector leaks the cleartext password to an MitM despite `ssl: true`

Summary

When SSL/TLS is enabled but no CA / server certificate is provided, the
connector verifies the server's identity using fingerprint validation. The
check is effective, the connection is ultimately rejected when it fails,
but it happens after the authentication exchange. As a result, the
credentials are sent before validation occurs, so an active man-in-the-middle
who presents their own certificate receives the password in the handshake
before the connection is aborted.

Impact

The credentials are transmitted to the peer before the server's identity is
validated. An on-path attacker (MitM) presenting any certificate can capture
the account password, even though the connection then fails the fingerprint
check and is closed. The disclosed credentials can subsequently be used to
authenticate directly against the server.

• Attacker requirement: active man-in-the-middle position on the network path
• Affected configuration: SSL/TLS enabled without a CA / server certificate

Affected versions

• < 3.2.4
• 3.3.0 – 3.3.2
• 3.4.0 – 3.4.5
• 3.5.0 – 3.5.2

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to one of these (or later)
on your branch.

Workarounds

Until you can upgrade, configure certificate verification explicitly, provide
the server/CA certificate and use a verifying SSL mode (e.g. VERIFY_CA /
VERIFY_FULL).

Reported by haaahaaahiihiiii (no GitHub account).

🚨 MariaDB has Cleartext Transmission of Sensitive Information and Insufficiently Protected Credentials

Summary

When PAM (dialog) authentication is used, the connector can be coerced into sending the account password in cleartext over an insecure connection. A hostile or man-in-the-middle server can trigger this with the default configuration, disclosing the user's password.

Details

The mysql_clear_password plugin is gated behind a secure connection: the driver refuses to transmit the password in cleartext over plain TCP. The sibling PAM plugin handler (SendPamAuthPacketFactory, server-side plugin name dialog) did not override that gate and inherited the default value false, so it was not subject to the same secure-transport requirement.

As a result, a hostile or man-in-the-middle server can issue an Authentication Switch Request for the dialog plugin over plain TCP, and the driver responds with the user's password in cleartext. With the default configuration (sslMode=DISABLE, restrictedAuth=null) this is reachable with no non-default options.

Am I affected?

You are affected if all of the following hold:

You use mariadb Connector/Node.js at a version below the patched release(s).
Connections can occur over an insecure transport: plain TCP (sslMode=DISABLE), or a TLS mode that establishes server identity only via self-signed-certificate fingerprint validation.
An attacker can occupy an on-path (MITM) position, or otherwise cause the client to connect to a server they control, and present an Authentication Switch Request for the dialog plugin.

Connections over properly verified TLS or a local Unix socket are not exposed to this vector.

Impact

Disclosure of the authenticating account's password in cleartext to an on-path or hostile server. The captured credentials can then be reused to authenticate to the database (and, if reused elsewhere, beyond it).

Patches

Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to the patched release on your branch (3.5.x → 3.5.3, 3.4.x → 3.4.6, 3.3.x → 3.3.3, 3.2.x and earlier → 3.2.4). PAM (dialog) is now treated exactly like mysql_clear_password: it may only run over a secure transport. SendPamAuthPacketFactory overrides the secure-required flag to true, and the authentication dispatcher permits a secure-required plugin only when the connection is TLS or a local Unix socket. The pre-existing check that blocks non-MITM-proof plugins when server identity relies solely on self-signed-certificate fingerprint validation continues to apply. Net effect: PAM is allowed over TLS or a Unix socket, and rejected over plain TCP or fingerprint-only connections.

Workarounds

If you cannot upgrade immediately:

• Restrict the permitted authentication plugins via restrictedAuth so dialog cannot be negotiated over an insecure transport.
  Avoid PAM (dialog) authentication over plain TCP.

###Credit

Reported by Yalguun Tumenkhuu (@fg0x0).

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.

↗️ @​types/geojson (indirect, 7946.0.8 → 7946.0.16) · Repo

Sorry, we couldn't find anything useful about this release.

↗️ @​types/node (indirect, 17.0.18 → 26.4.0) · Repo

Sorry, we couldn't find anything useful about this release.

↗️ iconv-lite (indirect, 0.6.3 → 0.7.3) · Repo · Changelog

Release Notes

0.7.3

🚀 Improvements

• Add iso-8859-8-i and iso-8859-8-e charset aliases - by @baptistejamin in #394

🐞 Bug fixes

• Fix UTF-32 streaming across chunk boundaries - by @spokodev and @bjohansebas in #393

  When decoding a UTF-32 stream, a 4-byte code unit split across a chunk boundary was decoded incorrectly, and a truncated trailing unit is now replaced with U+FFFD instead of being dropped. When encoding, a surrogate held over between chunks no longer throws. Whole-buffer decode/encode were unaffected.

New Contributors

• @baptistejamin made their first contribution in #394
• @spokodev made their first contribution in #393

Full Changelog: v0.7.2...v0.7.3

0.7.2

🐞 Bug fixes

• Correction of CommonJS exports in TypeScript definitions - by @plbstl in #366

  Fixed the TypeScript definitions to correctly represent the CommonJS exports of the library.
  This resolves issues where consumers using TypeScript would encounter errors due to incorrect
  type definitions that did not align with the actual module exports.

Other changes

• Bump actions/setup-node from 4 to 6 by @dependabot[bot] in #373
• Bump actions/checkout from 4 to 6 by @dependabot[bot] in #374
• chore: use files field in package.json instead of .npmignore by @bjohansebas in #372
• Bump github/codeql-action from 4.31.2 to 4.31.9 by @dependabot[bot] in #375
• Bump actions/upload-artifact from 4 to 6 by @dependabot[bot] in #377
• Bump actions/download-artifact from 6 to 7 by @dependabot[bot] in #376

Full Changelog: v0.7.1...v0.7.2

0.7.1

What's Changed

🚀 Improvements

• types: improve type definitions and add missing APIs - by @plbstl and @bjohansebas in #330

Other changes

• Bump actions/setup-node from 4 to 6 by @dependabot[bot] in #357
• Bump actions/download-artifact from 5 to 6 by @dependabot[bot] in #356
• Bump github/codeql-action from 3.29.8 to 4.31.2 by @dependabot[bot] in #355
• Bump actions/checkout from 4 to 5 by @dependabot[bot] in #351
• release: 0.7.1 by @bjohansebas in #359

New Contributors

• @plbstl made their first contribution in #330

Full Changelog: v0.7.0...v0.7.1

0.7.0

🐞 Bug fixes

• Handle split surrogate pairs when encoding utf8 - by @yosion-p and @ashtuchkin in #282:

  Handle a case where streaming utf8 encoder (converting js strings -> buffers) encounters
  surrogate pairs split between chunks (last character of one chunk is high surrogate and first
  character of the next chunk is a low surrogate).

• Avoid false positives in encodingExists by using objects without a prototype - by @bjohansebas in #328

  The encodingExists method could return incorrect results if the lookup matched properties inherited
  from the prototype of the object that stores the encodings, such as constructor and others. This change
  replaces that object with one that has no prototype, ensuring that only explicitly defined valid encodings
  in the library are considered. In addition, the fix is applied to the internal cache system to avoid the same
  kind of false positives

🚀 Improvements

• Make explicit that decode() method supports Uint8Array input - by @jardicc in #271
• Remove compatibility check for StringDecoder.end method - by @bjohansebas in #331

Other changes

• chore: update .npmignore to ignore unnecessary files by @vain0x in pillarjs/iconv-lite#292
• ci: use github actions instead travis by @bjohansebas in pillarjs/iconv-lite#324
• ci: add codeql by @bjohansebas in pillarjs/iconv-lite#325
• chore: update performance tests to use bench-node for benchmarking by @bjohansebas in pillarjs/iconv-lite#332
• feat: adopt neostandard as linter by @bjohansebas in pillarjs/iconv-lite#333
• chore: support node.js >=6, remove safe-buffer by @bjohansebas in pillarjs/iconv-lite#335
• Revert "chore: support node.js >=6, remove safe-buffer (#335)" by @bjohansebas in pillarjs/iconv-lite#336
• docs(package.json): update repo name and add funding field by @bjohansebas in pillarjs/iconv-lite#337
• chore: remove object-assign by @bjohansebas and @ljharb in pillarjs/iconv-lite#338
• release: 0.7.0 by @bjohansebas in pillarjs/iconv-lite#334
• ci: bump actions/download-artifact from 4 to 5 by @dependabot[bot] in pillarjs/iconv-lite#326
• ci: bump github/codeql-action from 3.29.2 to 3.29.8 by @dependabot[bot] in pillarjs/iconv-lite#327

New Contributors

• @yosion-p made their first contribution in pillarjs/iconv-lite#282
• @jardicc made their first contribution in pillarjs/iconv-lite#271
• @vain0x made their first contribution in pillarjs/iconv-lite#292
• @bjohansebas made their first contribution in pillarjs/iconv-lite#324
• @dependabot[bot] made their first contribution in pillarjs/iconv-lite#326

Full Changelog: pillarjs/iconv-lite@v0.6.3...v0.7.0

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

Commits

See the full diff on Github. The new version differs by 37 commits:

• release: 0.7.3 (#411)
• fix(utf32): reassemble split codepoint from overflow buffer, not source index (#393)
• feat: support iso-8859-8-i and iso-8859-8-e charset labels (#394)
• ci: fix workflow configuration for v0.x branch (#404)
• release: 0.7.2 (#379)
• fix: correction of CommonJS exports in TypeScript definitions (#366)
• Bump actions/download-artifact from 6 to 7 (#376)
• Bump actions/upload-artifact from 4 to 6 (#377)
• Bump github/codeql-action from 4.31.2 to 4.31.9 (#375)
• chore: use files field in package.json instead of .npmignore (#372)
• Bump actions/checkout from 4 to 6 (#374)
• Bump actions/setup-node from 4 to 6 (#373)
• release: 0.7.1 (#359)
• types: improve type definitions and add missing APIs (#330)
• Bump actions/checkout from 4 to 5 (#351)
• Bump github/codeql-action from 3.29.8 to 4.31.2 (#355)
• Bump actions/download-artifact from 5 to 6 (#356)
• Bump actions/setup-node from 4 to 6 (#357)
• release: 0.7.0 (#334)
• chore: remove object-assign (#338)
• docs(package.json): update repo name and add funding field (#337)
• Revert "chore: support node.js >=6, remove safe-buffer (#335)" (#336)
• chore: support node.js >=6, remove safe-buffer (#335)
• fix: add .git-blame-ignore-revs file for lint change
• feat: adopt linter (#333)
• chore: update performance tests to use bench-node for benchmarking (#332)
• docs: reorganize README
• fix: remove compatibility check for StringDecoder.end method (#331)
• fix: fix false positives in encodingExists (#328)
• Bump github/codeql-action from 3.29.2 to 3.29.8 (#327)
• Bump actions/download-artifact from 4 to 5 (#326)
• ci: add codeql (#325)
• ci: use github actions instead travis (#324)
• Update .npmignore (#292)
• Make explicit that decode() method supports Uint8Array input (#271)
• Handle split surrogate pairs when encoding utf8 (fixes #250)
• Update README.md to remove Cloud9

🆕 lru-cache (added, 11.5.2)

🆕 undici-types (added, 8.3.0)

🗑️ long (removed)

🗑️ moment (removed)

🗑️ moment-timezone (removed)

🗑️ please-upgrade-node (removed)

🗑️ semver-compare (removed)

---

👉 No CI detected

You don't seem to have any Continuous Integration service set up!

Without a service that will test the Depfu branches and pull requests, we can't inform you if incoming updates actually work with your app. We think that this degrades the service we're trying to provide down to a point where it is more or less meaningless.

This is fine if you just want to give Depfu a quick try. If you want to really let Depfu help you keep your app up-to-date, we recommend setting up a CI system:

* [Circle CI](https://circleci.com), [Semaphore ](https://semaphoreci.com) and [Github Actions](https://docs.github.com/actions) are all excellent options. * If you use something like Jenkins, make sure that you're using the Github integration correctly so that it reports status data back to Github. * If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with `depfu/`.

---

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)