"Replicated similar functionality" is indeed a security issue.

It's a security problem, sometimes - the whole buffer overflow being
replicated everywhere thing, for example.

But replication also gives robustness in the face of failure, so it
can also be a security asset. Still an issue, just not a security
problem. (Or, a problem, but for people trying to defeat security.)

That said, replication is intrinsic in the nature of computer
programming. Patterns are useful and, therefore, replicated. But even
more than that we start with a [relatively] small set of primitive
instructions and build up from there.

Unnecessary replication, on the other hand, is indeed something that's
not so good.

But getting rid of all replication is an impossible rabbit hole that
you really do not want to go down.

Thanks,

-- 
Raul


On Fri, Aug 25, 2017 at 8:13 PM,  <leo_...@volny.cz> wrote:
> [now I'm subscribed, might as well respond to some recent stuff from the
>  archives...]
>
> 321.geo...@gmail.com wrote:
>> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
>> process. It seems that if the logic from these programs were duplicated
>> the pledge in mandocdb.c could be further restricted and even not bother
>> with forking.
>>
>> Would such a change be pointless churn however? Both cmp(1) and rm(1)
>> are simple programs and are pledge'd themselves. Not to mention the
>> creation of the mandoc database is in itself a short lived process.
>>
>> To be clear I'm not proposing a change (indeed I have no diff) but
>> rather I am simply curious to the opinion of others in the OpenBSD
>> community.
>
> Okay, in that case, please forgive me if I go off on a little bit of a
> tangent.
>
> I've used UNIX for quite a while now. Not being satisfied with just
> using anything, I've (not deeply) poked at the luserspace internals
> quite a bit over time.
>
> Almost each time I read the source code of any UNIX program, whether it
> came w/ the system or not, I find duplicated functionality.
>
> As I see it, this is not just inefficient, but also a huge security
> issue: if the same operation is stated differently in many different
> places, how can we make sure that we squash all instances of a
> particular bad habit or bug?
>
> The only real solution that I've come up w/ over time is to put the
> actual logic in libraries and leave the programs to be luser interfaces
> to that logic.
>
> Perhaps something not quite so extreme is needed. I wouldn't know.
>
> It would certainly make it easier to execute the suggestion you make in
> the first paragraph of your message.
>
>         --schaafuit.
>
> [so, the spacing issue does not appear today, but the subject lines
>  are fscked. grrrr!]
>

Reply via email to