From nobody Wed Dec 18 13:47:41 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YCw3g19WYz5hN51 for ; Wed, 18 Dec 2024 13:47:43 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YCw3g0cf5z4G46; Wed, 18 Dec 2024 13:47:43 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734529663; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=agQwy+Nndlr9Oa295TqwOES2FwBTUZ4r1mrORGsKsdA=; b=ZVLVgjOpiPV1tBHVmLlzBEijOncmaAtIivA4wQ110R/qsbCjzksy7DNNQhxb5sFpKasxhN Ev/e/tqXgBZYdQlmrdnZLaGlCzn7jVXGdDCf4IJ5iAvKU88fP9ImtPxbinh09BNnohqjQ5 y+E+oUijvS8n0BLxV8GmN1v/f59PE/90GBMNCO+YeZ8F78pPY8aFub/DlKrTQ/qhmQg8gD yKV8owt1TCGNbmIlfaY67b0FXZrpXmIbTYidnsDmJJsdmGoBlrgPbUEGVmGyhxnI+/lKQx BjnpQ6YsPICjtg6BIyncY7kjElwuITRVjoQDw37kBaA9B/2mxMfa6B8kFpTSfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734529663; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=agQwy+Nndlr9Oa295TqwOES2FwBTUZ4r1mrORGsKsdA=; b=tluK95PT/6oFAxc1qVEKxGVAF2hs+C2A9E4+VNj2ST0bInLIksoJ5Bc2SQ2D+/PEIlf3KK 9iBlaAQzubC/26Oa/uwRM2IMwh2Tm2XchN/hLBVt+wmsiN/wyqJ7M9Dj8Ux1O/GdQP2pkW ljFjK/cQsZ22nG/YS8IzQfanld/n9PrS0mLmt7QhXORzD4Cj4EWOv1N2N7yynF0pAwWgZr hMm6TMG5zdDRcJdfa1mI9gDr9NvGnXwJ9FFSfDQ58/HsCGDyGGXXiyA89ZmtbfIN+uHo4a Wg2mHkzhXfEQy5oEv5pe97ghUdI5FSrj1KnhwNkljOBg7Yc+Ar5+2djGTl45EQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734529663; a=rsa-sha256; cv=none; b=wgeWEXGwVcy6s1zgHGN9Mf1STLbesPrDhjUB07dVvBvQrXcICy5KVSFsQOakfaUVWEhwsP a1B320utGfZYgi7LfIQFISXSGTfUC58XBIgRRQroyzpfeqxqOkCT2dq85Ipc2gtXrYTjCA uATs6HaiZBwWFk32y7O+mQJkmMtZW+ft/XbBRJx8Yc4XnFljkAu4wl9IS74N+ZUblzXksA PUyivo49FsPVHaboCIaL1WQKi0JPyd7/S0GmV7t+eje4TcHZ0n4i5qQIyd423OFnF+qpEh OlJU9C1Wv0nLOuwyuKEiJ4cw1QOIv1ahicdkblcncMZKvNQJfPyfkNclEUf/kg== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YCw3f5YCWz1Brj; Wed, 18 Dec 2024 13:47:42 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <98535948-3426-4f87-b83b-29952ed356b3@FreeBSD.org> Date: Wed, 18 Dec 2024 07:47:41 -0600 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Removing shar(1) To: Tomoaki AOKI Cc: freebsd-arch@freebsd.org References: <0d63a94d-2773-4efd-b789-0b753ab38b91@FreeBSD.org> <20241218182200.0096ef17f7a0714291da1afc@dec.sakura.ne.jp> Content-Language: en-US From: Kyle Evans In-Reply-To: <20241218182200.0096ef17f7a0714291da1afc@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/18/24 03:22, Tomoaki AOKI wrote: > On Tue, 17 Dec 2024 20:27:16 -0600 > Kyle Evans wrote: > >> Hi, >> >> I was reminded the other day that shar(1) exists, though it's use is no >> longer recommended in ports. The same functionality can be found in >> tar(1) instead, so I think we should deorbit /usr/bin/shar and stop >> promoting it entirely. sh(1) archives are really problematic from a >> user standpoint for at least one reason best explained by the manpage: >> >> It is easy to insert trojan horses into shar files. It is strongly >> recommended that all shell archive files be examined before running >> them through sh(1). Archives produced using this implementation of >> shar may be easily examined with the command: >> >> egrep -av '^[X#]' shar.file >> >> It's hard to advocate for their use in good conscience, much like it's >> hard to advocate curl|sh pipes. >> >> Review: https://reviews.freebsd.org/D48130 >> >> Thanks, >> >> Kyle Evans > > Unfortunately, there's some reporters (sorry, lost track with examples) > providing error outputs and/or patches as shar files. > (I myself dislike it, though, and consider them as "nonexistent" unless > it is a set of patches and multiple comments "it works" are posted.) > > If we drop it, such users would complain. But when I really need the > contents to look into the problem, I usually request the reporters to > re-upload the contents as flat texts or non-executable archives like > *.txz. > The behavior is still there in tar(1), but these are the cases that I don't sympathize with even remotely. I feel even stronger about this than the original proposal here- we should absolutely be discouraging this in our own bug tracker. If you want to use these between your own systems, that's fine, but don't make the users of our bug trackers have to be even more paranoid about attachments. > And IIRC, RPMs for Linux binaries containing install-time scripts would > have similar problems. > Can you expand on that? Why are install-time scripts generating shar-cives, and what's happening with the results? Why are they running in a context with host tools and not a linux jail/chroot? Thanks, Kyle Evans