Date: Tue, 10 Feb 2015 11:49:22 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: arch@freebsd.org Subject: Re: removing bdes.. Message-ID: <20150210194922.GF1953@funkthat.com> In-Reply-To: <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> <20150210191329.GL3698@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150210194922.GF1953>