From owner-freebsd-bugs@FreeBSD.ORG Tue Nov 24 19:20:03 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2900E1065679 for ; Tue, 24 Nov 2009 19:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DE1C58FC1F for ; Tue, 24 Nov 2009 19:20:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAOJK23F014035 for ; Tue, 24 Nov 2009 19:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAOJK2Pi014034; Tue, 24 Nov 2009 19:20:02 GMT (envelope-from gnats) Resent-Date: Tue, 24 Nov 2009 19:20:02 GMT Resent-Message-Id: <200911241920.nAOJK2Pi014034@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jeremy Chadwick Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5720106566B for ; Tue, 24 Nov 2009 19:18:50 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5168FC0A for ; Tue, 24 Nov 2009 19:18:50 +0000 (UTC) Received: from OMTA18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 96ah1d0071bwxycA174usq; Tue, 24 Nov 2009 19:04:54 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by OMTA18.emeryville.ca.mail.comcast.net with comcast id 97E41d00F3S48mS8e7E4Av; Tue, 24 Nov 2009 19:14:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3A0A81E3035; Tue, 24 Nov 2009 11:05:39 -0800 (PST) Message-Id: <20091124190539.3A0A81E3035@icarus.home.lan> Date: Tue, 24 Nov 2009 11:05:39 -0800 (PST) From: Jeremy Chadwick To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: bin/140835: libfetch: fetchParseURL(3) returns success with invalid URLs X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jeremy Chadwick List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:20:03 -0000 >Number: 140835 >Category: bin >Synopsis: libfetch: fetchParseURL(3) returns success with invalid URLs >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 24 19:20:02 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Jeremy Chadwick >Release: FreeBSD 8.0-PRERELEASE amd64 >Organization: >Environment: System: FreeBSD icarus.home.lan 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 17 20:07:21 PST 2009 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 >Description: libfetch contains a function, fetchParseURL(3), whose man page states the following: fetchParseURL() takes a URL in the form of a null-terminated string and splits it into its components function according to the Common Internet Scheme Syntax detailed in RFC1738. A regular expression which produces this syntax is: :(//((:)?@)?(:)?)?/()? If the URL does not seem to begin with a scheme name, the following syn- tax is assumed: (((:)?@)?(:)?)?/()? Note that some components of the URL are not necessarily relevant to all URL schemes. For instance, the file scheme only needs the and components. ..... fetchParseURL() returns a pointer to a struct url containing the individ- ual components of the URL. If it is unable to allocate memory, or the URL is syntactically incorrect, fetchParseURL() returns a NULL pointer. But when passed a URL such as the below (note the delimiter is colon-slash, not colon-slash-slash) http:/www.somesite.com/ fetchParseURL(3) returns a pointer to a struct with the following data: url->scheme = http url->user = url->pwd = url->host = url->port = 0 url->doc = /www.somesite.com/ Given the documentation, fetchParseURL(3) should return NULL in this scenario; it was able to work out the scheme by itself, which implies that the RFC1738-compliancy paragraph of the documentation should apply strictly. This issue came to light on freebsd-stable: http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052969.html http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052971.html http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052972.html http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052973.html >How-To-Repeat: $ fetch http:/www.somesite.com/ fetch: http:/www.somesite.com/: No address record $ fetch http:/localhost/ fetch: http:/localhost/: No address record >Fix: None known. >Release-Note: >Audit-Trail: >Unformatted: