Date: Tue, 10 Feb 2015 22:13:29 +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: <20150210191329.GL3698@zxy.spb.ru> In-Reply-To: <20150210190132.GB1953@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150210191329.GL3698>