removing bdes..

[Slawa Olhovchenkov]

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.