Hide Forgot
Created attachment 1255721 [details] Fix dereferences, so .netrc is read. Description of problem: 'wget' does not actually honor ~/.netrc as advertised, due to a minor coding error. Also, it does not support '--netrc' or '--no-netrc' options (which may be intentional, but it seems that it should). Version-Release number of selected component: wget-1.19-1.fc26.src.rpm How reproducible: 100% Steps to Reproduce: 1. Run wget to get your favorite password-protected download, with the site's username and passowrd included in ~/.netrc . 2. ls -ltu ~/.netrc Actual results: The download will fail due with "401 Unauthorized", and ~/.netrc will not have been accessed. Expected results: Successful download, and atime of ~/.netrc updated. Additional info: Patches included as attachments -- one to fix reading .netrc, the other to add the '--netrc/--no-netrc' option. (Both are one-liners.)
Created attachment 1255722 [details] Add --netrc/--no-netrc option.
Note that 'user' and 'password' are used slightly differenty in http.c vs. ftp.c, hence the difference in dereferencing when determining whether they are set.
Do you see the same issue with 1.19.1?
Give me a few minutes to get a spec file hacked up to build the source tarball from ftp://ftp.gnu.org/gnu/wget/ (I don't see 1.19.1 in the F26 repo yet). But in any case, 1.19.1 still seems wrong -- in http.c, the 20 lines or so preceding the conditional call to search_netrc assumes that 'user' and 'passwd' are both non-NULL, because no matter what the outcome of the two if/else chains, they're both dereferenced by *user and *passwd . So !user and !passwd are always false (if either was true, i.e., if either pointer was NULL, there would have been a segfault in the previous lines, no?). So the user/passwd test boils down to just !*passwd, if Mr. Boole has anything to say about it. (There may have been some confusion because similar code in ftp.c does allow them to be NULL .) From src/http.c: 1878 /* Find the username with priority */ 1879 if (u->user) 1880 *user = u->user; 1881 else if (opt.user && (opt.use_askpass || opt.ask_passwd)) 1882 *user = opt.user; 1883 else if (opt.http_user) 1884 *user = opt.http_user; 1885 else if (opt.user) 1886 *user = opt.user; 1887 else 1888 *user = NULL; 1889 1890 /* Find the password with priority */ 1891 if (u->passwd) 1892 *passwd = u->passwd; 1893 else if (opt.passwd && (opt.use_askpass || opt.ask_passwd)) 1894 *passwd = opt.passwd; 1895 else if (opt.http_passwd) 1896 *passwd = opt.http_passwd; 1897 else if (opt.passwd) 1898 *passwd = opt.passwd; 1899 else 1900 *passwd = NULL; 1901 1902 /* Check for ~/.netrc if none of the above match */ 1903 if (opt.netrc && (!user || (!passwd || !*passwd))) 1904 search_netrc (u->host, (const char **) user, (const char **) passwd, 0);
OK, here's the results: The 1.19.1 code works in the usual case where it has to get both user and passwd from .netrc . But unlike my patch, it does not work in the case where only "login" (user) is in .netrc, and only the password is given on the command-line (via the '--password' option; one can't give just a password with the '"http://username:password@site/" syntax ("Invalid user name")). (Tested empirically; I trust Mr. Boole but not myself after 18 hours uptime.) And there really ought to be a '--no-netrc' option (my main.c patch).
I'm attaching a patch that adds traces and an early exit to http.c, to make testing easy. (BTW, this isn't an "issue", it's a "problem" or a "bug". "Issue" is a euphemism dreamed up by Redmond marketeers.)
Created attachment 1255894 [details] Patch to 1.19.1 to add user/passwd and search_netrc traces, for testing. This should tell everything one needs to know, without the need for an http server.
For the record, the 1.19.1 is available since 17-Feb. https://koji.fedoraproject.org/koji/buildinfo?buildID=859637 https://src.fedoraproject.org/cgit/rpms/wget.git/commit/?id=ea14f5739fbda9d257f9ffca11e028d18be66f26 Did you propose your fix to the upstream? If not, I can review your changes and report it to the upstream.
(In reply to Tomas Hozza from comment #8) > ... > Did you propose your fix to the upstream? If not, I can review your changes > and report it to the upstream. No, I haven't -- please do. Thank you.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I just sent changes to the upstream. Will wait for their response.
Merged upstream: http://git.savannah.gnu.org/cgit/wget.git/commit/?id=17960b57d51ffb19b2b20df3e53da42c555f022c http://git.savannah.gnu.org/cgit/wget.git/commit/?id=f8c3df1f40f09dd61078436614d06e7ad818536e http://git.savannah.gnu.org/cgit/wget.git/commit/?id=876def8ebe56d483921cf645371d277b615373e5
wget-1.19.1-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-38c3781b89
fixed in: wget-1.19.1-3.fc26 wget-1.19.1-3.fc27
wget-1.19.1-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-38c3781b89
wget-1.19.1-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.