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

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

On 09/08, Greg Troxel wrote:
> 
> There is a huge gap between:
> 
>   a project (the corporation) and the volunteers have a track record of
>   trying to work on things, and signal an intent to do so, resources
>   permitting
> 
> and
> 
>   they have a duty to people that use the code
> 
> and the difference is basically the concept of liability.  The license
> of NetBSD disclaims liability, and people who choose to use it do not
> have a basis to claim harm because TNF didn't do some update in a time
> frame they wanted.  This is a huge point which cannot be overstated and
> should not be ignored.
> 
> This is just the way it is everywhere, despite differences in wording.

Agreed on all above.
 
> You are basically saying that TNF and the TNF volunteers have some sort
> of duty to meet some not-clearly-stated set of expectations, and made
> the assertion that TNF not somehow processing an openssl pullup (from an
> upstream that did not release a patch release of the previous API/ABI
> stable) is a breach of duty to you and others.

This is where a miscommunication has occurred, I think.  I'm not making
any such claim of liability.  I'm strictly speaking of the first thing
you listed above: the concept of developers making a good-faith effort
and taking responsibility for security in their project.

To me, it's not taking responsibility for security in pkgsrc for the
project to say that there are only 30 days left on the stable branch
(which is a third of the branch lifetime), it's a pain to fix, so we
won't fix it.  However, after I said that, Joerg pointed out that the
OpenSSL project is notorious for breaking ABI backward compatibility in
patch releases.  IMO, that puts an undue burden on pkgsrc developers,
so I changed my stance on the OpenSSL CVE situation and said that given
this, I no longer think that it's the responsibility of the pkgsrc
project to update OpenSSL in this case.

I know it's a lot of work, and I really appreciate all the work that
is done by the pkgsrc developers, and I think it's reasonable for the
pkgsrc project to take responsibility for security on the stable branch
only when there's a responsible upstream that can make a minimal patch
available, or a patch release, to fix the security vulnerability, both
without breaking API/ABI backward compatibility.

Now, of course, that's all just my opinion.  What I then went on to say
is that if the pkgsrc project doesn't agree with that, I thought it
would be good to make the pkgsrc project's intentions for what a user
can expect on the stable branch more clear because I thought there might
be other users like me who thought the statement in the pkgsrc guide
that said the stable branch "only gets modified for security updates"
meant that the pkgsrc project was committed to updating it for security
updates, not just sometimes.  I also said that this would help any user
to make an informed decision about which branch, current or stable,
would fit their needs the best.

> From having worked on pkgsrc, it's obvious that there is an infinite
> amount of work to do, and that only some of it hapens.  And only so many
> people volunteer, and they fix what matters to them.  That's not really
> a problem -- just how the world is.
> 
> To be logically consistent, you should complain to OpenSSL that they did
> not release a micro release that is basically the last version with
> *only* security patches.  (I'm not complaining about that -- just
> pointing out that without that, managing openssl is harder.)

As I said above, I didn't know that OpenSSL had a track record of
breaking ABI backward compatibility in patch releases until Joerg
pointed that out, so I've now changed my opinion on that: I think it
is irresponsible of the OpenSSL project to operate that way and do not
consider it the pkgsrc project's responsibility to put forth effort to
compensate for that.
 
> What I object to is the assertion that TNF has a duty to you to meet
> some performance standard in security pullups, and the assertion that
> people are entitled to some level of service.  It's dangerous because
> the liability landscape is troubling in general, and statements that
> there is a duty muddy the waters.

I said it above, but again, I don't think I ever said anything about
liability.  What I'm talking about is what I consider to be responsible
software development.

Lewis