Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
New Bug report received and forwarded. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
Package: wget
Version: 1.8.1-6.1
Severity: grave
Justification: user security hole
Tags: security patch
Hi.
Wget does absolutely no filtering of the server-supplied error messages,
and redirection URLs. And probably just anywhere else.
Both 1.8 & 1.9 branches exhibit this behaviour.
A simple not-very-functional demo is attached.
I found out there are just too many places where wget should filter, but
doesn't. The enclosed patch is covering just one of these places,
sadly. And even this tiny bit is covered badly, as, e.g., there's no
need to mark the message as server-generated, when in fact it's our
message about the lack of any message from the server, heh.
The comments in the patch should explain my reasoning in detail -- the
basic goals:
(1) Filter escape sequences & friends
-- HTTP 1.1 RFC allows [^\r\n\x00-\x1f\127]
(2) Mark the beginning & the end, and purpose of the message (``Remote
server said: >>> ... <<<'')
(3) Don't allow ending faking (remove extraneous whitespace, escape the end mark)
-- ``A recipient MAY replace any linear white space with a single SP
before interpreting the field value'' -- RFC 2616, Section 2.2
Please CC me, when appropriate.
Cheers.
Jan.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux kontryhel 2.4.26-jan #3 SMP Mon Apr 19 05:00:00 CEST 2004 i686
Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2
Versions of packages wget depends on:
ii libc6 2.2.5-11.5 GNU C Library: Shared libraries an
--
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
+ /* We encode each byte using at most 4 bytes, + trailing '\0'. */
+ buf = xmalloc (4 * strlen (reason_phrase_ptr) + 1);
Where is this buffer freed? Or is this compatible with the existing
approach to memory management in wget?
- logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"),
+ /*
+ * XXX Let's not allow the attacker pretend it's us speaking.
+ *
+ * It's important to:
+ * (1) Explain who created the message
+ * (2) Mark very visibly the beginning & end of the message
+ * (3) Make clear we have no connection whatsoever with this message
+ */
+ /* logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"), */
+ logprintf (LOG_NOTQUIET,
+ _("%s ERROR: Remote server said: >>> %d %s <<<.\n"),
I suppose that it would be better to use C-style quoting (with "")
instead of yet another ad-hoc string literal syntax. To increase
backwards compatibility, it's probably best to add the quotes only if
potentially harmful characters are actually contained in the server
response.
Note that you'd also have to change escape_reason_phrase().
- logprintf (LOG_NOTQUIET, "%d %s\n\n", hstat.statcode, hstat.error);
+ logprintf (LOG_NOTQUIET, _(">>> %d %s <<<\n\n"),
+ hstat.statcode, hstat.error);
Same here.
What's the status of this bug with respect to upstream? Has it been
sent in for review?
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Noèl Köthe <noel@debian.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
Am Fr, den 30.07.2004 schrieb Florian Weimer um 20:25:
> What's the status of this bug with respect to upstream? Has it been
> sent in for review?
bug/patch submitter CC: the report to the upstream mailinglist (archive:
http://www.mail-archive.com/wget%40sunsite.dk/) but there is no answer
to the mail until now.
--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Noèl Köthe <noel@debian.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
Am Fr, den 30.07.2004 schrieb Florian Weimer um 20:25:
Hello,
fullquote because Jan asked for CC: and the previous mail wasn't CC: to
him.
> + /* We encode each byte using at most 4 bytes, + trailing '\0'. */
> + buf = xmalloc (4 * strlen (reason_phrase_ptr) + 1);
>
> Where is this buffer freed? Or is this compatible with the existing
> approach to memory management in wget?
>
> - logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"),
> + /*
> + * XXX Let's not allow the attacker pretend it's us speaking.
> + *
> + * It's important to:
> + * (1) Explain who created the message
> + * (2) Mark very visibly the beginning & end of the message
> + * (3) Make clear we have no connection whatsoever with this message
> + */
> + /* logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"), */
> + logprintf (LOG_NOTQUIET,
> + _("%s ERROR: Remote server said: >>> %d %s <<<.\n"),
>
> I suppose that it would be better to use C-style quoting (with "")
> instead of yet another ad-hoc string literal syntax. To increase
> backwards compatibility, it's probably best to add the quotes only if
> potentially harmful characters are actually contained in the server
> response.
>
> Note that you'd also have to change escape_reason_phrase().
>
> - logprintf (LOG_NOTQUIET, "%d %s\n\n", hstat.statcode, hstat.error);
> + logprintf (LOG_NOTQUIET, _(">>> %d %s <<<\n\n"),
> + hstat.statcode, hstat.error);
>
> Same here.
>
> What's the status of this bug with respect to upstream? Has it been
> sent in for review?
Still no answer from upstream to Jans patch/bug.
--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
On Wed, Aug 11, 2004 at 01:08:24PM +0200, Noel Köthe wrote:
> Am Fr, den 30.07.2004 schrieb Florian Weimer um 20:25:
> fullquote because Jan asked for CC: and the previous mail wasn't CC: to
> him.
Thanks. Note that when you send a mail to <number>@bugs.debian.org, the
original submitter is *not* sent a copy; you have to CC: the submitter
explicitly.
> > + /* We encode each byte using at most 4 bytes, + trailing '\0'. */
> > + buf = xmalloc (4 * strlen (reason_phrase_ptr) + 1);
> >
> > Where is this buffer freed? Or is this compatible with the existing
> > approach to memory management in wget?
It isn't. Did I mention I can't code in C?...
> > - logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"),
> > + /*
> > + * XXX Let's not allow the attacker pretend it's us speaking.
> > + *
> > + * It's important to:
> > + * (1) Explain who created the message
> > + * (2) Mark very visibly the beginning & end of the message
> > + * (3) Make clear we have no connection whatsoever with this message
> > + */
> > + /* logprintf (LOG_NOTQUIET, _("%s ERROR %d: %s.\n"), */
> > + logprintf (LOG_NOTQUIET,
> > + _("%s ERROR: Remote server said: >>> %d %s <<<.\n"),
> >
> > I suppose that it would be better to use C-style quoting (with "")
> > instead of yet another ad-hoc string literal syntax.
Let's split this effort in four consequential steps:
(I) Filtering the control characters (including escape-sequences).
This is easy, if it weren't for so many places in the code that have to
be changed, and the massive difference between the woody & sarge
version. Just set the correct locale, do isprint(), and escape
appropriately. This can and should be adopted without a delay.
The following steps deal primarily with the freeform server-response:
(II) Making it possible to determine what the server-response is
You have to ensure the beginning & ending delimiters are not spoofable.
With Unicode, where similar glyphs are not so uncommon, and '\n' being
supplied by the terminal by the virtue of wrapping, this soon gets
tricky.
The begin-delimiter is ``Remote server said: BEGIN_QUOT'', the
end-delimiter is ``END_QUOT\n''. The begin-delimiter will work good,
regardless of the BEGIN_QUOT value. The only problem is we can't really
tell whether it was the *remote server*, or some third party (attacker),
who originated the message. If someone could come up with a more
appropriate phrase, I'd be pleased. The end-delimiter and any similar
glyphs (locale-dependent) will be escaped in the server-response, so
that it can't be spoofed. As we will never know which characters look
similar in a given font/locale combination, therefore we can never be
100% confident we are secure against spoofing. This, too, can be
implemented right ahead.
I chose ">>>"/"<<<" (and not e.g. '"') for BEGIN_QUOT/END_QUOT precisely
because it is not used anywhere in wget, and it looks strange, so to
pinpoint the message is not from us, but from some strange untrusted
source. ">>>" BTW is the python shell prompt.
(III) Marking the server-responses in an obvious and intuitive way
Hard if not impossible. Who cares about missing end-delimiter? When a
text starts in column 0, it looks like coming from the running program,
no matter what. You'd have to either turn the wrapping off, or you have
to know the width of the display. Or you can draw a border around the
whole message (horrible, and space-wasting).
We could collapse the end-delimiter just to ``\n'', and to split the
server-response in among multiple lines, prepending the begin-delimiter
and the (possibly different) begin-delimiter-continuation, before every
one. Then, we could leave out BEGIN_QUOT, too. This is likely to break
some existing software. The tricky part is to get the display width
*reliably*. We can't just default to 80, as this would present a
problem for terminals with the actual width <80. We could simply output
an error message and print *no* server-response. We could have our own
built-in dictionary of standard error number interpretations.
(IV) Making it impossible to fool a casual user
This is impossible. There will always people that would be vulnerable
because of bad luck, stupidity, poor language knowledge, etc.
> > To increase
> > backwards compatibility, it's probably best to add the quotes only if
> > potentially harmful characters are actually contained in the server
> > response.
Three points here:
(a) The user should get used to the format; this would improve
his/her confidence that what s/he sees is what s/he think it is.
(b) Any message above the numeric code is potentially dangerous; we are
talking social engineering here: we must make clear the message is *not
from us*.
(c) You are right that the original patch would break existing software,
so the new suggestion is to quote the free-form part of the server
response, and let the numeric code as it is.
_("%s ERROR %d: Remote server said: >>> %s <<<.\n"),
^^^
Please keep me CC'd.
Jan.
--
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Thomas Hood <jdthood@aglu.demon.nl>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
On Sun, Aug 22, 2004 at 11:39:07AM +0200, Thomas Hood wrote:
> The changes contemplated look very invasive. How quickly can this
> bug be fixed?
It looks like we'd have to go thru the whole code, sanitizing all calls
to logprintf() where a tainted variable is involved. This is tedious.
I'm leaning towards solving the control-chars injection by a wrapper
that would filter these. I can't think of no such workaround for the
spoofing vulnerability.
J.
--
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
On Sun, Aug 22, 2004 at 01:12:43PM +0200, Jan Minar wrote:
> I'm leaning towards solving the control-chars injection by a wrapper
> that would filter these. I can't think of no such workaround for the
> spoofing vulnerability.
Here's the script:
--- /dev/null Wed Dec 10 03:42:57 2003
+++ /home/jan/bin/wget Sun Aug 22 13:18:19 2004
@@ -0,0 +1,6 @@
+#!/bin/sh
+# ~jan/bin/wget -- wget wrapper that'll get rid of the escape sequences
+
+WGET=/usr/bin/wget
+
+"$WGET" -o /dev/fd/1 "$@" | filter-controls
Here's the filter-controls source:
--- /dev/null Wed Dec 10 03:42:57 2003
+++ /home/jan/code/filter-controls/filter-controls.c Tue Aug 17 01:50:28 2004
@@ -0,0 +1,43 @@
+#include <stdio.h>
+#include <ctype.h>
+#include <stdlib.h>
+
+void my_putchar(char);
+
+/* my_putchar(char) error-checking putchar() wrapper */
+/* DNW: Somehow echo hello | ./filter-controls > /dev/full returns 0. */
+inline void
+my_putchar (char c) {
+ if (putchar (c) == EOF) {
+ perror ("Error writing to stdout");
+ exit (1);
+ }
+}
+
+int
+main (void)
+{
+ int c;
+ int last_was_space = 0;
+
+ setbuf (stdout, NULL);
+
+ while ((c = getchar()) != EOF) {
+ if (isgraph(c) || c == '\n') {
+ my_putchar (c);
+ last_was_space = 0;
+ } else if (isspace (c)) {
+ if (last_was_space == 0)
+ my_putchar (' ');
+ last_was_space = 1;
+ } else {
+ my_putchar ('\\');
+ my_putchar ('0' + ((c & 0xff) >> 6));
+ my_putchar ('0' + ((c & 0x3f) >> 3));
+ my_putchar ('0' + (c & 7));
+
+ last_was_space = 0;
+ }
+ }
+ return 0;
+}
Of course the script is not necessary; I only didn't want to learn
setting up pipes in C.
The problem here is, we lose the nice progress bar, getting the tedious
dot-progress interface instead. Nobody will like this. So maybe
hooking/rewriting the logprintf() function will be an option, although
I don't like it.
Jan.
--
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
tags 261755 +patch
thanks
On Sun, Aug 22, 2004 at 11:39:07AM +0200, Thomas Hood wrote:
> The changes contemplated look very invasive. How quickly can this
> bug be fixed?
Here we go: Hacky, non-portable, but pretty slick & non-invasive,
whatever that means. Now I'm going to check whether it is going to
catch all the cases where malicious characters could be possibly
injected.
This patch (hopefully) solves the problem of remote attacker (server or
otherwise) injects malicious control sequences in the HTTP headers. It
by no mean solves the spoofing bug, which is by nature tricky to address
well.
Cheers,
Jan.
--
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
Tags added: patch
Request was from Jan Minar <jjminar@fastmail.fm>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
On Sun, Aug 22, 2004 at 08:02:54PM +0200, Jan Minar wrote:
> +/* vasprintf() requires _GNU_SOURCE. Which is OK with Debian. */
> +#ifndef _GNU_SOURCE
> +#define _GNU_SOURCE
This must be done before stdio.h is included.
> +#endif
> +#include <ctype.h>
> +
> #ifndef errno
> extern int errno;
> #endif
> @@ -345,7 +351,49 @@
> int expected_size;
> int allocated;
> };
> +
> +/* XXX Where does the declaration belong?? */
> +void escape_buffer (char **src);
>
> +/*
> + * escape_untrusted -- escape using '\NNN'. To be used wherever we want to
> + * print untrusted data.
> + *
> + * Syntax: escape_buffer (&buf-to-escape);
> + */
> +void escape_buffer (char **src)
> +{
> + char *dest;
> + int i, j;
> +
> + /* We encode each byte using at most 4 bytes, + trailing '\0'. */
> + dest = xmalloc (4 * strlen (*src) + 1);
> +
> + for (i = j = 0; (*src)[i] != '\0'; ++i) {
> + /*
> + * We allow any non-control character, because LINE TABULATION
> + * & friends can't do more harm than SPACE. And someone
> + * somewhere might be using these, so unless we actually can't
> + * protect against spoofing attacks, we don't pretend we can.
> + *
> + * Note that '\n' is included both in the isspace() *and*
> + * iscntrl() range.
> + */
> + if (isprint((*src)[i]) || isspace((*src)[i])) {
This lets '\r' thru, not good. BTW, (*src)[i] is quite a cypher.
> + dest[j++] = (*src)[i];
> + } else {
> + dest[j++] = '\\';
> + dest[j++] = '0' + (((*src)[i] & 0xff) >> 6);
> + dest[j++] = '0' + (((*src)[i] & 0x3f) >> 3);
> + dest[j++] = '0' + ((*src)[i] & 7);
> + }
> + }
> + dest[j] = '\0';
> +
> + xfree (*src);
> + *src = dest;
> +}
Attached is version 2, which solves these problems.
Please keep me CC'd.
Jan.
--
"To me, clowns aren't funny. In fact, they're kind of scary. I've wondered
where this started and I think it goes back to the time I went to the circus,
and a clown killed my dad."
Source: wget
Source-Version: 1.9.1-5
We believe that the bug you reported is fixed in the latest version of
wget, which is due to be installed in the Debian FTP archive:
wget_1.9.1-5.diff.gz
to pool/main/w/wget/wget_1.9.1-5.diff.gz
wget_1.9.1-5.dsc
to pool/main/w/wget/wget_1.9.1-5.dsc
wget_1.9.1-5_i386.deb
to pool/main/w/wget/wget_1.9.1-5_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 261755@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Noèl Köthe <noel@debian.org> (supplier of updated wget package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Mon, 13 Sep 2004 22:55:58 +0200
Source: wget
Binary: wget
Architecture: source i386
Version: 1.9.1-5
Distribution: unstable
Urgency: high
Maintainer: Noèl Köthe <noel@debian.org>
Changed-By: Noèl Köthe <noel@debian.org>
Description:
wget - retrieves files from the web
Closes: 197916261755
Changes:
wget (1.9.1-5) unstable; urgency=high
.
* added patch from Jan Minar <jjminar fastmail.fm> which corrects
the parsing/filtering of answer from servers
(Thanks alot for your help Jan!)
(closes: Bug#261755)
* documenting incompatibility of -k and -O
(closes: Bug#197916)
Files:
4543b701997bcb32529c78606b8e4081 596 web optional wget_1.9.1-5.dsc
2d9081bcbe108e443be4ed8f9c465537 11752 web optional wget_1.9.1-5.diff.gz
beb626e0a77a3eb9ed85bfdd89a1d800 424634 web optional wget_1.9.1-5_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBRgnL9/DnDzB9Vu0RAgE9AJ4nVAzUfQiHJrur2Eo1K4F8AFu3TACeMkpk
hMpSnjKIKfMR7TrYcRVns6o=
=hWNT
-----END PGP SIGNATURE-----
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Tomas Pospisek <tpo@sourcepole.ch>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
I'm going through the list of packages that are pending to transition from
sid->sarge in order to tag them for manual propagation [1]. I've seen that
wget in sid fixes a security issue [2] (no sanitizing of server
responses). Question:
* I don't really understand the bug's security implications. Should
sid's fixed wget be propagated to sarge?
* Does fix all the issues present in the code?
*t
[1] http://www.wolffelaar.nl/~sarge/
[2] http://bugs.debian.org/261755
--
--------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
--------------------------------------------------------
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Noèl Köthe <noel@debian.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
Am Sonntag, den 26.09.2004, 00:26 +0200 schrieb Tomas Pospisek:
> I'm going through the list of packages that are pending to transition from
> sid->sarge in order to tag them for manual propagation [1]. I've seen that
> wget in sid fixes a security issue [2] (no sanitizing of server
> responses). Question:
>
> * I don't really understand the bug's security implications. Should
> sid's fixed wget be propagated to sarge?
> * Does fix all the issues present in the code?
it opens this problem: #271931
Thats the reason why I didn't asked for moving it from sid to sarge.
sadly upstream is not available since some weeks to discuss this
problem.:(
--
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Tomas Pospisek <tpo_deb2@sourcepole.ch>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
On Mon, 27 Sep 2004, Noèl Köthe wrote:
> Am Sonntag, den 26.09.2004, 00:26 +0200 schrieb Tomas Pospisek:
>> I'm going through the list of packages that are pending to transition from
>> sid->sarge in order to tag them for manual propagation [1]. I've seen that
>> wget in sid fixes a security issue [2] (no sanitizing of server
>> responses). Question:
>>
>> * I don't really understand the bug's security implications. Should
>> sid's fixed wget be propagated to sarge?
>> * Does fix all the issues present in the code?
>
> it opens this problem: #271931
> Thats the reason why I didn't asked for moving it from sid to sarge.
> sadly upstream is not available since some weeks to discuss this
> problem.:(
OK, I've put that info into the release helping system [1]. Please update
it when the problem is fixed or let me know.
*t
[1] I don't know if the following link will work:
http://www.wolffelaar.nl/~sarge/?PHPSESSID=f957b02aa24b1a4ab9237ae4e80df6a9&package=wget&maint=&outofsync=&frozen=&status=
Otherwise just visit http://www.wolffelaar.nl/~sarge/,
enter wget in the first field and press return.
--
--------------------------------------------------------
Tomas Pospisek
http://sourcepole.com - Linux & Open Source Solutions
--------------------------------------------------------
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Jan Minar <jjminar@fastmail.fm>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
Hi all!
Sorry for not making the patch right the first (or was it second?) time.
And thank Ambrose and Ismail for reporting the bug and commenting upon
it.
I rewrote the patch to be multibyte-aware, please test it and/or review
it. When I say please review it, I mean it, because the wchar API is
really not my cup of tea, and I probably made silly mistakes and
introduced new and interesting problems.
This new patch introduces no difference in what is printed when ``wget
localhost'' is run, at least under cs_CZ.UTF-8, zh_CN.gb18030,
zh_CN.gb2312, zh_CN.gbk, and ja_JP.eucjp locales.
BTW: Does anybody know why is upstream completely ignoring this issue?
Cheers,
--
Jan
Message sent on to Jan Minar <jjminar@fastmail.fm>:
Bug#261755.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Ismail Donmez <kde@myrealbox.com>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
On Tuesday 28 September 2004 22:41, Jan Minar wrote:
> Hi all!
>
> Sorry for not making the patch right the first (or was it second?) time.
> And thank Ambrose and Ismail for reporting the bug and commenting upon
> it.
>
> I rewrote the patch to be multibyte-aware, please test it and/or review
> it. When I say please review it, I mean it, because the wchar API is
> really not my cup of tea, and I probably made silly mistakes and
> introduced new and interesting problems.
>
> This new patch introduces no difference in what is printed when ``wget
> localhost'' is run, at least under cs_CZ.UTF-8, zh_CN.gb18030,
> zh_CN.gb2312, zh_CN.gbk, and ja_JP.eucjp locales.
>
> BTW: Does anybody know why is upstream completely ignoring this issue?
Tested with LC_ALL=tr_TR.UTF-8 and works fine for me. Thanks for the fix!
Regards,
ismail
Message sent on to Jan Minar <jjminar@fastmail.fm>:
Bug#261755.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
To: 284875@bugs.debian.org, 261755@bugs.debian.org
Subject: wget - solving strategies
Date: Tue, 4 Jan 2005 22:03:27 +0100
reopen 261755
tag 261755 +sarge
thanks
Hi,
just a few annotation from me on how to make wget reach sarge. IMHO,
the current patch to 261755 is _not_ acceptable for inclusion into a
stable release, because it is too clumpsy. It is of no use to filter the
printout to the console (after adding localized characters), but the
sanitation should take part of the input stream.
Therefore, IMHO the right fix to the other bug is a prerequisite to be
able to finally release with a good version of wget.
Some annotations to the listed bugs:
Can (1) really happen in a normal scenario? According to the man page
When running Wget without -N, -nc, or -r, downloading the same file in
the same directory will result in the original copy of file being
preserved and the second copy being named file.1.
So, this case will happen only if -r is specified. (Or is wget buggy to
allow the remote side to overwrite that documented behaviour?)
(2) seems to happen _exactly_ when the hostnames are created in the
directory hierarchy. This needs tackling.
(3) see my comment above.
(4) needs probably be discussed a bit more.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug reopened, originator not changed.
Request was from Andreas Barth <aba@not.so.argh.org>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Noèl Köthe <noel@debian.org>: Bug#261755; Package wget.
(full text, mbox, link).
Acknowledgement sent to Hrvoje Niksic <hniksic@xemacs.org>:
Extra info received and forwarded to list. Copy sent to Noèl Köthe <noel@debian.org>.
(full text, mbox, link).
Subject: wget: Server responses &c written to the tty verbatim (escape
sequences, control characters, ...)
Date: Thu, 05 May 2005 16:04:03 +0200
This bug has been fixed in CVS. Wget filters escape sequences when
printing untrusted strings (those coming from the remote server).
Newlines and TABs are escaped, which makes it much harder to mimic
Wget's output, at least without knowing the exact width of the
terminal.
Reply sent to Noèl Köthe <noel@debian.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Jan Minar <jjminar@fastmail.fm>:
Bug acknowledged by developer.
(full text, mbox, link).
Source: wget
Source-Version: 1.9.1-11
We believe that the bug you reported is fixed in the latest version of
wget, which is due to be installed in the Debian FTP archive:
wget_1.9.1-11.diff.gz
to pool/main/w/wget/wget_1.9.1-11.diff.gz
wget_1.9.1-11.dsc
to pool/main/w/wget/wget_1.9.1-11.dsc
wget_1.9.1-11_i386.deb
to pool/main/w/wget/wget_1.9.1-11_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 261755@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Noèl Köthe <noel@debian.org> (supplier of updated wget package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 05 May 2005 22:58:58 +0200
Source: wget
Binary: wget
Architecture: source i386
Version: 1.9.1-11
Distribution: unstable
Urgency: high
Maintainer: Noèl Köthe <noel@debian.org>
Changed-By: Noèl Köthe <noel@debian.org>
Description:
wget - retrieves files from the web
Closes: 261755284875305425
Changes:
wget (1.9.1-11) unstable; urgency=high
.
* going back to -8 status to have minimal changes to current
sarge version
* backported fixes from Hrvoje Niksic/upstream from wget 1.10
cvs version (thanks alot Hrvoje Niksic!):
- adds the filtering of control chars
(closes: Bug#261755)
- prevents hosts named ".." from writing to ../. and
prevents "%00" truncating C strings that hold URLs
(closes: Bug#284875)
* removed unneeded texi2html build-dep
(closes: Bug#305425)
Files:
ba4c07b0f2a9981892537cafd67db973 587 web optional wget_1.9.1-11.dsc
1421b183f36da51ee3d39377cfae5db5 17197 web optional wget_1.9.1-11.diff.gz
f200df94d7cb8dc369bcd973d0576ae8 425918 web optional wget_1.9.1-11_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCeoQl9/DnDzB9Vu0RAgNiAJ4w+fXh7GnvM9l6ofVryTol22RyTQCeJjGc
ulkXZX2xdW1kUlublPyy0sg=
=868g
-----END PGP SIGNATURE-----
Bug reopened, originator not changed.
Request was from Frank Lichtenheld <djpig@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Tags added: sarge
Request was from Frank Lichtenheld <djpig@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Bug closed, send any further explanations to Jan Minar <jjminar@fastmail.fm>
Request was from Frank Lichtenheld <djpig@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Tags removed: sarge
Request was from Frank Lichtenheld <djpig@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.