Issue #19629 has been updated by ManuelKiessling (Manuel Kießling). Also see https://tickets.puppetlabs.com/browse/PUP-11848. ---------------------------------------- Bug #19629: Fix for CVE-2023-28755 breaks "puppet apply" run https://bugs.ruby-lang.org/issues/19629#change-102977 * Author: ManuelKiessling (Manuel Kießling) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- (Not neccessarily a bug in Ruby - chances are I should have formatted my Puppet file URIs differently from the get-go.) However, since yesterday I'm getting these errors when running `puppet apply`: Could not evaluate: Could not retrieve file metadata for puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades: Failed to open TCP connection to :8140 (Connection refused - connect(2) for "" port 8140) I think the reason this happens now in an otherwise completely unchanged environment is that on my Ubuntu system, a new ruby2.7 package has been installed, due to CVE-2023-28755. See http://changelogs.ubuntu.com/changelogs/pool/main/r/ruby2.7/ruby2.7_2.7.0-5u... for the backport info. The patch info (URI.parse should set empty string in host instead of nil in lib/uri/rfc3986_parser.rb, raise ArgumentError with empty host url again in lib/net/http/generic_request.rb.) sounds exactly like the reason I'm suddenly running into this error: `puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades` is an URI with an empty hostname - or is it? It's actually meant to refer to a local file, not a file on remote host ""; however, this is how it now seems to be interpreted: protocol `puppet`, hostname ``, path `/modules/unattended_upgrades...`. Because the patched code now returns `""` for the hostname instead of `nil`, it tries to do a hostname lookup for `""` which of course fails. Not sure if this is an intended consequence of the patch in this specific context, which is why I'm reporting it. -- https://bugs.ruby-lang.org/

Issue #19629 has been updated by ManuelKiessling (Manuel Kießling). You are right, and they have already fixed it through https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/2018547. ---------------------------------------- Bug #19629: Fix for CVE-2023-28755 breaks "puppet apply" run https://bugs.ruby-lang.org/issues/19629#change-102986 * Author: ManuelKiessling (Manuel Kießling) * Status: Third Party's Issue * Priority: Normal * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- (Not neccessarily a bug in Ruby - chances are I should have formatted my Puppet file URIs differently from the get-go.) However, since yesterday I'm getting these errors when running `puppet apply`: Could not evaluate: Could not retrieve file metadata for puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades: Failed to open TCP connection to :8140 (Connection refused - connect(2) for "" port 8140) I think the reason this happens now in an otherwise completely unchanged environment is that on my Ubuntu system, a new ruby2.7 package has been installed, due to CVE-2023-28755. See http://changelogs.ubuntu.com/changelogs/pool/main/r/ruby2.7/ruby2.7_2.7.0-5u... for the backport info. The patch info (URI.parse should set empty string in host instead of nil in lib/uri/rfc3986_parser.rb, raise ArgumentError with empty host url again in lib/net/http/generic_request.rb.) sounds exactly like the reason I'm suddenly running into this error: `puppet:///modules/unattended_upgrades/etc/apt/apt.conf.d/50unattended-upgrades` is an URI with an empty hostname - or is it? It's actually meant to refer to a local file, not a file on remote host ""; however, this is how it now seems to be interpreted: protocol `puppet`, hostname ``, path `/modules/unattended_upgrades...`. Because the patched code now returns `""` for the hostname instead of `nil`, it tries to do a hostname lookup for `""` which of course fails. Not sure if this is an intended consequence of the patch in this specific context, which is why I'm reporting it. -- https://bugs.ruby-lang.org/