From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 19:13:31 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7707DEFD for ; Tue, 10 Feb 2015 19:13:31 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FB2D96A for ; Tue, 10 Feb 2015 19:13:31 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLGFV-000Lzz-8m; Tue, 10 Feb 2015 22:13:29 +0300 Date: Tue, 10 Feb 2015 22:13:29 +0300 From: Slawa Olhovchenkov To: John-Mark Gurney Subject: Re: removing bdes.. Message-ID: <20150210191329.GL3698@zxy.spb.ru> References: <20150209181502.GF1953@funkthat.com> <20150210151812.GB67127@zxy.spb.ru> <20150210172039.GA1071@reks> <20150210175240.GD67127@zxy.spb.ru> <20150210175852.GV1953@funkthat.com> <20150210180906.GI3698@zxy.spb.ru> <20150210181916.GY1953@funkthat.com> <20150210183638.GK3698@zxy.spb.ru> <20150210190132.GB1953@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210190132.GB1953@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:13:31 -0000 On Tue, Feb 10, 2015 at 11:01:32AM -0800, John-Mark Gurney wrote: > > > > Ah, bdes utility, sorry. > > > > But this is only 20K binary and 25K source and 80K documenation. > > > > And need to update ed(1) (keep 80K documentation?) > > > > > > See my other comment on lack of maintaining the utility... > > > > Sorry, I am not understand you point ("someone marked it as insecure" -- right?). > > Yes, but it took 15 years for someone to do that.. What other issues > remain in the utility? I am missing -- what issuse found in this utility? Insecure algorithm? This is not issuse. > > What need to maintaining in this utility? > > I don't know, but that's the point... Is the risk/cost of this utility > more or less than the cost of having this utility... Since I have a > feeling that only a handful (none?) of people are currently using this > utility, the risk/cost is higher than the benifit of having it... What risk of having not suid, not network utility? > > And what is insecure in this utility? > > (As I understanding 'insecure' -- allowing to gain unauthorise access > > or execute unapproved action) > > gain unauthorized access is what is insecure... Any data encrypted > using this utility would put the data at risk of an unathorized party > gaining access to said data (due to the use of an insecure crypto > algorithm)... Hmm, as I reminder FreeBSD motto is "tools, not policies". If tools work as expected -- all OK. Deny insecure crypto algorithm? Why don't force to use stong crypto algorithm in all places (force disk, swap and memory encryption)? Deny unencrypted network connection? Deny unencrypted arhive? > > > > x Prompt for an encryption key which is used in subsequent reads > > > > and writes. If a newline alone is entered as the key, then > > > > encryption is turned off. Otherwise, echoing is disabled while a > > > > key is read. Encryption/decryption is done using the bdes(1) > > > > algorithm. > > > > > > It turns out that ed has it's own implementation baked in, so removing > > > bdes will not effect ed's functionality... > > > > > > In my search, it looks like I'll take enigma along w/ bdes... > > > > I am talk this not about utility bdes, I am talk about bdes.1 man page > > and bdes.ps. I think not good reference to not-existing man page. > > > > May be need to update ed.1? > > We can simply remove the Xr if that really concerns you, but as the > port would have the man page it isn't always not-existant... I see > some benefit to keeping it, though someone from the -docs team would > speak up...