Re: Will OpenSSL 1.1l be back ported to 2021Q2?

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 09/01, Greg Troxel wrote:
> 
> "Morgan, Iain (ARC-TN)[InuTeq, LLC]" <iain.morgan%nasa.gov@localhost> writes:
> 
> > Not having seen any response, I assume that this question was overlooked.
> 
> I would assume instead that a lot of people saw it, thought that a
> pullup, if done with no stability issues, would probably be good, that
> doing so would be a lot of work, that Q2 has only about 30 days left,
> and that they personally weren't going to do this.

Hi, Greg!

This is sad, IMO.  An open-source project has certain responsibilities
when it comes to security.  NetBSD, for example, has a security team,
and the security team addresses discovered security vulnerabilities
for the supported branches and releases security advisories.  It seems
irresponsible for the pkgsrc project to say that there are only 30 days
left in Q2, it's a pain to fix it, so we won't.

30 days is about a third of the life of the branch; that doesn't seem
insignificant to me.

In the security section of

  https://www.pkgsrc.org/

it says

  The vulnerabilities database and package EOL database are both signed
  with the pkgsrc-security GPG key.

It seems inconsistent to me that the project would go to the trouble of
signing the databases and at the same time leave a package like OpenSSL
vulnerable on the stable branch for a third of the branch's lifetime.

If this is the pkgsrc project's policy, though, I think at the least
it should be made clear.  This kind of information is very important
when a user is deciding which branch to follow: stable or current.  For
example, in the "Getting pkgsrc for the first time" section of the guide
at

  https://www.netbsd.org/docs/pkgsrc/getting.html

it says

  Before you download any pkgsrc files, you should decide whether you
  want the current branch or the stable branch.  The latter is forked on
  a quarterly basis from the current branch and only gets modified for
  security updates.

I think that should be changed to

  Before you download any pkgsrc files, you should decide whether you
  want the current branch or the stable branch.  The latter is forked
  on a quarterly basis from the current branch and only gets modified
  for security updates.  Due to a lack of project funding and developer
  time, the pkgsrc stable branch does not always get modified for
  security updates, so if you desire the most secure branch, the stable
  branch is not suitable; the current branch would be the better choice.
  On the other hand, the stable branch normally has no breaking changes,
  while the current branch naturally must have breaking changes from
  time to time as packages are updated to their latest versions.

> > Although OpenSSL 1.1l appears in pkgsrc HEAD, it doesn't look like it
> > has been backported to the 2021Q2 release. Since this update addresses
> > a security issue which is identified as High by the OpenSSL
> > developers, please backport it to the current release.
> 
> You can certainly "cvs up -A" in security/openssl and "make replace".
> That should get you the fixes, and also any resulting stability issues.
> You can then let us know how that went; it would be helpful for others
> doing the same, as well as a data point for anyone contemplating doing a
> pullup (which is required to be ABI stable).
> 
> I'm curious what plaatform you are using it on, and if you're doing
> binary builds yourself.
> 
> Perhaps TNF should offer support contracts for this sort of thing, but
> they'd probaly have to be priced high enough to hire 0.5 FTE.  Even if
> there were no guarantees, phrasing it that way might make it easier for
> entities like NASA to provide funding.  I find it really unfortunate how
> donating to open source code that's being used seems much harder in a
> corporate environment than paying for proprietary software licenses.

This has nothing to do with NASA or any other organization that might be
using pkgsrc; it's a responsibility of the pkgsrc project to communicate
clearly about what it provides on the supported branches so that users,
regardless of whether they're an individual or an organization, can make
an informed decision about which branch to follow.  I think that's what
has broken down in this case; it wasn't clear what the pkgsrc project
provides on the stable branch.

In terms of monetizing an open-source project, I agree with you that
it's unfortunate that donating to an open-source project is harder
for an organization than paying for a license.  I think the reason is
obvious: one is actively being generous (i.e., choosing to give money
away when it's not required), whereas the other is operating legally.
It's very natural to me that an organization would be willing to pay for
a license and at the same time not go out of its way to make a donation
to an open-source project.  Who would organize the donation at the
organization?  Who would decide which projects to donate to and which
ones not to?  Who would decide how much to donate?  Who would justify
this cash outflow to the board of directors?  It's a very different
problem from "we think this software fits our needs the best, it costs
this much, and we think that it's a financially responsible decision to
pay for the license to achieve this."

Kind regards,

Lewis