Ken Moffat via blfs-support
2018-12-04 16:26:37 UTC
This is a follow-up, with changed subject and method, to
http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-December/080534.html
Some of us install a _lot_ of perl modules, and those go in
/usr/lib/perl5/site_perl/5.mm.ss (where mm is the minor version and
ss is what perl calls the subversion - the point version in more
general terms).
For the book, biber is probably the only package which adds a vast
number of modules, but outside the book people may have many perl
modules for specific reasons.
When a newer sub-version of perl adds security fixes, some of us
think that upgrading is important. But when the existing extra
modules are in e.g. site_perl-5.28.0 and the new version is 5.28.1 I
assume they will no-longer be found or usable.
My previous post had a patch to add the changes from 5.28.1 to
5.28.0, followed by rebuilding 5.28.0. That worked, but when I
looked at older systems which I try to keep usable the version of
perl in LFS-8.2 was 5.26.1. There have been two point releases of
5.26 since then, each with CVE fixes, and my attempts to create a
patch with the changes failed - several tests, both in porting/ and
for the new fixes, failed.
In the end, I have come up with a simpler process, although this is
still a hack.
1. In patchlevel.h change the PERL_SUBVERSION back to the running
version (e.g. on 5.26 the latest fixes are 5.26.3 and my running
version for BLFS-8.3 was 5.26.1, so I changed it to 1).
2. In lib/B/Op_private.pm change the VERSION. This has the form
5.0mm0ss so I changed it from 5.026003 to 5.026001.
3. Using the installed old perl, run Porting/makemeta : that updates
the version strings in META.json and META.yml to match the running
perl.
4. Check that the VERSION in lib/B/Op_private.pm matches the
versions in the META files.
Item 1 controls the name of perl-5.mm.s which will be installed, and
the version in /usr/lib/perl5/.
Items 2 and 3 ensure that the tests should give the same results as
when you originally built perl in LFS.
Rebuild following the LFS instructions from when you originally
installed, run the tests, check them, and update.
This has now been tested using 5.28.1 as 5.28.0, 5.26.3 as both
5.26.1 and 5.26.0, and 5.24.4 as 5.24.1.
The latter was for an old LFS-8.0 system I had lying around.
Unfortunately, 5.24 is EOL and has not been updated for the latest
CVE-18311..4 fixes (but there were several CVE fixes after 5.24.1
which are in .4).
For CVE-2018-18311..4 the fixes apply for seveal previous versions.
Debian are using 5.20 on one release, but they had not updated when
I looked. Ubuntu are using 5.22 on a rleease and have backported
these. Unfortunately, not all of their patches applied to 5.24, and
my initial attempt to manually fix them up caused at least one test
to spew out a message which was garbage but recognizable from my
attempt to put a hunk in manually. So, for 5.24 I have not at the
moment fixed the latest vulnerabilities - that system was not being
maintained, so no worries.
Hopefully everyone is using more recent versions of perl on their
LFS systems.
ĸen
http://lists.linuxfromscratch.org/pipermail/blfs-support/2018-December/080534.html
Some of us install a _lot_ of perl modules, and those go in
/usr/lib/perl5/site_perl/5.mm.ss (where mm is the minor version and
ss is what perl calls the subversion - the point version in more
general terms).
For the book, biber is probably the only package which adds a vast
number of modules, but outside the book people may have many perl
modules for specific reasons.
When a newer sub-version of perl adds security fixes, some of us
think that upgrading is important. But when the existing extra
modules are in e.g. site_perl-5.28.0 and the new version is 5.28.1 I
assume they will no-longer be found or usable.
My previous post had a patch to add the changes from 5.28.1 to
5.28.0, followed by rebuilding 5.28.0. That worked, but when I
looked at older systems which I try to keep usable the version of
perl in LFS-8.2 was 5.26.1. There have been two point releases of
5.26 since then, each with CVE fixes, and my attempts to create a
patch with the changes failed - several tests, both in porting/ and
for the new fixes, failed.
In the end, I have come up with a simpler process, although this is
still a hack.
1. In patchlevel.h change the PERL_SUBVERSION back to the running
version (e.g. on 5.26 the latest fixes are 5.26.3 and my running
version for BLFS-8.3 was 5.26.1, so I changed it to 1).
2. In lib/B/Op_private.pm change the VERSION. This has the form
5.0mm0ss so I changed it from 5.026003 to 5.026001.
3. Using the installed old perl, run Porting/makemeta : that updates
the version strings in META.json and META.yml to match the running
perl.
4. Check that the VERSION in lib/B/Op_private.pm matches the
versions in the META files.
Item 1 controls the name of perl-5.mm.s which will be installed, and
the version in /usr/lib/perl5/.
Items 2 and 3 ensure that the tests should give the same results as
when you originally built perl in LFS.
Rebuild following the LFS instructions from when you originally
installed, run the tests, check them, and update.
This has now been tested using 5.28.1 as 5.28.0, 5.26.3 as both
5.26.1 and 5.26.0, and 5.24.4 as 5.24.1.
The latter was for an old LFS-8.0 system I had lying around.
Unfortunately, 5.24 is EOL and has not been updated for the latest
CVE-18311..4 fixes (but there were several CVE fixes after 5.24.1
which are in .4).
For CVE-2018-18311..4 the fixes apply for seveal previous versions.
Debian are using 5.20 on one release, but they had not updated when
I looked. Ubuntu are using 5.22 on a rleease and have backported
these. Unfortunately, not all of their patches applied to 5.24, and
my initial attempt to manually fix them up caused at least one test
to spew out a message which was garbage but recognizable from my
attempt to put a hunk in manually. So, for 5.24 I have not at the
moment fixed the latest vulnerabilities - that system was not being
maintained, so no worries.
Hopefully everyone is using more recent versions of perl on their
LFS systems.
ĸen
--
I'm saving up 22 shillings and 10 pence (almost a pound!) per week to
buy an ARM-13.
http://www.antipope.org/charlie/blog-static/2018/11/brexit-means-brexit.html
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
I'm saving up 22 shillings and 10 pence (almost a pound!) per week to
buy an ARM-13.
http://www.antipope.org/charlie/blog-static/2018/11/brexit-means-brexit.html
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page