[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Will OpenSSL 1.1l be back ported to 2021Q2?
On 09/07, Greg Troxel wrote:
> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> > I didn't read the CVE, but I assumed that since Iain said it was given
> > a "high rating," it would affect a lot of people. Anyway, even if it
> > wouldn't affect many people, I would still think it should be addressed,
> > but as I said above, if upstream has a problem with making patch
> > releases that break ABI backward compatibility, that's a very difficult
> > situation, and I don't see a good way to deal with that, and I don't
> > think the responsibility should fall on pkgsrc developers.
> There's an important point here that your language is mischaracterizing.
> Pkgsrc the project imposes an expectation of people that work within it
> that they will not make changes that cause serious breakage. We do
> *not* have any imposed expecatations that anyone will do any particular
> work to achieve any goals. However, we have a history where this
> frequently happens.
> So pkgsrc does not have a responsibility to users to do updates, and in
> particular no individual has a responsibility to TNF of any user of
> pkgsrc to take any affirmative step. I see assertions of such
> responsibilty as contrary to Free Software norms and dangerous.
> pkgsrc is Free Software, without warranty. If a user of software wants
> to have their expecttations met in a guaranteed manner, they should hire
> someone to do that for them, and that's outside the scope of this list
> and the project.
We may just disagree; I don't know. I think you're saying that the
pkgsrc project absolves itself of any responsibility in terms of
security, and that if a user wishes for anyone to take responsibility
for security, they should pay someone to do that.
That is inconsistent with my view that any software project, by virtue
of existing, takes on a good-faith responsibility for security unless it
explicitly states security as a non-goal (e.g., designed to be deployed
on a trusted network and dealing only with trusted data). I feel like
this is a reasonable and common open-source software responsibility. It
seems to me that with most any project, the project is interested in
receiving vulnerability reports and in addressing them quickly. If not,
then I don't think the software lasts very long, or it becomes known
that the project developers are not interested in security, and users
can choose whether they're OK with that.
Just looking at a few examples, consider NetBSD
If you read those pages, you won't see any notion of "if you want any
kind of statement of our intention to address security vulnerabilities,
you should give that up and pay someone for that; we don't provide
any such thing." Instead, the impression I get is one of developers
who consider security to be important and who intend to address any
vulnerabilities reported against their project. In other words, I
don't see an attitude consistent with the view you shared that you "see
assertions of such responsibility as contrary to Free Software norms and
Main Index |
Thread Index |