From nobody Fri Dec 20 15:37:50 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 4YFBPr1WV1z5Ws24 for ; Fri, 20 Dec 2024 15:37:52 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4YFBPr10xNz4vmP; Fri, 20 Dec 2024 15:37:52 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734709072; 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=SGr4slRJ4LogJMY5JQPcCYYgj3VMCcseZfkcBAgyC8g=; b=GcunMrvLQ56C3eRImmHFQLgJ3+EFC/zSYgckSTJ2Ltv9Rl79kWri9TqAwVpzEdgT+shBLU vKAy8puiICeRTV2ksmMckqcZ8ylKqruW1AiW8Ib2ChcE9+G55llUHIogRNKr8vQMA/eQGa nbltlRT7/+qMdQvGuO21PZiXZvbxm+nGwwl0OYTP/cxUD33aBR3QHYSvuwoQJvKEih7CCM HeWg7uqndK7WL6QCBfD3LH9dZsu0V5lXnfckabcgX14gq5vaMtVOM7I6npeXQa3hyo2JXV PF0ik8r2F2aZs5KAFvfh3s53PLl24qnqQHy679QA9mmtXLE00vIKEQKqhaoi6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734709072; 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=SGr4slRJ4LogJMY5JQPcCYYgj3VMCcseZfkcBAgyC8g=; b=gzzCqp2kw5uhXFMy1EDJ3zZlKbC5C6LJbJ42O6gjnSKFudO6XD7WZq+pMn0U7WNFdElxNI BQidqLGLLvNAyZ7SZA1QdXn4X6V7VVlntb0m6TFnBro6VZE5CTw7y+8SQn/59vyRksuD/E u6GvUOY/D+oTev5QhmxeXNPwDfL+7f6Sa/n7f1O1dOGoFKgy8rExe1zp6TFXGpAaT0+lVb VXZQNsOqKtQ045kAOVcEsBJFxvTynHq0XvX4cBwEQYyjlO5Sam13gRt6xcWXbexv+ilHmr 6ELhUdfgCSQ5CVQAxNxNJ7NZ+xWLt77PYH7jK9AyGVrcwrbwBoRdtG9yIjBLlw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734709072; a=rsa-sha256; cv=none; b=ofVojeTBDGNKeT/+skqL/D/Pkvm5djbhos0HNpsOjXmNbR4mqH4hhqfgkd01kaek5HHAIi 2X05qm28OKH36WizvLyUD3Dw+Pn6vTJFj3D7tckSLGTdO4JlLZKSZQ07nRMBAriGWu1+HH 2tbMOctTrTHfQFth3+TedvipwkK1CVm9Hx+QsT6L2aoEOG3ZdFveK3KGEbM3OLAX1k0vA8 bs5mt58SWVU26QfgWJJFOOdWbCSMXd6PrnqiG7+k4PI5uUYgR6MLcxtfO5EwHVxj/d/clI bfYGWsgaLmysNVlCJeOLBnhy2Rd/CXGHHM1h8RC1CgyAFrnrPJUjgzfUZnBokw== 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)) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4YFBPq5YKlz1GfQ; Fri, 20 Dec 2024 15:37:51 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <15ff7220-9a07-46f6-a0fc-20fcf237ab25@FreeBSD.org> Date: Fri, 20 Dec 2024 09:37:50 -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: "Rodney W. Grimes" Cc: Robert Clausecker , freebsd-arch@FreeBSD.org References: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> Content-Language: en-US From: Kyle Evans In-Reply-To: <202412201520.4BKFK2pH037264@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/20/24 09:20, Rodney W. Grimes wrote: >> On 12/20/24 08:56, Rodney W. Grimes wrote: >>>> On 12/18/24 05:04, Robert Clausecker wrote: >>>>> Hi Kyle, >>>>> >>>>> With shar no longer being recommended for the submission of new ports, >>>>> I see no objection to removing this feature. However, tar(1) should >>>>> keep the functionality. >>>>> >>>> >>>> I make no proposal to remove it from tar- that'd be really annoying >>>> after recommending people use tar(1) instead both here and in the patch >>>> below. >>> >>> Isnt this a bit oxy-moronic? Remove shar, yet point people to the exact >>> same behavior in another binary shipped with the system? Your basically >>> leaving the foot shooting neck hanging rope in the system and doing zip >>> to remove the fact this fucntionality should NOT be removed. >>> >> >> No, because the pointer is gone once shar(1) is gone. The functionality >> will not removed, just the convenient front-end. You still have tar(1). > > If you dont remove the functionality the sum game is zero improvement. > You have done NOTHING but remove a pointer (shar) to a function. > In my book that is security through obscurity and just silly. > If the shar create function needs to go because of security it nneds > to go from ALL places. > I'm not arguing that the functionality needs to go for security reasons, I'm arguing that we need to stop promoting the functionality as prominently as it is today. I don't have any problem with people using it for their own purposes, or with third parties that agree to it. I have problems with people that see shar(1) as a good option because it's a first-class citizen along with the likes of cpio/tar/pax without considering the implications for the user of the archive. >> >>> Your basically breaking things without any increase in security. >>> >>> FIRM NO here. >>> >>>> >>>>> We should consider replacing shar(1) by an implementation that just calls >>>>> into tar(1) to do its job. >>>>> >>>> >>>> Strongly prefer not to if we can avoid it (I'm not seeing any arguments >>>> that we really need it to be a first-class citizen); I view that as >>>> promoting functionality that we shouldn't be encouraging, along with >>>> providing a manpage. >>> >>> Basically your just making it inconvinvient to get to the rope for those >>> that do know how to not hang themselves. >>> >> >> The rope is also great for hanging others, and it'd be great to shove it >> behind all of the better tools in the shed. > > Obscurity process is NOT what BSD does. > >> What actual reasoning do you have for keeping shar(1) specifically? > > I didnt site any. I sited that your removing half of the problem is > not a reasonable approach. Either remove it totally or do not touch > it at all. > >> Your entire argument so far boils down to "You shouldn't remove it," > > Wow, really, thats how you read it. > Feel free to explain it more clearly, then. Thanks, Kyle Evans