Date: Tue, 10 Feb 2015 23:39:59 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: John-Mark Gurney <jmg@funkthat.com> Cc: arch@freebsd.org Subject: Re: removing bdes.. Message-ID: <20150210203959.GN3698@zxy.spb.ru> In-Reply-To: <20150210194922.GF1953@funkthat.com> References: <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> <20150210194922.GF1953@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 10, 2015 at 11:49:22AM -0800, John-Mark Gurney wrote:
> 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
PCI-DSS is as airport security -- banned clear water and cell phones.
> algorithms are an issue.... If this had been 3DES, I wouldn't be
> propsing to remove it..
Insecure algorithms are an issue if this algorithms are standart
service.
> > > > 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
bdes have exploit? or have bad code (mktmp. fgets)?
openssl (with strong encryption algorithms) full of known expoit.
> 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...
You point "this is unused code and prefer to remove" or "weak encryption must be banned"?
> > > > 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..
This is break compatibility? As I know some insecure algorithms need
for LDAP and PAP/CHAP/NTLM.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150210203959.GN3698>