From owner-freebsd-arch@FreeBSD.ORG Tue Feb 10 19:49:23 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA684963 for ; Tue, 10 Feb 2015 19:49:23 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BDEA0D1C for ; Tue, 10 Feb 2015 19:49:23 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1AJnMIb033840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2015 11:49:22 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1AJnMu5033839; Tue, 10 Feb 2015 11:49:22 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Feb 2015 11:49:22 -0800 From: John-Mark Gurney To: Slawa Olhovchenkov Subject: Re: removing bdes.. Message-ID: <20150210194922.GF1953@funkthat.com> 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> <20150210191329.GL3698@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210191329.GL3698@zxy.spb.ru> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 10 Feb 2015 11:49:23 -0800 (PST) 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:49:24 -0000 Slawa Olhovchenkov wrote this message on Tue, Feb 10, 2015 at 22:13 +0300: > 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. Then why is SSL now rumored to be removed from PCI-DSS if algorithm is not a security issue? The entire industry thinks that insecure algorithms are an issue.... If this had been 3DES, I wouldn't be propsing to remove it.. > > > 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? There are many risks... Some other suid utility could shell out to use bdes, and due to an exploit in bdes gain root... All code on the system has risk, even if it isn't used... In fact, in some ways, unused code has greater risk as it isn't audited or tested as much as other code... > > > 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. Can you guarantee that this code will? Are you willing to bet your life on this code always functioning w/o any security issues (algorithm not withstanding)... > Deny insecure crypto algorithm? Why don't force to use stong crypto I plan on removing some insecure algorithms from OpenCrypto... If you want to know more, go read the archives on -security about it.. > algorithm in all places (force disk, swap and memory encryption)? Talking about this, I would like to turn on always on encryption for swap, but realize that for some embedded systems, it'll be a hardship.. > Deny unencrypted network connection? I'd like that... turn in tcpinc... Always run https... have http only ever redirect to https, though there are issues w/ that... But sounds like I should deny you ssh, since you seem to think that unencrypted connections are perfectly fine... > Deny unencrypted arhive? At least unauthenticated archive, sure... Too many distributions out there are unauthenticated and pose a security risk... As Xin Li, who is currently acting SO, has spoken and agreed that it should be moved to ports, I'll stop responding to this discussion... We've spent more time talking about this utility, than people have used or even looked at it's code in the last 10 years... If you don't like this decission, bring it up w/ Xin Li or someone else or fork FreeBSD... > > > > > 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."