F40 Change Proposal: wget2 as Wget

:link: Wget2 as wget

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Replace wget with wget2 (a modern implementation of wget intended to replace wget 1.x) as the provider of wget.

:link: Owner

:link: Detailed Description

GNU Wget2 is the successor to GNU Wget providing a modern implementation of wget backed by a new library: libwget2. The intent to switch from wget 1.x to wget2 is to switch to an implementation that is more actively developed and provides a richer interface for leveraging wget’s functionality.

:link: Feedback

:link: Benefit to Fedora

The major benefit of switching to wget2 is leveraging the cleaner codebase that leverages modern practices for development and maintainability, including unit tests and fuzzing as a security-sensitive component. Users will also see better support for newer protocols over time as they are more easily and quickly plumbed into wget2 than wget.

:link: Scope

  • Proposal owners: Add a wget2-wget subpackage that replaces wget and ensure things don’t break during mass build. Then retire wget.

  • Other developers: N/A

  • Release engineering: #11790

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives: N/A (not needed for this Change)

:link: Upgrade/compatibility impact

When upgrading to Fedora Linux 40, systems with wget installed will be switched to wget2 via the wget2-wget package. The change should be mostly transparent to users.

:link: How To Test

Users can test wget2 now by installing the package and using the wget2 command. The interface will be the interface users have with wget on upgrade.

:link: User Experience

This change should be largely transparent to users. Some of the more esoteric options and behaviors may have changed, but the commonly used ones mostly work as they did in 1.x.

:link: Dependencies

N/A (not a System Wide Change)

:link: Contingency Plan

  • Contingency mechanism: Change owners will disable wget2-wget subpackage and restore wget
  • Contingency deadline: Final Freeze
  • Blocks release? No

:link: Documentation

The main documentation for wget2 is wget2(1) man page. There is also online documentation of the libwget2 library.

N/A (not a System Wide Change)

:link: Release Notes

The wget command is now based on GNU Wget2, a modern implementation of GNU Wget.

This change proposal has now been submitted to FESCo with ticket #3118 for voting.

To find out more, please visit our Changes Policy documentation.

Is this an official successor? It seems like the main maintainers are the same… why is it a separate package?

I am a little bit concerned about security implications, as wget and curl have tended to be… hot-spots. Unless my search is simply confounded by the name format, I don’t see any CVEs ever recorded against wget2. Since the first public release was in 2014, and an “alpha” release (for 2.0, presumably?) in 2018, it seems like … something would have been found?

Some of the more esoteric options and behaviors may have changed, but the commonly used ones mostly work as they did in 1.x.

Can you elaborate on this? “May have changed” seems a bit concerning.

This was updated in the Change document, but for your benefit:

Except for WARC and FTP, Wget2 is a drop-in replacement for Wget in most cases. See upstream info: Different behavior of Wget2 and Differing CLI options Wget/Wget2, and TODO.

I have faced trouble filtering files to be downloaded using wget2 where wget did not face issues. Same command on both. It would be quality of life regression.

Specifically

wget -m -np -c -e robots=off -A "*USA*" https://myrient.erista.me/files/No-Intro/Atari%20-%202600/

Failed to work in wget2

Could you please file an issue on the upstream issue tracker?

1 Like

this change is discouraged by upstream maintainers, see Fedora 40 ships Wget2 as Wget (#661) · Issues · Wget / wget2 · GitLab

it is just not ready. Upstream was NOT asked for its opinion on this matter. If we had been asked about this, we’d have stated our concerns and said that it’s a bad idea.

security implications are a real concern (see list of tickets upstream).

Can this change be reverted?

2 Likes

A post was split to a new topic: Wget2 change breaks compatibility and should be reverted