Re: bsdcpio and bsdtar installed by default

[Alistair Crooks <agc%pkgsrc.org@localhost>]

[I left off replying to your message for a while to let you calm down.
Can we leave the hysteria off any replies, please? Thanks - agc]

On Tue, Jun 24, 2008 at 06:03:17AM +0200, Tonnerre Lombard wrote:
> Salut, Alistair,
> 
> On Mon, 23 Jun 2008 13:03:33 +0100, Alistair Crooks wrote:
> > In software engineering (as opposed to the "rewrite it because I can't
> > understand it" clueless lemming spree that is being espoused in some
> > places), most errors occur in places where the code was last changed.
> 
> That may well be but is not an accurate assumption and certainly
> doesn't contribute to our debate.

Hmmm, not sure what you dispute here, but it's all true, whether you like it
or not. Oh, nice try at dispute by hand-waving, though.
 
> > Does libarchive have a comprehensive set of regression tests to make
> > sure that no bugs have crept back in? Or a test suite at all?
> 
> Yes. Please have a look at the "test" subdirectory of the code.

Cool. A good start.
 
> > I would certainly hope that the bugs had been fixed upstream.  But
> > that doesn't alter the fact that there were exploitable bugs, and so
> > my confidence in this software is less than it was.  Not just
> > exploitable bugs - "potentially to even execute arbitrary code" bugs.
> 
> This is pure nonsense. Following this argumentation, we would need to
> pull most of our programs from the repository. At least a large
> fraction of them already had exploitable security problems, and many of
> them even had more than 3.

I've been around a while, and have learned that one gains a reputation as
a writer of software over a long time. And that reputation is lost over a
very short period of time.

Now you can jump up and down as much as you like, and try to rubbish
everything that people say to you, but please try to consider this
rationally.

Robust software in the face of attackers is not some form of league table.
It is a binary thing - either software is secure, or it's not. The uses
of this software will primarily be extracting archives as root. For that,
I want software I can trust. Up until this point, all we have heard from
the people who want to use libarchive was "FreeBSD use it, so it's good".
We heard nothing of exploitable bugs, including arbitrary code execution.
I mention it, and you attempt to discredit what I say with the emotive
"This is pure nonsense".

Get a grip.
 
> libarchive is relatively young code, the project appears to have
> started in February 2004. But that doesn't mean we have to consider it
> written by morons simply because it has had a couple of security
> problems.

I don't consider it written by moron or genius grade people. I have
no view on the people who wrote it. I have a view on the software
itself, and the people who are trying to force this upon me without
telling me the full facts.
 
> Also, do you know how various different security problems can lead to
> arbitrary code execution? A lot of people have invested a lot of effort
> in making it possible to execute code in stack overflows, heap
> overflows, re-used signal handler vulnerabilities, double frees,
> special types of race conditions and various other occasions. I would
> find it presumptuous to claim that one has never written code which was
> prone to one of these.

That is a great consolation to the person whose system was ruined by
software which exploits that code. Neither am I making such a claim
that exploitable code has never been written. I'm trying to take steps
which protect NetBSD, and pkgsrc. Please don't try to lecture me on
that.
 
> But as easily as they might have slipped in they are fixed. Looking
> over the code contained in the libarchive repository, it doesn't seem
> to be of such an exceptionally low quality that we should consider it
> to be full of security holes even after those you mentioned have been
> fixed. Like I said, it doesn't look like a systematic problem to me.

That's good news - once again, why weren't we told this up front?
 
> > Please remind me again when this code was audited, and by whom.
> 
> Tim Kientzle himself has done some auditing of the code, and Colin
> Percival has done the same auditing producing the 3 CVEs you found.
> 
> On the other hand, we depend on GNU Tar and pax heavily for our code.
> Are you sure these have been audited to the appropriate level?
> Especially our pax appears to be so unimportant that it is not even
> mentioned as an audit target. I'm not sure this is such a better base
> for security assumptions.

We haven't depended on GNU tar for a long, long time, so please don't
try to ignite the fires by saying that kind of thing.

As for pax - that's been audited by numerous people over time, so that
one's not going to wash either. It used to be maintained by the NetBSD
security-officer, for a start.

So please, let's get rid of the hyperbole, and focus on the matter in
hand. You may be surprised to find that I'm not against having this
software completely - but I do want to know why we need it yesterday,
where all these archives are coming from that are unreadable, and I
want to be able to express myself on this project's mailing lists
without someone telling me that I'm talking pure nonsense.

If we can't have rational discussion, then forget it, and forget
libarchive.

Thanks,
Alistair