From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12057 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: "musl" gzip-compressed tarballs are decompressed if using newest wegt release Date: Wed, 1 Nov 2017 14:08:07 -0400 Message-ID: <20171101180807.GH1627@brightrain.aerifal.cx> References: <20171101152604.GG1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1509559701 23099 195.159.176.226 (1 Nov 2017 18:08:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Nov 2017 18:08:21 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12071-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 01 19:08:17 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1e9xR1-0005QG-Ru for gllmg-musl@m.gmane.org; Wed, 01 Nov 2017 19:08:15 +0100 Original-Received: (qmail 28295 invoked by uid 550); 1 Nov 2017 18:08:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 28277 invoked from network); 1 Nov 2017 18:08:19 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12057 Archived-At: On Wed, Nov 01, 2017 at 04:50:01PM +0100, Jens Schleusener wrote: > On Wed, 1 Nov 2017, Rich Felker wrote: > > >On Wed, Nov 01, 2017 at 11:19:30AM +0100, Jens Schleusener wrote: > >>Hi, > >> > >>not a real "musl" software problem but just an observation of a > >>changed behaviour of "musl" tarball downloads with the newest "wegt" > >>release (1.19.2): The tarballs are saved now decompressed but > >>contains the original extension (.tar.gz). Although if the extension > >>would be .tar it seems at least to me an undesired behaviour. > >> > >>Reason seems a new "wget" feature, here some extracted lines taken > >>from the ChangeLog > >> > >> 2017-08-04 > >> Add gzip Content-Encoding decompression > >> (gethttp): Decompress files with gzip Content-Encoding > >> > >>in combination with the HTTP header the www.musl-libc.org server delivers: > >> > >> Content-Type: application/x-tar > >> Content-Encoding: gzip > >> > >>Solutions/workarounds may be on the server side delivering of a HTTP > >>header like > >> > >> Content-Type: application/x-gzip > >> (or Content-Type: application/octet-stream) > >> > >>or on the client side the use of the new "wget" option > >> > >> --compression=none > > > >IMO this is both a bug in the server and a major regression in wget, > >since lots of servers have this bug. I'll look at fixing it on my side > >but I think it should be reported to wget and reverted since this is > >going to break a *huge* number of build scripts that download tarballs > >from affected servers. > > Thanks for the more clear statement (I agree). If not already done > by another person I will send an accoding mail to the "bug-wget" > list. It should be fixed now. I've written a patch for thttpd that removes the content-transfer-encoding nonsense and submitted it for inclusion in Alpine Linux (used on musl's web host) and already installed the patched package myself. Hopefully this will eventually make it upstream to thttpd, but it seems mostly unmaintained. FWIW I'd love to switch to a better httpd that's actually maintained, but I need something with simple migration path and without loads of unwanted bloat. Needs to be able to: - support host header based vhosts, translated to dir names under web root. - execute cgi (only!) from a configured whitelist of pathnames - support url paths that go past the cgi program, i.e. /cgit/musl/... where /cgit is the cgi executable - honor symlinks (without any attempt to [re]interpret them) Solution which involve a process per static-content request are not really desirable. Recommendations would be welcome. Rich