pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [EXTERNAL] Re: Will OpenSSL 1.1l be back ported to 2021Q2?
I have to admit that I agree with the general sentiments stated below. I understnad that a package like Openssl affects a large number of other packages, and thus warrants a reasonable amount of testing to avoid adverse impact. That is, impact beyond that due to the vlunerability itself. I also understand that as we approach the end of a given releases lifecycle, attention is focused on preparing and testing the upcoming release.
With regards to this specific issue, the bmake replace after backporting the OpenSSL update went smoothely for me. As I noted earlier, I've tested several commands that link against the OpenSSL libraries and found no issues. As a further test, I removed the OpenSSL 1.1k build and all of the packages that depended on it from a separate 2021Q2 install and then rebuilt OpenSSL and all of the previously removed packages. Again, there was not issue.
I've also done a similar test as above, but with the addition of doing "bmake test" as well. Unfortunately, the results from that seem inconclusive. I don't generally run "bmake test" so I'm not sure what are expected failures.
Thus far, none of the failures appear to be related to OpenSSL. Most appear to be due to not finding the soruce tarball -- even though the tarball should already be present in the distfiles directory. Some Python 3.9 modules also fail to "project_url" not being supported by setuptools.
I'd like to thank those who have contributed to this thread and offered suggestions. I've certainly got some things to think about before my next production pkgsrc build.
--
Iain
On 9/7/21, 13:32, "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> wrote:
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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pkgsrc.org%2F&data=04%7C01%7Ciain.morgan%40nasa.gov%7Cbd40fa7f5da744cb39cf08d9723eaaa2%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637666435746164592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=73%2FdUudKylk2eIN6F78jvhNPxkrhkAFe08SFrwuU2%2F4%3D&reserved=0
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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.netbsd.org%2Fdocs%2Fpkgsrc%2Fgetting.html&data=04%7C01%7Ciain.morgan%40nasa.gov%7Cbd40fa7f5da744cb39cf08d9723eaaa2%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637666435746164592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ust%2FbT8vXAFUm6BZoybMHYqxxwo4Y0ketlKl25Zapys%3D&reserved=0
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
Home |
Main Index |
Thread Index |
Old Index