Re: fetch -v error output broken?

2021-09-09 Thread Baptiste Daroussin
On Thu, Sep 09, 2021 at 04:00:39PM +0200, Stefan Esser wrote:
> I have just opened PR 258387 for this issue, which occurred during testing
> of a port with invalid MASTER_SITE.
> 
> The error output of "fetch -v" should be server messages, but it appears that
> the buffer gets overwritten with data of unknown origin (mostly NUL bytes), 
> e.g.:
> 
I figured the same this morning and fixed it in: 635eb7ac799

Best regards,
Bapt



fetch -v error output broken?

2021-09-09 Thread Stefan Esser
I have just opened PR 258387 for this issue, which occurred during testing
of a port with invalid MASTER_SITE.

The error output of "fetch -v" should be server messages, but it appears that
the buffer gets overwritten with data of unknown origin (mostly NUL bytes), 
e.g.:

$ fetch -v http://distcache.us-west.freebsd.org/x 2>&1 | hd
  72 65 73 6f 6c 76 69 6e  67 20 73 65 72 76 65 72  |resolving server|
0010  20 61 64 64 72 65 73 73  3a 20 64 69 73 74 63 61  | address: distca|
0020  63 68 65 2e 75 73 2d 77  65 73 74 2e 66 72 65 65  |che.us-west.free|
0030  62 73 64 2e 6f 72 67 3a  38 30 0a 72 65 71 75 65  |bsd.org:80.reque|
0040  73 74 69 6e 67 20 68 74  74 70 3a 2f 2f 64 69 73  |sting http://dis|
0050  74 63 61 63 68 65 2e 75  73 2d 77 65 73 74 2e 66  |tcache.us-west.f|
0060  72 65 65 62 73 64 2e 6f  72 67 2f 78 0a 0d 0a 00  |reebsd.org/x|
0070  67 69 6e 78 00 00 00 0a  34 30 34 20 4e 6f 74 20  |ginx404 Not |
0080  46 6f 75 6e 64 0d 0a 00  00 00 00 00 10 02 00 50  |Found..P|
0090  95 14 01 c9 00 00 00 00  00 00 00 00 0a 0d 0a 00  ||
00a0  74 6c 65 3e 34 30 34 20  4e 6f 74 20 46 6f 75 6e  |tle>404 Not Foun|
00b0  64 0d 0a 00 00 00 00 00  10 02 00 50 95 14 01 c9  |d..P|
00c0  00 00 00 00 00 00 00 00  0a 34 30 34 20 4e 6f 74  |.404 Not|
00d0  20 46 6f 75 6e 64 0d 0a  00 0a 00 00 00 00 00 10  | Found..|
00e0  02 00 50 95 14 01 c9 00  00 00 00 00 00 00 00 0a  |..P.|
00f0  6e 67 69 6e 78 0d 0a 00  3e 0d 0a 00 0a 00 00 00  |nginx...>...|
0100  00 00 10 02 00 50 95 14  01 c9 00 00 00 00 00 00  |.P..|
0110  00 00 0a 0d 0a 00 72 3e  6e 67 69 6e 78 0d 0a 00  |..r>nginx...|
0120  3e 0d 0a 00 0a 00 00 00  00 00 10 02 00 50 95 14  |>P..|
0130  01 c9 00 00 00 00 00 00  00 00 0a 0d 0a 00 72 3e  |..r>|
0140  6e 67 69 6e 78 0d 0a 00  3e 0d 0a 00 0a 00 00 00  |nginx...>...|
0150  00 00 10 02 00 50 95 14  01 c9 00 00 00 00 00 00  |.P..|
0160  00 00 0a 66 65 74 63 68  3a 20 68 74 74 70 3a 2f  |...fetch: http:/|
0170  2f 64 69 73 74 63 61 63  68 65 2e 75 73 2d 77 65  |/distcache.us-we|
0180  73 74 2e 66 72 65 65 62  73 64 2e 6f 72 67 2f 78  |st.freebsd.org/x|
0190  3a 20 4e 6f 74 20 46 6f  75 6e 64 0a  |: Not Found.|
019c

The expected output is returned by wget, e.g.:

$ wget -d http://distcache.us-west.freebsd.org/x
[...]
404 Not Found
Registered socket 3 for persistent reuse.
Skipping 146 bytes of body: [
404 Not Found

404 Not Found
nginx


] done.
2021-09-09 15:37:02 ERROR 404: Not Found.

Part of the HTML response can be found in the fetch output, too:

"r>nginx" is obviously a fragment of "nginx", but "r>nginx"
appears twice, 40 bytes apart.

"tle>404 Not Found" is a fragment of "404 Not Found", with "404
Not Found" appearing a total of 3 times ...

This could be a result of recent changes to the memcpy function, which used to
allow overlapping buffers, but does not anymore on -CURRENT.

But the 4 occurences of memcpy() in libfetch/http.c and libfetch/common.c seem
to be sane, and I did not look any further for the source of the data 
corruption.


OpenPGP_signature
Description: OpenPGP digital signature