Subject: Re: binary packages with vulnerabilities removed from ftp - a bad
To: Todd Vierling <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 01/31/2005 09:57:28
On Mon, 31 Jan 2005, Todd Vierling wrote:
> On Sun, 30 Jan 2005, Frederick Bruckman wrote:
>>> If the @blddep is not there (maybe because it was rm'd for sekurity
>>> reasons) and an updated @dep is available, that can be used just fine.
>> How could you know that the ABI of the @blddep library didn't change?
> Because we're supposed to bump the BUILDLINK_RECOMMENDED if it does, and the
> bulk build should rebuild it. This doesn't help binary packages much, but
> until we have a soname-based provides/requires type of thing, it's the best
> we can do.
And how would bumping the <anything> in pkgsrc affect the *existing*
binary packages? This is the "open-ended dependencies" problem, again.
This discussion *is* about binary packages, nothing else. I have
proposed no changes to "pkgsrc". The problem, again, is that removing
packages from the collection on the server for security aspersions
breaks other packages, which are left on the server for some victim
to attempt to install.
> Please *don't* remove anything based solely on @blddep. That obviates the
> whole point of dewey dependencies.
I only said that would be the easiest way, not the best. It would
still be an improvement over the existing state of affairs, which
leaves many broken packages on the server. At least, you could see
that they were missing without having to attempt to install them. It
would remove no package that isn't already non-installable.
What do you think of my second idea, to move them to purgatory until
some committer verifies that their requirement is, indeed, fulfilled
by a newer package?