Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump the bundler group across 2 directories with 4 updates #3

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Mar 19, 2024

Bumps the bundler group with 2 updates in the /rails3-deps directory: omniauth and sanitize.
Bumps the bundler group with 3 updates in the /rails4-deps directory: omniauth, rack and sanitize.

Updates omniauth from 1.3.1 to 1.4.2

Release notes

Sourced from omniauth's releases.

v1.4.2

Fixes

  • Mitigate Hashie regressions

v1.4.1

Security Updates

  • Update Rack to => 1.6.2

v1.4.0

Dropped

  • Dropped support Ruby 1.8.7

Fixed

  • Silence Hashie::Mash logger on Hashie 3.5.0+
  • Use secure URL for OpenID asset
Commits
  • 9897127 Bump version to 1.4.2
  • 6abedb0 Merge pull request #880 from omniauth/hashie
  • df7699d Temporary Hashie Regression Fix
  • 2dccbb5 Bump version to 1.4.1
  • 3c0f586 Merge pull request #878 from omniauth/dependency-updates
  • c299e30 Gem updates CI tests
  • 949ffca Bump version to 1.4.0
  • 0edc7ec Merge pull request #874 from michaelherold/silence-mash-logger
  • 00481a9 Silence Hashie::Mash logger on Hashie 3.5.0+
  • cb82bb4 Merge pull request #876 from omniauth/secure-asset-url
  • Additional commits viewable in compare view

Updates sanitize from 4.0.1 to 6.0.2

Release notes

Sourced from sanitize's releases.

v6.0.2

Bug Fixes

  • CVE-2023-36823: Fixed an HTML+CSS sanitization bypass that could allow XSS (cross-site scripting). This issue affects Sanitize versions 3.0.0 through 6.0.1.

    When using Sanitize's relaxed config or a custom config that allows <style> elements and one or more CSS at-rules, carefully crafted input could be used to sneak arbitrary HTML through Sanitize.

    See the following security advisory for additional details: GHSA-f5ww-cq3m-q3g7

    Thanks to @​cure53 for finding this issue.

v6.0.1

Bug Fixes

  • Sanitize now always removes <noscript> elements and their contents, even when noscript is in the allowlist.

    This fixes a sanitization bypass that could occur when noscript was allowed by a custom allowlist. In this scenario, carefully crafted input could sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

    Sanitize's default configs don't allow <noscript> elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist.

    The root cause of this issue is that HTML parsing rules treat the contents of a <noscript> element differently depending on whether scripting is enabled in the user agent. Nokogiri doesn't support scripting so it follows the "scripting disabled" rules, but a web browser with scripting enabled will follow the "scripting enabled" rules. This means that Sanitize can't reliably make the contents of a <noscript> element safe for scripting enabled browsers, so the safest thing to do is to remove the element and its contents entirely.

    See the following security advisory for additional details: GHSA-fw3g-2h3j-qmm7

    Thanks to David Klein from TU Braunschweig (@​leeN) for reporting this issue.

  • Fixed an edge case in which the contents of an "unescaped text" element (such as <noembed> or <xmp>) were not properly escaped if that element was allowlisted and was also inside an allowlisted <math> or <svg> element.

    The only way to encounter this situation was to ignore multiple warnings in the readme and create a custom config that allowlisted all the elements involved, including <math> or <svg>. If you're using a default config or if you heeded the warnings about MathML and SVG not being supported, you're not affected by this issue.

    Please let this be a reminder that Sanitize cannot safely sanitize MathML or SVG content and does not support this use case. The default configs don't allow MathML or SVG elements, and allowlisting MathML or SVG elements in a custom config may create a security vulnerability in your application.

    Documentation has been updated to add more warnings and to make the existing warnings about this more prominent.

    Thanks to David Klein from TU Braunschweig (@​leeN) for reporting this issue.

v6.0.0

Potentially Breaking Changes

  • Ruby 2.5.0 is now the oldest officially supported Ruby version.

  • Sanitize now requires Nokogiri 1.12.0 or higher, which includes Nokogumbo. The separate dependency on Nokogumbo has been removed. [@​lis2 - #211]211

v5.2.3

Bug Fixes

  • Ensure protocol sanitization is applied to data attributes. [@​ccutrer - #207][207]

... (truncated)

Changelog

Sourced from sanitize's changelog.

6.0.2 (2023-07-06)

Bug Fixes

  • CVE-2023-36823: Fixed an HTML+CSS sanitization bypass that could allow XSS (cross-site scripting). This issue affects Sanitize versions 3.0.0 through 6.0.1.

    When using Sanitize's relaxed config or a custom config that allows <style> elements and one or more CSS at-rules, carefully crafted input could be used to sneak arbitrary HTML through Sanitize.

    See the following security advisory for additional details: GHSA-f5ww-cq3m-q3g7

    Thanks to @​cure53 for finding this issue.

6.0.1 (2023-01-27)

Bug Fixes

  • Sanitize now always removes <noscript> elements and their contents, even when noscript is in the allowlist.

    This fixes a sanitization bypass that could occur when noscript was allowed by a custom allowlist. In this scenario, carefully crafted input could sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

    Sanitize's default configs don't allow <noscript> elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist.

    The root cause of this issue is that HTML parsing rules treat the contents of a <noscript> element differently depending on whether scripting is enabled in the user agent. Nokogiri doesn't support scripting so it follows the "scripting disabled" rules, but a web browser with scripting enabled will follow the "scripting enabled" rules. This means that Sanitize can't reliably make the contents of a <noscript> element safe for scripting enabled browsers, so the safest thing to do is to remove the element and its contents entirely.

    See the following security advisory for additional details: GHSA-fw3g-2h3j-qmm7

    Thanks to David Klein from TU Braunschweig (@​leeN) for reporting this issue.

  • Fixed an edge case in which the contents of an "unescaped text" element (such as <noembed> or <xmp>) were not properly escaped if that element was

... (truncated)

Commits

Updates nokogiri from 1.6.7.2 to 1.16.3

Release notes

Sourced from nokogiri's releases.

v1.16.3 / 2024-03-15

Dependencies

Changed

  • [CRuby] XML::Reader sets the @encoding instance variable during reading if it is not passed into the initializer. Previously, it would remain nil. The behavior of Reader#encoding has not changed. This works around changes to how libxml2 reports the encoding used in v2.12.6.

sha256 checksums:

3d806263a0548e5163ff256655d78a87998fa83a5ae256b83c14a1a97731e824  nokogiri-1.16.3-aarch64-linux.gem
cfb923c02bde065005e2521f0a6883c63cf305cb899a9dd4c74897731bb2af1d  nokogiri-1.16.3-arm-linux.gem
5d3268558c002fa493e33076798cfda1df8effbd5363060dc41595cfebb1cf90  nokogiri-1.16.3-arm64-darwin.gem
6bf0918233959c7d5e703061ada0f436544612397475a866aa314071f02bfabb  nokogiri-1.16.3-java.gem
656f163dd287671c3a28157a2e853ee1a36afeb3f4185a78af863f3980efc58d  nokogiri-1.16.3-x64-mingw-ucrt.gem
7330f65cf2f8fa442327112b6515b4988f396d23010d33571714fd2ac0648fb9  nokogiri-1.16.3-x64-mingw32.gem
08d8a369940fa2309379cd8af1e7b3cc702b0115d3ddd197cfa7b33daedfd541  nokogiri-1.16.3-x86-linux.gem
cd26e99fa6388cd73c8892bb99ac98af162fe83c8f71c6473dfeba7aac76bcb9  nokogiri-1.16.3-x86-mingw32.gem
bc22786f4db4c32a5587e3b77a106408148d3bb1602dd0b52c0f5c968c42d17d  nokogiri-1.16.3-x86_64-darwin.gem
47a3330e41b49a100225b6fab490b2dc43410931e01e791886e0c2998412e8cb  nokogiri-1.16.3-x86_64-linux.gem
498aa253ccd5b89a0fa5c4c82b346d22176fc865f4a12ef8da642064d1d3e248  nokogiri-1.16.3.gem

v1.16.2 / 2024-02-04

Security

Dependencies


sha256 checksums:

69ba15d2a2498324489ed63850997f0b8f684260114ea81116d3082f16551d2d  nokogiri-1.16.2-aarch64-linux.gem
6a05ce42e3587a40cf8936ece0beaa5d32922254215d2e8cf9ad40588bb42e57  nokogiri-1.16.2-arm-linux.gem
c957226c8e36b31be6a3afb8602e2128282bf8b40ea51016c4cd21aa2608d3f8  nokogiri-1.16.2-arm64-darwin.gem
122652bfc338cd8a54a692ac035e245e41fd3b8283299202ca26e7a7d50db310  nokogiri-1.16.2-java.gem
</tr></table> 

... (truncated)

Changelog

Sourced from nokogiri's changelog.

v1.16.3 / 2024-03-15

Dependencies

Changed

  • [CRuby] XML::Reader sets the @encoding instance variable during reading if it is not passed into the initializer. Previously, it would remain nil. The behavior of Reader#encoding has not changed. This works around changes to how libxml2 reports the encoding used in v2.12.6.

v1.16.2 / 2024-02-04

Security

Dependencies

v1.16.1 / 2024-02-03

Dependencies

Fixed

  • [CRuby] XML::Reader defaults the encoding to UTF-8 if it's not specified in either the document or as a method parameter. Previously non-ASCII characters were serialized as NCRs in this case. #2891 (@​flavorjones)
  • [CRuby] Restored support for compilation by GCC versions earlier than 4.6, which was broken in v1.15.0 (540e9aee). #3090 (@​adfoster-r7)
  • [CRuby] Patched upstream libxml2 to allow parsing HTML5 in the context of a namespaced node (e.g., foreign content like MathML). [#3112, #3116] (@​flavorjones)
  • [CRuby] Fixed a small memory leak in libgumbo (HTML5 parser) when the maximum tree depth limit is hit. [#3098, #3100] (@​stevecheckoway)

v1.16.0 / 2023-12-27

Notable Changes

Ruby

This release introduces native gem support for Ruby 3.3.

This release ends support for Ruby 2.7, for which upstream support ended 2023-03-31.

... (truncated)

Commits

Updates omniauth from 1.3.1 to 1.4.3

Release notes

Sourced from omniauth's releases.

v1.4.2

Fixes

  • Mitigate Hashie regressions

v1.4.1

Security Updates

  • Update Rack to => 1.6.2

v1.4.0

Dropped

  • Dropped support Ruby 1.8.7

Fixed

  • Silence Hashie::Mash logger on Hashie 3.5.0+
  • Use secure URL for OpenID asset
Commits
  • 9897127 Bump version to 1.4.2
  • 6abedb0 Merge pull request #880 from omniauth/hashie
  • df7699d Temporary Hashie Regression Fix
  • 2dccbb5 Bump version to 1.4.1
  • 3c0f586 Merge pull request #878 from omniauth/dependency-updates
  • c299e30 Gem updates CI tests
  • 949ffca Bump version to 1.4.0
  • 0edc7ec Merge pull request #874 from michaelherold/silence-mash-logger
  • 00481a9 Silence Hashie::Mash logger on Hashie 3.5.0+
  • cb82bb4 Merge pull request #876 from omniauth/secure-asset-url
  • Additional commits viewable in compare view

Updates rack from 1.6.4 to 1.6.13

Commits
  • 47a1fd7 bump version
  • b8dc520 Handle case where session id key is requested but it is missing
  • 698a060 Merge pull request #1462 from jeremyevans/sessionid-to_s
  • de902e4 Merge branch '1-6-sec' into 1-6-stable
  • b7d6546 Bump version
  • d3e2f88 making diff smaller
  • 99a8a87 fix memcache tests on 1.6
  • f2cb48e fix tests on 1.6
  • 7ff635c Introduce a new base class to avoid breaking when upgrading
  • 3232f93 Add a version prefix to the private id to make easier to migrate old values
  • Additional commits viewable in compare view

Updates sanitize from 4.0.1 to 6.0.2

Release notes

Sourced from sanitize's releases.

v6.0.2

Bug Fixes

  • CVE-2023-36823: Fixed an HTML+CSS sanitization bypass that could allow XSS (cross-site scripting). This issue affects Sanitize versions 3.0.0 through 6.0.1.

    When using Sanitize's relaxed config or a custom config that allows <style> elements and one or more CSS at-rules, carefully crafted input could be used to sneak arbitrary HTML through Sanitize.

    See the following security advisory for additional details: GHSA-f5ww-cq3m-q3g7

    Thanks to @​cure53 for finding this issue.

v6.0.1

Bug Fixes

  • Sanitize now always removes <noscript> elements and their contents, even when noscript is in the allowlist.

    This fixes a sanitization bypass that could occur when noscript was allowed by a custom allowlist. In this scenario, carefully crafted input could sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

    Sanitize's default configs don't allow <noscript> elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist.

    The root cause of this issue is that HTML parsing rules treat the contents of a <noscript> element differently depending on whether scripting is enabled in the user agent. Nokogiri doesn't support scripting so it follows the "scripting disabled" rules, but a web browser with scripting enabled will follow the "scripting enabled" rules. This means that Sanitize can't reliably make the contents of a <noscript> element safe for scripting enabled browsers, so the safest thing to do is to remove the element and its contents entirely.

    See the following security advisory for additional details: GHSA-fw3g-2h3j-qmm7

    Thanks to David Klein from TU Braunschweig (@​leeN) for reporting this issue.

  • Fixed an edge case in which the contents of an "unescaped text" element (such as <noembed> or <xmp>) were not properly escaped if that element was allowlisted and was also inside an allowlisted <math> or <svg> element.

    The only way to encounter this situation was to ignore multiple warnings in the readme and create a custom config that allowlisted all the elements involved, including <math> or <svg>. If you're using a default config or if you heeded the warnings about MathML and SVG not being supported, you're not affected by this issue.

    Please let this be a reminder that Sanitize cannot safely sanitize MathML or SVG content and does not support this use case. The default configs don't allow MathML or SVG elements, and allowlisting MathML or SVG elements in a custom config may create a security vulnerability in your application.

    Documentation has been updated to add more warnings and to make the existing warnings about this more prominent.

    Thanks to David Klein from TU Braunschweig (@​leeN) for reporting this issue.

v6.0.0

Potentially Breaking Changes

  • Ruby 2.5.0 is now the oldest officially supported Ruby version.

  • Sanitize now requires Nokogiri 1.12.0 or higher, which includes Nokogumbo. The separate dependency on Nokogumbo has been removed. [@​lis2 - #211]211

v5.2.3

Bug Fixes

  • Ensure protocol sanitization is applied to data attributes. [@​ccutrer - #207][207]

... (truncated)

Changelog

Sourced from sanitize's changelog.

6.0.2 (2023-07-06)

Bug Fixes

  • CVE-2023-36823: Fixed an HTML+CSS sanitization bypass that could allow XSS (cross-site scripting). This issue affects Sanitize versions 3.0.0 through 6.0.1.

    When using Sanitize's relaxed config or a custom config that allows <style> elements and one or more CSS at-rules, carefully crafted input could be used to sneak arbitrary HTML through Sanitize.

    See the following security advisory for additional details: GHSA-f5ww-cq3m-q3g7

    Thanks to @​cure53 for finding this issue.

6.0.1 (2023-01-27)

Bug Fixes

  • Sanitize now always removes <noscript> elements and their contents, even when noscript is in the allowlist.

    This fixes a sanitization bypass that could occur when noscript was allowed by a custom allowlist. In this scenario, carefully crafted input could sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

    Sanitize's default configs don't allow <noscript> elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist.

    The root cause of this issue is that HTML parsing rules treat the contents of a <noscript> element differently depending on whether scripting is enabled in the user agent. Nokogiri doesn't support scripting so it follows the "scripting disabled" rules, but a web browser with scripting enabled will follow the "scripting enabled" rules. This means that Sanitize can't reliably make the contents of a <noscript> element safe for scripting enabled browsers, so the safest thing to do is to remove the element and its contents entirely.

    See the following security advisory for additional details: GHSA-fw3g-2h3j-qmm7

    Thanks to David Klein from TU Braunschweig (@​leeN) for reporting this issue.

  • Fixed an edge case in which the contents of an "unescaped text" element (such as <noembed> or <xmp>) were not properly escaped if that element was

... (truncated)

Commits

Updates nokogiri from 1.6.7.2 to 1.16.3

Release notes

Sourced from nokogiri's releases.

v1.16.3 / 2024-03-15

Dependencies

Changed

  • [CRuby] XML::Reader sets the @encoding instance variable during reading if it is not passed into the initializer. Previously, it would remain nil. The behavior of Reader#encoding has not changed. This works around changes to how libxml2 reports the encoding used in v2.12.6.

sha256 checksums:

3d806263a0548e5163ff256655d78a87998fa83a5ae256b83c14a1a97731e824  nokogiri-1.16.3-aarch64-linux.gem
cfb923c02bde065005e2521f0a6883c63cf305cb899a9dd4c74897731bb2af1d  nokogiri-1.16.3-arm-linux.gem
5d3268558c002fa493e33076798cfda1df8effbd5363060dc41595cfebb1cf90  nokogiri-1.16.3-arm64-darwin.gem
6bf0918233959c7d5e703061ada0f436544612397475a866aa314071f02bfabb  nokogiri-1.16.3-java.gem
656f163dd287671c3a28157a2e853ee1a36afeb3f4185a78af863f3980efc58d  nokogiri-1.16.3-x64-mingw-ucrt.gem
7330f65cf2f8fa442327112b6515b4988f396d23010d33571714fd2ac0648fb9  nokogiri-1.16.3-x64-mingw32.gem
08d8a369940fa2309379cd8af1e7b3cc702b0115d3ddd197cfa7b33daedfd541  nokogiri-1.16.3-x86-linux.gem
cd26e99fa6388cd73c8892bb99ac98af162fe83c8f71c6473dfeba7aac76bcb9  nokogiri-1.16.3-x86-mingw32.gem
bc22786f4db4c32a5587e3b77a106408148d3bb1602dd0b52c0f5c968c42d17d  nokogiri-1.16.3-x86_64-darwin.gem
47a3330e41b49a100225b6fab490b2dc43410931e01e791886e0c2998412e8cb  nokogiri-1.16.3-x86_64-linux.gem
498aa253ccd5b89a0fa5c4c82b346d22176fc865f4a12ef8da642064d1d3e248  nokogiri-1.16.3.gem

v1.16.2 / 2024-02-04

Security

Dependencies


sha256 checksums:

69ba15d2a2498324489ed63850997f0b8f684260114ea81116d3082f16551d2d  nokogiri-1.16.2-aarch64-linux.gem
6a05ce42e3587a40cf8936ece0beaa5d32922254215d2e8cf9ad40588bb42e57  nokogiri-1.16.2-arm-linux.gem
c957226c8e36b31be6a3afb8602e2128282bf8b40ea51016c4cd21aa2608d3f8  nokogiri-1.16.2-arm64-darwin.gem
122652bfc338cd8a54a692ac035e245e41fd3b8283299202ca26e7a7d50db310  nokogiri-1.16.2-java.gem
</tr></table> 

... (truncated)

Changelog

Sourced from nokogiri's changelog.

v1.16.3 / 2024-03-15

Dependencies

Changed

  • [CRuby] XML::Reader sets the @encoding instance variable during reading if it is not passed into the initializer. Previously, it would remain nil. The behavior of Reader#encoding has not changed. This works around changes to how libxml2 reports the encoding used in v2.12.6.

v1.16.2 / 2024-02-04

Security

Dependencies

v1.16.1 / 2024-02-03

Dependencies

Fixed

  • [CRuby] XML::Reader defaults the encoding to UTF-8 if it's not specified in either the document or as a method parameter. Previously non-ASCII characters were serialized as NCRs in this case. #2891 (@​flavorjones)
  • [CRuby] Restored support for compilation by GCC versions earlier than 4.6, which was broken in v1.15.0 (540e9aee). #3090 (@​adfoster-r7)
  • [CRuby] Patched upstream libxml2 to allow parsing HTML5 in the context of a namespaced node (e.g., foreign content like MathML). [#3112, #3116] (@​flavorjones)
  • [CRuby] Fixed a small memory leak in libgumbo (HTML5 parser) when the maximum tree depth limit is hit. [#3098, #3100] (@​stevecheckoway)

v1.16.0 / 2023-12-27

Notable Changes

Ruby

This release introduces native gem support for Ruby 3.3.

This release ends support for Ruby 2.7, for which upstream support ended 2023-03-31.

... (truncated)

Commits

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Bumps the bundler group with 2 updates in the /rails3-deps directory: [omniauth](https://github.com/omniauth/omniauth) and [sanitize](https://github.com/rgrove/sanitize).
Bumps the bundler group with 3 updates in the /rails4-deps directory: [omniauth](https://github.com/omniauth/omniauth), [rack](https://github.com/rack/rack) and [sanitize](https://github.com/rgrove/sanitize).


Updates `omniauth` from 1.3.1 to 1.4.2
- [Release notes](https://github.com/omniauth/omniauth/releases)
- [Commits](omniauth/omniauth@v1.3.1...v1.4.2)

Updates `sanitize` from 4.0.1 to 6.0.2
- [Release notes](https://github.com/rgrove/sanitize/releases)
- [Changelog](https://github.com/rgrove/sanitize/blob/main/HISTORY.md)
- [Commits](rgrove/sanitize@v4.0.1...v6.0.2)

Updates `nokogiri` from 1.6.7.2 to 1.16.3
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](sparklemotion/nokogiri@v1.6.7.2...v1.16.3)

Updates `omniauth` from 1.3.1 to 1.4.3
- [Release notes](https://github.com/omniauth/omniauth/releases)
- [Commits](omniauth/omniauth@v1.3.1...v1.4.2)

Updates `rack` from 1.6.4 to 1.6.13
- [Release notes](https://github.com/rack/rack/releases)
- [Changelog](https://github.com/rack/rack/blob/main/CHANGELOG.md)
- [Commits](rack/rack@1.6.4...1.6.13)

Updates `sanitize` from 4.0.1 to 6.0.2
- [Release notes](https://github.com/rgrove/sanitize/releases)
- [Changelog](https://github.com/rgrove/sanitize/blob/main/HISTORY.md)
- [Commits](rgrove/sanitize@v4.0.1...v6.0.2)

Updates `nokogiri` from 1.6.7.2 to 1.16.3
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](sparklemotion/nokogiri@v1.6.7.2...v1.16.3)

---
updated-dependencies:
- dependency-name: omniauth
  dependency-type: direct:production
  dependency-group: bundler-security-group
- dependency-name: sanitize
  dependency-type: direct:production
  dependency-group: bundler-security-group
- dependency-name: nokogiri
  dependency-type: indirect
  dependency-group: bundler-security-group
- dependency-name: omniauth
  dependency-type: direct:production
  dependency-group: bundler-security-group
- dependency-name: rack
  dependency-type: direct:production
  dependency-group: bundler-security-group
- dependency-name: sanitize
  dependency-type: direct:production
  dependency-group: bundler-security-group
- dependency-name: nokogiri
  dependency-type: indirect
  dependency-group: bundler-security-group
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot added the dependencies Pull requests that update a dependency file label Mar 19, 2024
Copy link
Author

dependabot bot commented on behalf of github May 14, 2024

Superseded by #4.

@dependabot dependabot bot closed this May 14, 2024
@dependabot dependabot bot deleted the dependabot/bundler/rails3-deps/bundler-security-group-2dd6328480 branch May 14, 2024 01:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants