Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2022-07-14 22:08:09
|
Thanks Lonnie (and Michael)
We will give that a go.
Regards
Michael Knill
On 15/7/2022, 6:44 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael and Matthew,
This error occurs while building the toolchain (crosstool-ng), there are a couple ways to fix this.
1) The URL for 'isl' has moved, this [1] is the fix for upstream crosstool-ng.
So, before you do a "./ct-ng build" edit the "packages/isl/package.desc" file and change the line:
-- from --
mirrors='http://isl.gforge.inria.fr'
-- to --
mirrors='https://libisl.sourceforge.io'
--
Then perform "./ct-ng build".
Please let us know if this works for you.
[1] https://github.com/crosstool-ng/crosstool-ng/commit/cfb7d07ae1e0ef4dbf14f40a5744d1abd382d000
2) Alternatively, we have a copy of the crosstool-ng "tarballs" directory.
So, before you do a "./ct-ng build"
--
cd ~/source-control/crosstool-ng-1.24.0/.build
curl -LO https://astlinux-project.org/files/crosstool-ng-1.24.0-tarballs.tar.gz
tar xzvf crosstool-ng-1.24.0-tarballs.tar.gz
rm crosstool-ng-1.24.0-tarballs.tar.gz
cd ~/source-control/crosstool-ng-1.24.0
--
Then perform "./ct-ng build".
Either "fix" should work.
Lonnie
> On Jul 14, 2022, at 12:55 AM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> Matthew is trying to build our own image and has come up with this issue.
> Any help would be appreciated.
>
> Regards
> Michael Knill
>
> From: Matthew Knill <mat...@ip...>
> Date: Thursday, 14 July 2022 at 3:42 pm
> To: Michael Knill <mic...@ip...>
> Subject: Error building Astlinux image
>
> After following the doco exactly, I got to the `./ct-ng build` in the [Crosstool-NG](https://raw.githubusercontent.com/astlinux-project/astlinux/master/crosstool-ng-src/README) instructions which yielded the following error:
> ```
> [INFO ] Performing some trivial sanity checks
> [INFO ] Build started 20220714.150937
> [INFO ] Building environment variables
> [INFO ] =================================================================
> [INFO ] Retrieving needed toolchain components' tarballs
> [ERROR] isl: download failed
...
>
> Regards,
> Matthew Knill
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2022-07-14 20:44:16
|
Hi Michael and Matthew, This error occurs while building the toolchain (crosstool-ng), there are a couple ways to fix this. 1) The URL for 'isl' has moved, this [1] is the fix for upstream crosstool-ng. So, before you do a "./ct-ng build" edit the "packages/isl/package.desc" file and change the line: -- from -- mirrors='http://isl.gforge.inria.fr' -- to -- mirrors='https://libisl.sourceforge.io' -- Then perform "./ct-ng build". Please let us know if this works for you. [1] https://github.com/crosstool-ng/crosstool-ng/commit/cfb7d07ae1e0ef4dbf14f40a5744d1abd382d000 2) Alternatively, we have a copy of the crosstool-ng "tarballs" directory. So, before you do a "./ct-ng build" -- cd ~/source-control/crosstool-ng-1.24.0/.build curl -LO https://astlinux-project.org/files/crosstool-ng-1.24.0-tarballs.tar.gz tar xzvf crosstool-ng-1.24.0-tarballs.tar.gz rm crosstool-ng-1.24.0-tarballs.tar.gz cd ~/source-control/crosstool-ng-1.24.0 -- Then perform "./ct-ng build". Either "fix" should work. Lonnie > On Jul 14, 2022, at 12:55 AM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > Matthew is trying to build our own image and has come up with this issue. > Any help would be appreciated. > > Regards > Michael Knill > > From: Matthew Knill <mat...@ip...> > Date: Thursday, 14 July 2022 at 3:42 pm > To: Michael Knill <mic...@ip...> > Subject: Error building Astlinux image > > After following the doco exactly, I got to the `./ct-ng build` in the [Crosstool-NG](https://raw.githubusercontent.com/astlinux-project/astlinux/master/crosstool-ng-src/README) instructions which yielded the following error: > ``` > [INFO ] Performing some trivial sanity checks > [INFO ] Build started 20220714.150937 > [INFO ] Building environment variables > [INFO ] ================================================================= > [INFO ] Retrieving needed toolchain components' tarballs > [ERROR] isl: download failed ... > > Regards, > Matthew Knill > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <li...@mk...> - 2022-07-14 09:47:01
|
> Am 14.07.2022 um 07:55 schrieb Michael Knill <mic...@ip...>:
>
> [INFO ] Retrieving needed toolchain components' tarballs
> [ERROR] isl: download failed
It looks like a needed component ("isl") couldn't be downloaded.
Server down, DNS, etc.
Michael
http://www.mksolutions.info
|
|
From: Michael K. <mic...@ip...> - 2022-07-14 05:55:19
|
Hi Devs Matthew is trying to build our own image and has come up with this issue. Any help would be appreciated. Regards Michael Knill From: Matthew Knill <mat...@ip...> Date: Thursday, 14 July 2022 at 3:42 pm To: Michael Knill <mic...@ip...> Subject: Error building Astlinux image After following the doco exactly, I got to the `./ct-ng build` in the [Crosstool-NG](https://raw.githubusercontent.com/astlinux-project/astlinux/master/crosstool-ng-src/README) instructions which yielded the following error: ``` [INFO ] Performing some trivial sanity checks [INFO ] Build started 20220714.150937 [INFO ] Building environment variables [INFO ] ================================================================= [INFO ] Retrieving needed toolchain components' tarballs [ERROR] isl: download failed [ERROR] [ERROR] >> [ERROR] >> Build failed in step 'Retrieving needed toolchain components' tarballs' [ERROR] >> called in step '(top-level)' [ERROR] >> [ERROR] >> Error happened in: CT_Abort[scripts/functions@487] [ERROR] >> called from: CT_DoFetch[scripts/functions@2103] [ERROR] >> called from: CT_PackageRun[scripts/functions@2063] [ERROR] >> called from: CT_Fetch[scripts/functions@2174] [ERROR] >> called from: do_isl_get[scripts/build/companion_libs/121-isl.sh@16] [ERROR] >> called from: do_companion_libs_get[scripts/build/companion_libs.sh@15] [ERROR] >> called from: main[scripts/crosstool-NG.sh@648] [ERROR] >> [ERROR] >> For more info on this error, look at the file: 'build.log' [ERROR] >> There is a list of known issues, some with workarounds, in: [ERROR] >> 'docs/manual/B_Known_issues.md' [ERROR] >> [ERROR] >> If you feel this is a bug in crosstool-NG, report it at: [ERROR] >> https://github.com/crosstool-ng/crosstool-ng/issues/ [ERROR] >> [ERROR] >> Make sure your report includes all the information pertinent to this issue. [ERROR] >> Read the bug reporting guidelines here: [ERROR] >> http://crosstool-ng.github.io/support/ [ERROR] [ERROR] (elapsed: 4:01.54) [04:02] / make: *** [ct-ng:261: build] Error 1 ``` Regards, Matthew Knill |
|
From: Michael K. <mic...@ip...> - 2022-06-26 23:04:14
|
Thanks Lonnie.
Regards
Michael Knill
On 27/6/2022, 1:46 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> Not sure if you want to add to Astlinux?
The past has proven that the Runnix URL should be automatic and not a user configurable URL that may become stale in the future. The "upgrade-RUNNIX-image" script should contain the default URL, not webgui-prefs.txt.
So, no to 'system_runnix_repository_url' in the standard AstLinux.
But if you feel you need your own Runnix repo, sure ... the beauty of Open Source Software.
Lonnie
> On Jun 25, 2022, at 11:59 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> Replied to dev list from user list.
>
> I'm going to add my own Runnix repository to the System Tab which I will specify in webgui-prefs.txt using the variable 'system_runnix_repository_url'.
> Not sure if you want to add to Astlinux?
>
> Regards
> Michael Knill
>
> On 25/6/2022, 11:51 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael, (comments inline)
>
>> On Jun 24, 2022, at 8:07 PM, Michael Knill <mic...@ip...> wrote:
>>
>> A couple of questions regarding Runnix:
>> • I did a Runnix upgrade and it went to 0.6.11. Is this ok on Astlinux 1.3.10?
>
> Should be fine. Test by upgrading to Runnix 0.6.11 and "reboot" from the CLI ... it should boot AstLinux.
>
> AstLinux 1.3.10 uses x86_64 Linux 3.16.85, Runnix 0.6.11 is based on x86_64 Linux 4.19.242.
>
> Over the years we have changed Runnix from 32-bit (0.4.x) to 32-bit PAE (0.5.x) to 64-bit (0.6.x)
>
> The "upgrade-RUNNIX-image" automatically uses the proper Runnix series. You can force the Runnix repo URL, the AstLinux 1.3.10 and later default is:
> --
> upgrade-RUNNIX-image check https://astlinux-project.org/mirror/runnix6
> --
>
>
>> • Can I upgrade to a specific Runnix version or is there no point?
>
> You could with a private Runnix repo, but there is no reason to do so that I am aware of.
>
> Note that any Runnix upgrades would need to be done via the CLI, the Web Interface uses the default Runnix repo URL.
>
>
>
>> • Can I manage my own repository of Runnix?
>
> Yes, (see above) ... just as with the AstLinux repo file format, for example:
>
> -- On an external reachable HTTPS server "HOST/PATH" --
> mkdir runnix6
> cd runnix6
> curl -LO https://astlinux-project.org/mirror/runnix6/runnix-0.6.11.tar.gz
> curl -LO https://astlinux-project.org/mirror/runnix6/runnix-0.6.11.tar.gz.sha1
> curl -LO https://astlinux-project.org/mirror/runnix6/ver
> --
>
> Then in AstLinux:
> --
> upgrade-RUNNIX-image check https://HOST/PATH/runnix6
> --
>
> Adjust as desired.
>
> Lonnie
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2022-06-26 15:45:47
|
> Not sure if you want to add to Astlinux? The past has proven that the Runnix URL should be automatic and not a user configurable URL that may become stale in the future. The "upgrade-RUNNIX-image" script should contain the default URL, not webgui-prefs.txt. So, no to 'system_runnix_repository_url' in the standard AstLinux. But if you feel you need your own Runnix repo, sure ... the beauty of Open Source Software. Lonnie > On Jun 25, 2022, at 11:59 PM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > Replied to dev list from user list. > > I'm going to add my own Runnix repository to the System Tab which I will specify in webgui-prefs.txt using the variable 'system_runnix_repository_url'. > Not sure if you want to add to Astlinux? > > Regards > Michael Knill > > On 25/6/2022, 11:51 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, (comments inline) > >> On Jun 24, 2022, at 8:07 PM, Michael Knill <mic...@ip...> wrote: >> >> A couple of questions regarding Runnix: >> • I did a Runnix upgrade and it went to 0.6.11. Is this ok on Astlinux 1.3.10? > > Should be fine. Test by upgrading to Runnix 0.6.11 and "reboot" from the CLI ... it should boot AstLinux. > > AstLinux 1.3.10 uses x86_64 Linux 3.16.85, Runnix 0.6.11 is based on x86_64 Linux 4.19.242. > > Over the years we have changed Runnix from 32-bit (0.4.x) to 32-bit PAE (0.5.x) to 64-bit (0.6.x) > > The "upgrade-RUNNIX-image" automatically uses the proper Runnix series. You can force the Runnix repo URL, the AstLinux 1.3.10 and later default is: > -- > upgrade-RUNNIX-image check https://astlinux-project.org/mirror/runnix6 > -- > > >> • Can I upgrade to a specific Runnix version or is there no point? > > You could with a private Runnix repo, but there is no reason to do so that I am aware of. > > Note that any Runnix upgrades would need to be done via the CLI, the Web Interface uses the default Runnix repo URL. > > > >> • Can I manage my own repository of Runnix? > > Yes, (see above) ... just as with the AstLinux repo file format, for example: > > -- On an external reachable HTTPS server "HOST/PATH" -- > mkdir runnix6 > cd runnix6 > curl -LO https://astlinux-project.org/mirror/runnix6/runnix-0.6.11.tar.gz > curl -LO https://astlinux-project.org/mirror/runnix6/runnix-0.6.11.tar.gz.sha1 > curl -LO https://astlinux-project.org/mirror/runnix6/ver > -- > > Then in AstLinux: > -- > upgrade-RUNNIX-image check https://HOST/PATH/runnix6 > -- > > Adjust as desired. > > Lonnie > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2022-06-26 05:15:53
|
Hi Devs
Replied to dev list from user list.
I'm going to add my own Runnix repository to the System Tab which I will specify in webgui-prefs.txt using the variable 'system_runnix_repository_url'.
Not sure if you want to add to Astlinux?
Regards
Michael Knill
On 25/6/2022, 11:51 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael, (comments inline)
> On Jun 24, 2022, at 8:07 PM, Michael Knill <mic...@ip...> wrote:
>
> A couple of questions regarding Runnix:
> • I did a Runnix upgrade and it went to 0.6.11. Is this ok on Astlinux 1.3.10?
Should be fine. Test by upgrading to Runnix 0.6.11 and "reboot" from the CLI ... it should boot AstLinux.
AstLinux 1.3.10 uses x86_64 Linux 3.16.85, Runnix 0.6.11 is based on x86_64 Linux 4.19.242.
Over the years we have changed Runnix from 32-bit (0.4.x) to 32-bit PAE (0.5.x) to 64-bit (0.6.x)
The "upgrade-RUNNIX-image" automatically uses the proper Runnix series. You can force the Runnix repo URL, the AstLinux 1.3.10 and later default is:
--
upgrade-RUNNIX-image check https://astlinux-project.org/mirror/runnix6
--
> • Can I upgrade to a specific Runnix version or is there no point?
You could with a private Runnix repo, but there is no reason to do so that I am aware of.
Note that any Runnix upgrades would need to be done via the CLI, the Web Interface uses the default Runnix repo URL.
> • Can I manage my own repository of Runnix?
Yes, (see above) ... just as with the AstLinux repo file format, for example:
-- On an external reachable HTTPS server "HOST/PATH" --
mkdir runnix6
cd runnix6
curl -LO https://astlinux-project.org/mirror/runnix6/runnix-0.6.11.tar.gz
curl -LO https://astlinux-project.org/mirror/runnix6/runnix-0.6.11.tar.gz.sha1
curl -LO https://astlinux-project.org/mirror/runnix6/ver
--
Then in AstLinux:
--
upgrade-RUNNIX-image check https://HOST/PATH/runnix6
--
Adjust as desired.
Lonnie
_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
|
|
From: Lonnie A. <li...@lo...> - 2022-06-01 22:44:49
|
Announcing AstLinux Release: 1.4.6 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.6 Highlights: * Asterisk Versions: 13.38.3, 16.25.3, 18.11.3 * Add support for UEFI boot in addition to the current Legacy BIOS boot * Linux Kernel 4.19.242, security and bug fixes * igc, backport from linux-5.4.191, Intel i225 2.5-Gigabit Ethernet Network Driver * r8125, version 9.009.00, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver * RUNNIX, version bump to runnix-0.6.11 * OpenSSL, version bump to 1.1.1o, security fixes: CVE-2022-0778, CVE-2022-1292 * OpenVPN, version bump to 2.4.12, security fix: CVE-2022-0547 * libcurl (curl) version bump to 7.83.1, security fixes: many * LibreTLS, version bump to 3.5.2 * Monit, version bump to 5.32.0 * msmtp, version bump to 1.8.20 * php, version 7.2.34, add security fix: CVE-2021-21707 * smartctl (smartmontools), version bump to 7.3, drivedb.h snapshot 2022-05-10 * sqlite, version bump to 3.38.5, JSON support is now enabled * zabbix, version bump to 4.0.40 * Asterisk '13se' (stable edition) version 13.38.3 is the last Asterisk 13.x "Legacy" version, built --without-pjproject * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.6/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2022-05-15 23:00:22
|
Announcing AstLinux Pre-Release: astlinux-1.4-5492-970ef8 Key new features: -- Add support for UEFI boot in addition to the current Legacy BIOS boot. More info: https://doc.astlinux-project.org/userdoc:boot-bios-uefi ** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 4.19.242 (version bump), security and bug fixes -- RUNNIX, version bump to runnix-0.6.11, with Linux Kernel 4.19.242, add UEFI boot support as well as Legacy BIOS boot. == syslinux, version 6.03, enable EFI (64-bit) support == gnu-efi, new package, version 3.0.10 -- igc, backport from linux-5.4.191, Intel i225 2.5-Gigabit Ethernet Network Driver -- r8125, version 9.009.00, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver -- igb, version bump to 5.10.2, Intel 1.0-Gigabit Ethernet Network Driver -- OpenSSL, version bump to 1.1.1o, security fixes: CVE-2022-0778, CVE-2022-1292 -- OpenVPN, version bump to 2.4.12, security fix: CVE-2022-0547 -- WireGuard VPN, module 1.0.20211208 (no change), tools 1.0.20210914 (no change) -- libcurl (curl) version bump to 7.83.1, many security fixes -- Monit, version bump to 5.32.0 -- php, version 7.2.34, add security fix: CVE-2021-21707 -- smartctl (smartmontools), version bump to 7.3, drivedb.h snapshot 2022-05-10 -- sqlite, version bump to 3.38.5, JSON support is now enabled -- zabbix, version bump to 4.0.40 -- lighttpd/php, anonymize header version information -- Asterisk 13.38.3 ('13se' no change) Last Asterisk 13.x "Legacy" version, built --without-pjproject -- Asterisk 16.25.3 (version bump) and 18.11.3 (version bump) Security fixes: (res_stir_shaken) CVE-2022-26498, CVE-2022-26499 -- pjsip 2.10, security fixes: CVE-2022-21723, CVE-2022-23608, CVE-2021-37706 -- Complete Pre-Release ChangeLog: https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2022-04-28 21:46:00
|
Announcing AstLinux Pre-Release: astlinux-1.4-5459-c657da Key new features: -- Add support for UEFI boot in addition to the current Legacy BIOS boot. More info: https://doc.astlinux-project.org/userdoc:boot-bios-uefi ** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 4.19.236 (version bump), security and bug fixes -- RUNNIX, version bump to runnix-0.6.10, with Linux Kernel 4.19.236, add UEFI boot support as well as Legacy BIOS boot. == syslinux, version 6.03, enable EFI (64-bit) support == gnu-efi, new package, version 3.0.10 -- igc, backport from linux-5.4.191, Intel i225 2.5-Gigabit Ethernet Network Driver -- r8125, version 9.008.00, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver -- OpenSSL, version bump to 1.1.1n, security fix: CVE-2022-0778 -- OpenVPN, version bump to 2.4.12, security fix: CVE-2022-0547 -- WireGuard VPN, module 1.0.20211208 (no change), tools 1.0.20210914 (no change) -- libcurl (curl) version bump to 7.82.0 -- Monit, version bump to 5.32.0 -- php, version 7.2.34, add security fix: CVE-2021-21707 -- sqlite, version bump to 3.38.2, JSON support is now enabled -- lighttpd/php, anonymize header version information -- Asterisk 13.38.3 ('13se' no change) Last Asterisk 13.x "Legacy" version, built --without-pjproject -- Asterisk 16.25.3 (version bump) and 18.11.3 (version bump) Security fixes: (res_stir_shaken) CVE-2022-26498, CVE-2022-26499 -- pjsip 2.10, security fixes: CVE-2022-21723, CVE-2022-23608, CVE-2021-37706 -- Complete Pre-Release ChangeLog: https://astlinux-project.org/beta/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2022-04-16 23:20:02
|
Thanks Michael
Yes I probably could but as long as they have a date that's fine.
Up to my stakeholder if my date is unacceptable.
Regards
Michael Knill
On 16/4/22, 9:34 pm, "Michael Keuter" <li...@mk...> wrote:
Hi Michael,
the 2 changes were quite simple, maybe you can change them manually in your personal repo:
https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6
Add an extra line in both of the files.
https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597
Just copy the new patch file into the php package folder.
> Am 16.04.2022 um 01:38 schrieb Michael Knill <mic...@ip...>:
>
> Thanks Lonnie for the work you have done for this.
>
> My stakeholder has replied to my email and is happy with the approach taken. Yay!
> Just wondering when you are expecting 1.4.5 to be released so I can give them a remediation date.
>
> Thanks again.
>
> Regards
> Michael Knill
>
> On 15/4/22, 5:52 pm, "Michael Knill" <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> I will chat to the stakeholder.
>
> Regards
> Michael Knill
>
> On 15/4/22, 1:07 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes.
>
> We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default.
>
> We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible.
>
> With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2].
>
> Additionally, make lighttpd/php anonymize header version information [3].
>
> As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application.
>
> Lonnie
>
> [1] https://security-tracker.debian.org/tracker/source-package/php7.4
>
> [2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597
>
> [3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6
>
>
>
>> On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Lonnie
>>
>> Thanks for the info and sorry for the delayed response.
>>
>> I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them.
>> PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while.
>>
>> Regards
>> Michael Knill
>>
>> On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>>
>> Hi Michael,
>>
>> Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available?
>>
>> Looking at Debian security PHP:
>> https://security-tracker.debian.org/tracker/source-package/php7.4
>>
>> There may be one CVE fix we could backport, though Debian opted to ignore it.
>>
>> Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows.
>>
>> If there is a specific CVE of concern in PHP, please point it out.
>>
>> If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that.
>>
>> One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake.
>>
>> Again, if there is a CVE of concern, please let me know.
>>
>> Lonnie
>>
>>
>>
>>
>>> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Hi Devs
>>>
>>> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities.
>>> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted.
>>>
>>> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code.
>>> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time).
>>>
>>> Thanks all.
>>>
>>> Regards
>>>
>>> Michael Knill
>>> Managing Director
>>>
>>> D: +61 2 6189 1360
>>> P: +61 2 6140 4656
>>> E: mic...@ip...
>>> W: ipcsolutions.com.au
>>>
>>> <image001.png>
>>> Smarter Business Communications
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
Michael
http://www.mksolutions.info
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <li...@mk...> - 2022-04-16 11:34:09
|
Hi Michael, the 2 changes were quite simple, maybe you can change them manually in your personal repo: https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 Add an extra line in both of the files. https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 Just copy the new patch file into the php package folder. > Am 16.04.2022 um 01:38 schrieb Michael Knill <mic...@ip...>: > > Thanks Lonnie for the work you have done for this. > > My stakeholder has replied to my email and is happy with the approach taken. Yay! > Just wondering when you are expecting 1.4.5 to be released so I can give them a remediation date. > > Thanks again. > > Regards > Michael Knill > > On 15/4/22, 5:52 pm, "Michael Knill" <mic...@ip...> wrote: > > Thanks Lonnie > > I will chat to the stakeholder. > > Regards > Michael Knill > > On 15/4/22, 1:07 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes. > > We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default. > > We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible. > > With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2]. > > Additionally, make lighttpd/php anonymize header version information [3]. > > As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application. > > Lonnie > > [1] https://security-tracker.debian.org/tracker/source-package/php7.4 > > [2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 > > [3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 > > > >> On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Lonnie >> >> Thanks for the info and sorry for the delayed response. >> >> I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them. >> PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while. >> >> Regards >> Michael Knill >> >> On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available? >> >> Looking at Debian security PHP: >> https://security-tracker.debian.org/tracker/source-package/php7.4 >> >> There may be one CVE fix we could backport, though Debian opted to ignore it. >> >> Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows. >> >> If there is a specific CVE of concern in PHP, please point it out. >> >> If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that. >> >> One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake. >> >> Again, if there is a CVE of concern, please let me know. >> >> Lonnie >> >> >> >> >>> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Devs >>> >>> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. >>> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. >>> >>> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. >>> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). >>> >>> Thanks all. >>> >>> Regards >>> >>> Michael Knill >>> Managing Director >>> >>> D: +61 2 6189 1360 >>> P: +61 2 6140 4656 >>> E: mic...@ip... >>> W: ipcsolutions.com.au >>> >>> <image001.png> >>> Smarter Business Communications >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2022-04-16 11:24:09
|
Hi David, it might be a "good idea" to adapt to the latest buildroot stuff (e.g. hashes for the packages), but since we're already using the latest versions of those packages, what would we gain from that except "better compliance"? All packages must be changed for that, and since we use different features in AstLinux, we cannot just copy the recent buildroot packages. That's a lot of work without IMHO any real world benefit … > Am 14.04.2022 um 19:50 schrieb David Kerr <da...@ke...>: > > "PHP version not supported" should really only matter if the end customer is intending to use PHP directly themselves. As an embedded system, if PHP access is restricted to use by services on, and maintained by, that embedded system, then it shouldn't matter what version it is -- so long as critical security fixes are applied. > > That said, Astlinux has diverged a lot from buildroot over the years and is way behind. Diverged may be the wrong word. But I don't think the "keep it small" argument holds any more given available memory in router/gateway devices. I know it is a huge undertaking, but it might be a good idea to think about re-architecting to build on current buildroot following their recommendations on how to package product specific features. > > Excuse me while I hide behind my kevlar shield to protect from the incoming barrage of reasons why that is a bad idea :-) > > David. > > > On Thu, Apr 14, 2022 at 11:07 AM Lonnie Abelbeck <li...@lo...> wrote: > Hi Michael, > > I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes. > > We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default. > > We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible. > > With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2]. > > Additionally, make lighttpd/php anonymize header version information [3]. > > As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application. > > Lonnie > > [1] https://security-tracker.debian.org/tracker/source-package/php7.4 > > [2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 > > [3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 > > > > > On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote: > > > > Hi Lonnie > > > > Thanks for the info and sorry for the delayed response. > > > > I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them. > > PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while. > > > > Regards > > Michael Knill > > > > On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > > > Hi Michael, > > > > Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available? > > > > Looking at Debian security PHP: > > https://security-tracker.debian.org/tracker/source-package/php7.4 > > > > There may be one CVE fix we could backport, though Debian opted to ignore it. > > > > Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows. > > > > If there is a specific CVE of concern in PHP, please point it out. > > > > If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that. > > > > One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake. > > > > Again, if there is a CVE of concern, please let me know. > > > > Lonnie > > > > > > > > > >> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote: > >> > >> Hi Devs > >> > >> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. > >> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. > >> > >> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. > >> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). > >> > >> Thanks all. > >> > >> Regards > >> > >> Michael Knill > >> Managing Director > >> > >> D: +61 2 6189 1360 > >> P: +61 2 6140 4656 > >> E: mic...@ip... > >> W: ipcsolutions.com.au > >> > >> <image001.png> > >> Smarter Business Communications > >> > >> _______________________________________________ > >> Astlinux-devel mailing list > >> Ast...@li... > >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2022-04-16 03:30:29
|
Whoops sorry. I was looking at https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt. Thanks for that. Regards Michael Knill On 16/4/22, 10:27 am, "Lonnie Abelbeck" <li...@lo...> wrote: Michael, AstLinux 1.4.5 is the current release. [1] The 1.4.6 release won't probably be until 2022-06 or 2022-07'ish. Though pre-releases will be generated when we think there is a solid snapshot. Keep in mind the CVE fix we added to PHP was deemed not important enough for Debian to backport. Lonnie [1] https://www.astlinux-project.org/ > On Apr 15, 2022, at 6:38 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie for the work you have done for this. > > My stakeholder has replied to my email and is happy with the approach taken. Yay! > Just wondering when you are expecting 1.4.5 to be released so I can give them a remediation date. > > Thanks again. > > Regards > Michael Knill > > On 15/4/22, 5:52 pm, "Michael Knill" <mic...@ip...> wrote: > > Thanks Lonnie > > I will chat to the stakeholder. > > Regards > Michael Knill > > On 15/4/22, 1:07 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes. > > We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default. > > We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible. > > With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2]. > > Additionally, make lighttpd/php anonymize header version information [3]. > > As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application. > > Lonnie > > [1] https://security-tracker.debian.org/tracker/source-package/php7.4 > > [2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 > > [3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 > > > >> On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Lonnie >> >> Thanks for the info and sorry for the delayed response. >> >> I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them. >> PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while. >> >> Regards >> Michael Knill >> >> On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available? >> >> Looking at Debian security PHP: >> https://security-tracker.debian.org/tracker/source-package/php7.4 >> >> There may be one CVE fix we could backport, though Debian opted to ignore it. >> >> Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows. >> >> If there is a specific CVE of concern in PHP, please point it out. >> >> If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that. >> >> One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake. >> >> Again, if there is a CVE of concern, please let me know. >> >> Lonnie >> >> >> >> >>> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Devs >>> >>> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. >>> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. >>> >>> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. >>> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). >>> >>> Thanks all. >>> >>> Regards >>> >>> Michael Knill >>> Managing Director >>> >>> D: +61 2 6189 1360 >>> P: +61 2 6140 4656 >>> E: mic...@ip... >>> W: ipcsolutions.com.au >>> >>> <image001.png> >>> Smarter Business Communications >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2022-04-16 00:26:51
|
Michael, AstLinux 1.4.5 is the current release. [1] The 1.4.6 release won't probably be until 2022-06 or 2022-07'ish. Though pre-releases will be generated when we think there is a solid snapshot. Keep in mind the CVE fix we added to PHP was deemed not important enough for Debian to backport. Lonnie [1] https://www.astlinux-project.org/ > On Apr 15, 2022, at 6:38 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie for the work you have done for this. > > My stakeholder has replied to my email and is happy with the approach taken. Yay! > Just wondering when you are expecting 1.4.5 to be released so I can give them a remediation date. > > Thanks again. > > Regards > Michael Knill > > On 15/4/22, 5:52 pm, "Michael Knill" <mic...@ip...> wrote: > > Thanks Lonnie > > I will chat to the stakeholder. > > Regards > Michael Knill > > On 15/4/22, 1:07 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes. > > We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default. > > We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible. > > With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2]. > > Additionally, make lighttpd/php anonymize header version information [3]. > > As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application. > > Lonnie > > [1] https://security-tracker.debian.org/tracker/source-package/php7.4 > > [2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 > > [3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 > > > >> On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote: >> >> Hi Lonnie >> >> Thanks for the info and sorry for the delayed response. >> >> I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them. >> PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while. >> >> Regards >> Michael Knill >> >> On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Michael, >> >> Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available? >> >> Looking at Debian security PHP: >> https://security-tracker.debian.org/tracker/source-package/php7.4 >> >> There may be one CVE fix we could backport, though Debian opted to ignore it. >> >> Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows. >> >> If there is a specific CVE of concern in PHP, please point it out. >> >> If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that. >> >> One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake. >> >> Again, if there is a CVE of concern, please let me know. >> >> Lonnie >> >> >> >> >>> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote: >>> >>> Hi Devs >>> >>> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. >>> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. >>> >>> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. >>> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). >>> >>> Thanks all. >>> >>> Regards >>> >>> Michael Knill >>> Managing Director >>> >>> D: +61 2 6189 1360 >>> P: +61 2 6140 4656 >>> E: mic...@ip... >>> W: ipcsolutions.com.au >>> >>> <image001.png> >>> Smarter Business Communications >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2022-04-15 23:38:45
|
Thanks Lonnie for the work you have done for this.
My stakeholder has replied to my email and is happy with the approach taken. Yay!
Just wondering when you are expecting 1.4.5 to be released so I can give them a remediation date.
Thanks again.
Regards
Michael Knill
On 15/4/22, 5:52 pm, "Michael Knill" <mic...@ip...> wrote:
Thanks Lonnie
I will chat to the stakeholder.
Regards
Michael Knill
On 15/4/22, 1:07 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes.
We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default.
We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible.
With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2].
Additionally, make lighttpd/php anonymize header version information [3].
As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application.
Lonnie
[1] https://security-tracker.debian.org/tracker/source-package/php7.4
[2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597
[3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6
> On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Lonnie
>
> Thanks for the info and sorry for the delayed response.
>
> I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them.
> PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while.
>
> Regards
> Michael Knill
>
> On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available?
>
> Looking at Debian security PHP:
> https://security-tracker.debian.org/tracker/source-package/php7.4
>
> There may be one CVE fix we could backport, though Debian opted to ignore it.
>
> Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows.
>
> If there is a specific CVE of concern in PHP, please point it out.
>
> If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that.
>
> One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake.
>
> Again, if there is a CVE of concern, please let me know.
>
> Lonnie
>
>
>
>
>> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Devs
>>
>> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities.
>> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted.
>>
>> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code.
>> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time).
>>
>> Thanks all.
>>
>> Regards
>>
>> Michael Knill
>> Managing Director
>>
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip...
>> W: ipcsolutions.com.au
>>
>> <image001.png>
>> Smarter Business Communications
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2022-04-15 07:52:43
|
Thanks Lonnie
I will chat to the stakeholder.
Regards
Michael Knill
On 15/4/22, 1:07 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes.
We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default.
We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible.
With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2].
Additionally, make lighttpd/php anonymize header version information [3].
As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application.
Lonnie
[1] https://security-tracker.debian.org/tracker/source-package/php7.4
[2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597
[3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6
> On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi Lonnie
>
> Thanks for the info and sorry for the delayed response.
>
> I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them.
> PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while.
>
> Regards
> Michael Knill
>
> On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Michael,
>
> Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available?
>
> Looking at Debian security PHP:
> https://security-tracker.debian.org/tracker/source-package/php7.4
>
> There may be one CVE fix we could backport, though Debian opted to ignore it.
>
> Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows.
>
> If there is a specific CVE of concern in PHP, please point it out.
>
> If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that.
>
> One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake.
>
> Again, if there is a CVE of concern, please let me know.
>
> Lonnie
>
>
>
>
>> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote:
>>
>> Hi Devs
>>
>> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities.
>> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted.
>>
>> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code.
>> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time).
>>
>> Thanks all.
>>
>> Regards
>>
>> Michael Knill
>> Managing Director
>>
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip...
>> W: ipcsolutions.com.au
>>
>> <image001.png>
>> Smarter Business Communications
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: David K. <da...@ke...> - 2022-04-14 18:50:20
|
"PHP version not supported" should really only matter if the end customer is intending to use PHP directly themselves. As an embedded system, if PHP access is restricted to use by services on, and maintained by, that embedded system, then it shouldn't matter what version it is -- so long as critical security fixes are applied. That said, Astlinux has diverged a lot from buildroot over the years and is way behind. Diverged may be the wrong word. But I don't think the "keep it small" argument holds any more given available memory in router/gateway devices. I know it is a huge undertaking, but it might be a good idea to think about re-architecting to build on current buildroot following their recommendations on how to package product specific features. Excuse me while I hide behind my kevlar shield to protect from the incoming barrage of reasons why that is a bad idea :-) David. On Thu, Apr 14, 2022 at 11:07 AM Lonnie Abelbeck <li...@lo...> wrote: > Hi Michael, > > I took some time and looked into bumping the AstLinux PHP version to 7.4 > ... short answer, keep it at 7.2 with appropriate CVE fixes. > > We (AstLinux) do not build a full set of PHP modules, only what we need to > lessen the security footprint and image size, as well as not exposing the > lighttpd/php stack to the public (encouraged) and by default. > > We also externally re-build the source "/ext/date/lib/timezonedb.h" file > to keep the timezone info up to date and as small as possible. > > With that in mind I scrutinized the Debian security-tracker for PHP [1] > and found one applicable CVE (Debian ignored it) but was simple to add [2]. > > Additionally, make lighttpd/php anonymize header version information [3]. > > As as aside, it is a pity the PHP folks don't offer an LTS version with > only security fixes. It seems somewhat unreasonable to me to always be > chasing the latest couple PHP versions, all containing "Backward > Incompatible Changes". As such, we do what we feel is best for our > specific project and application. > > Lonnie > > [1] https://security-tracker.debian.org/tracker/source-package/php7.4 > > [2] > https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 > > [3] > https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 > > > > > On Apr 13, 2022, at 8:13 PM, Michael Knill < > mic...@ip...> wrote: > > > > Hi Lonnie > > > > Thanks for the info and sorry for the delayed response. > > > > I'm afraid that it is purely a high level mandate as you mentioned and I > suspect it would be difficult to justify to them the addition of CVE's but > I am intending on discussing this with them. > > PHP 7.4 goes EoS after November so it would be a short term only fix > anyway but would keep the security guys happy for a little while. > > > > Regards > > Michael Knill > > > > On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> > wrote: > > > > Hi Michael, > > > > Is this vulnerability check based on a specific CVE or just the fact > there are bigger version numbers of PHP available? > > > > Looking at Debian security PHP: > > https://security-tracker.debian.org/tracker/source-package/php7.4 > > > > There may be one CVE fix we could backport, though Debian opted to > ignore it. > > > > Some of the CVEs effect modules we don't build like "soap", one only > applies to 7.4+, one only to Windows. > > > > If there is a specific CVE of concern in PHP, please point it out. > > > > If this is just some high-level mandates, like PHP >= 7.4 good, PHP < > 7.4 bad, then I have a hard time working with that. > > > > One issue with upgrading to PHP 7.4 is the internal libzip is no > longer supported, and libzip dropped autoconf support with versions > 1.3.2 > and switched to only cmake. > > > > Again, if there is a CVE of concern, please let me know. > > > > Lonnie > > > > > > > > > >> On Apr 12, 2022, at 12:59 AM, Michael Knill < > mic...@ip...> wrote: > >> > >> Hi Devs > >> > >> One of our major wholesale providers has performed a vulnerability > check on our Astlinux system and identified a few Medium and High > vulnerabilities. > >> Pretty sure we have rectified all the Mediums but the High one is the > PHP version now not supported. Unfortunately there will be significant > repercussions if I cannot get this sorted. > >> > >> So basically I need to go to PHP 7.4 which will take us to November or > go to 8.x which I understand will require some significant changes to the > current PHP code. > >> Do I have any other option than to roll my own image? If not then I'm > certainly going to need to outsource this task as we don't have the inhouse > skills (or time). > >> > >> Thanks all. > >> > >> Regards > >> > >> Michael Knill > >> Managing Director > >> > >> D: +61 2 6189 1360 > >> P: +61 2 6140 4656 > >> E: mic...@ip... > >> W: ipcsolutions.com.au > >> > >> <image001.png> > >> Smarter Business Communications > >> > >> _______________________________________________ > >> Astlinux-devel mailing list > >> Ast...@li... > >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2022-04-14 15:07:17
|
Hi Michael, I took some time and looked into bumping the AstLinux PHP version to 7.4 ... short answer, keep it at 7.2 with appropriate CVE fixes. We (AstLinux) do not build a full set of PHP modules, only what we need to lessen the security footprint and image size, as well as not exposing the lighttpd/php stack to the public (encouraged) and by default. We also externally re-build the source "/ext/date/lib/timezonedb.h" file to keep the timezone info up to date and as small as possible. With that in mind I scrutinized the Debian security-tracker for PHP [1] and found one applicable CVE (Debian ignored it) but was simple to add [2]. Additionally, make lighttpd/php anonymize header version information [3]. As as aside, it is a pity the PHP folks don't offer an LTS version with only security fixes. It seems somewhat unreasonable to me to always be chasing the latest couple PHP versions, all containing "Backward Incompatible Changes". As such, we do what we feel is best for our specific project and application. Lonnie [1] https://security-tracker.debian.org/tracker/source-package/php7.4 [2] https://github.com/astlinux-project/astlinux/commit/ca0f690ac145cb61c21fd419187e110db1b95597 [3] https://github.com/astlinux-project/astlinux/commit/d5210cd49b9f6450ec630e87f38ae4a44ad2b1d6 > On Apr 13, 2022, at 8:13 PM, Michael Knill <mic...@ip...> wrote: > > Hi Lonnie > > Thanks for the info and sorry for the delayed response. > > I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them. > PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while. > > Regards > Michael Knill > > On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote: > > Hi Michael, > > Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available? > > Looking at Debian security PHP: > https://security-tracker.debian.org/tracker/source-package/php7.4 > > There may be one CVE fix we could backport, though Debian opted to ignore it. > > Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows. > > If there is a specific CVE of concern in PHP, please point it out. > > If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that. > > One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake. > > Again, if there is a CVE of concern, please let me know. > > Lonnie > > > > >> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote: >> >> Hi Devs >> >> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. >> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. >> >> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. >> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). >> >> Thanks all. >> >> Regards >> >> Michael Knill >> Managing Director >> >> D: +61 2 6189 1360 >> P: +61 2 6140 4656 >> E: mic...@ip... >> W: ipcsolutions.com.au >> >> <image001.png> >> Smarter Business Communications >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2022-04-14 01:13:25
|
Hi Lonnie
Thanks for the info and sorry for the delayed response.
I'm afraid that it is purely a high level mandate as you mentioned and I suspect it would be difficult to justify to them the addition of CVE's but I am intending on discussing this with them.
PHP 7.4 goes EoS after November so it would be a short term only fix anyway but would keep the security guys happy for a little while.
Regards
Michael Knill
On 12/4/22, 11:56 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Michael,
Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available?
Looking at Debian security PHP:
https://security-tracker.debian.org/tracker/source-package/php7.4
There may be one CVE fix we could backport, though Debian opted to ignore it.
Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows.
If there is a specific CVE of concern in PHP, please point it out.
If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that.
One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake.
Again, if there is a CVE of concern, please let me know.
Lonnie
> On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote:
>
> Hi Devs
>
> One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities.
> Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted.
>
> So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code.
> Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time).
>
> Thanks all.
>
> Regards
>
> Michael Knill
> Managing Director
>
> D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>
> <image001.png>
> Smarter Business Communications
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2022-04-12 13:56:35
|
Hi Michael, Is this vulnerability check based on a specific CVE or just the fact there are bigger version numbers of PHP available? Looking at Debian security PHP: https://security-tracker.debian.org/tracker/source-package/php7.4 There may be one CVE fix we could backport, though Debian opted to ignore it. Some of the CVEs effect modules we don't build like "soap", one only applies to 7.4+, one only to Windows. If there is a specific CVE of concern in PHP, please point it out. If this is just some high-level mandates, like PHP >= 7.4 good, PHP < 7.4 bad, then I have a hard time working with that. One issue with upgrading to PHP 7.4 is the internal libzip is no longer supported, and libzip dropped autoconf support with versions > 1.3.2 and switched to only cmake. Again, if there is a CVE of concern, please let me know. Lonnie > On Apr 12, 2022, at 12:59 AM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. > Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. > > So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. > Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). > > Thanks all. > > Regards > > Michael Knill > Managing Director > > D: +61 2 6189 1360 > P: +61 2 6140 4656 > E: mic...@ip... > W: ipcsolutions.com.au > > <image001.png> > Smarter Business Communications > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2022-04-12 06:33:29
|
Hi Devs One of our major wholesale providers has performed a vulnerability check on our Astlinux system and identified a few Medium and High vulnerabilities. Pretty sure we have rectified all the Mediums but the High one is the PHP version now not supported. Unfortunately there will be significant repercussions if I cannot get this sorted. So basically I need to go to PHP 7.4 which will take us to November or go to 8.x which I understand will require some significant changes to the current PHP code. Do I have any other option than to roll my own image? If not then I'm certainly going to need to outsource this task as we don't have the inhouse skills (or time). Thanks all. Regards Michael Knill Managing Director D: +61 2 6189 1360 P: +61 2 6140 4656 E: mic...@ip...<mailto:mic...@ip...> W: ipcsolutions.com.au<https://ipcsolutions.com.au/> [Icon Description automatically generated] Smarter Business Communications |
|
From: Lonnie A. <li...@lo...> - 2022-03-02 13:49:22
|
Announcing AstLinux Release: 1.4.5 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.5 Highlights: * Asterisk Versions: 13.38.3, 16.21.1, 18.10.0 * Asterisk 18.x is now supported, along with Asterisk 16.x and Asterisk 13.x built --without-pjproject * Previous ast13-firmware-1.x is no longer being updated, ast13-firmware-1.x users should either switch to ast16-firmware-1.x (recommended) or use ast13se-firmware-1.x if chan_pjsip is not used in your dialplan. * Linux Kernel 4.19.230, security and bug fixes * RUNNIX, version bump to runnix-0.6.6 * OpenSSL, version bump to 1.1.1m, security fixes: none * WireGuard VPN, module 1.0.20211208 (version bump), tools 1.0.20210914 (no change) * strongSwan, version 5.5.3, security fix: CVE-2021-45079 * libcurl (curl) version bump to 7.81.0 * chrony, version bump to 4.2 * darkstat, version bump to 3.0.721 * expat, version bump to 2.4.6, security fixes: many * Monit, version bump to 5.31.0 * msmtp, version bump to 1.8.19, 'msmtpd' security fix * mtr, version bump to 0.95 * prosody, version bump to 0.11.13 * tarsnap, version bump to 1.0.40, "Trust No One" encrypted backups using the Tarsnap Backup service. * vnStat, version bump to 2.9 * zabbix, version bump to 4.0.38 * Asterisk '13se' (stable edition) version 13.38.3 is the last Asterisk 13.x "Legacy" version, built --without-pjproject * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.5/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Josh A. <jm...@ho...> - 2022-02-24 04:25:30
|
I would have noticed that if I paid more attention to host -h. Thanks for pointing that out! ________________________________ From: Lonnie Abelbeck <li...@lo...> Sent: Tuesday, February 22, 2022 9:17 PM To: AstLinux Developers Mailing List <ast...@li...> Subject: Re: [Astlinux-devel] Can't Add Bind to New Dev Build Hi Josh, "host" on AstLinux is a symlink to "unbound-host", and as you mentioned it works with NAPTR lookups ... -- pbx3 ~ # host -t NAPTR hpbxsec.deutschland-lan.de hpbxsec.deutschland-lan.de has NAPTR record 10 0 "s" "SIPS+D2T" "" _sips._tcp.hpbxsec.deutschland-lan.de. -- Good to know :-) Lonnie > On Feb 22, 2022, at 7:59 PM, Josh Alberts <jm...@ho...> wrote: > > Hi Lonnie, > > My goal here is to be able to do NAPTR lookups since much of my VOIP stuff uses ENUM. Of course I can SSH to another box or use an online dig but I'm lazy so I like to have the ability to do NAPTR lookups wherever I find myself logged in. > > You mentioned 'host' and I never checked to see whether it was capable of doing NAPTR lookups. It turns out that it can. So, rather than use dig or even unbound-host, I think I will just use host on my Astlinux machines when I find myself in need of a NAPTR lookup. No extra software needed! > > Thanks again for your feedback. I never knew about unbound so it's good to know that it exists. I also wasn't aware of the LXC container functionality in Astlinux - that could be useful at some point! I've been using Astlinux for perhaps 8 years at this point and I am happy that it still seems to be going strong. > > Josh > > From: Lonnie Abelbeck <li...@lo...> > Sent: Sunday, February 20, 2022 11:21 AM > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Can't Add Bind to New Dev Build > > > > > On Feb 20, 2022, at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote: > > > > > >> On Feb 20, 2022, at 9:06 AM, Josh Alberts <jm...@ho...> wrote: > >> > >> Hello Astlinux Team, > >> > >> I tried to make a fresh development built last night and I am unable to include 'bind libs and dig tool'. After adding it in 'make menuconfig' this is the error that I get when running the build script: > >> > >> ... > > > >> It's not imperative for me to have bind but I like to have it in my dev builds so I can use dig. Would you guys please consider bumping the version of bind to something that will build with Astlinux? > >> > >> Thanks! > > > > Hi Josh, > > > > AstLinux has never included "bind" in the image, the package has originated with an early Buildroot. > > > > Years ago we looked at adding "dig", but it added a lot to the disk image size ... which 5MB of .xz compressed source might imply. > > > > Instead the "unbound" package installs unbound-host (with a symlink for "host"), while not "dig" it provides a lot of functionality. Much better than Busybox's nslookup. > > > > Lonnie > > Josh, another thought... > > In cases where it might be handy to have diagnostic tools (like "dig") you can install a Debian LXC container within AstLinux. > > LXC container in AstLinux > https://doc.astlinux-project.org/userdoc:guest_lxc_container > > The LXC container is not part of the AstLinux image, but uses /mnt/kd/lxc/ for storage, and must be kept updated separately. > > > Lonnie > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel _______________________________________________ Astlinux-devel mailing list Ast...@li... https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2022-02-23 02:17:54
|
Hi Josh, "host" on AstLinux is a symlink to "unbound-host", and as you mentioned it works with NAPTR lookups ... -- pbx3 ~ # host -t NAPTR hpbxsec.deutschland-lan.de hpbxsec.deutschland-lan.de has NAPTR record 10 0 "s" "SIPS+D2T" "" _sips._tcp.hpbxsec.deutschland-lan.de. -- Good to know :-) Lonnie > On Feb 22, 2022, at 7:59 PM, Josh Alberts <jm...@ho...> wrote: > > Hi Lonnie, > > My goal here is to be able to do NAPTR lookups since much of my VOIP stuff uses ENUM. Of course I can SSH to another box or use an online dig but I'm lazy so I like to have the ability to do NAPTR lookups wherever I find myself logged in. > > You mentioned 'host' and I never checked to see whether it was capable of doing NAPTR lookups. It turns out that it can. So, rather than use dig or even unbound-host, I think I will just use host on my Astlinux machines when I find myself in need of a NAPTR lookup. No extra software needed! > > Thanks again for your feedback. I never knew about unbound so it's good to know that it exists. I also wasn't aware of the LXC container functionality in Astlinux - that could be useful at some point! I've been using Astlinux for perhaps 8 years at this point and I am happy that it still seems to be going strong. > > Josh > > From: Lonnie Abelbeck <li...@lo...> > Sent: Sunday, February 20, 2022 11:21 AM > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Can't Add Bind to New Dev Build > > > > > On Feb 20, 2022, at 9:54 AM, Lonnie Abelbeck <li...@lo...> wrote: > > > > > >> On Feb 20, 2022, at 9:06 AM, Josh Alberts <jm...@ho...> wrote: > >> > >> Hello Astlinux Team, > >> > >> I tried to make a fresh development built last night and I am unable to include 'bind libs and dig tool'. After adding it in 'make menuconfig' this is the error that I get when running the build script: > >> > >> ... > > > >> It's not imperative for me to have bind but I like to have it in my dev builds so I can use dig. Would you guys please consider bumping the version of bind to something that will build with Astlinux? > >> > >> Thanks! > > > > Hi Josh, > > > > AstLinux has never included "bind" in the image, the package has originated with an early Buildroot. > > > > Years ago we looked at adding "dig", but it added a lot to the disk image size ... which 5MB of .xz compressed source might imply. > > > > Instead the "unbound" package installs unbound-host (with a symlink for "host"), while not "dig" it provides a lot of functionality. Much better than Busybox's nslookup. > > > > Lonnie > > Josh, another thought... > > In cases where it might be handy to have diagnostic tools (like "dig") you can install a Debian LXC container within AstLinux. > > LXC container in AstLinux > https://doc.astlinux-project.org/userdoc:guest_lxc_container > > The LXC container is not part of the AstLinux image, but uses /mnt/kd/lxc/ for storage, and must be kept updated separately. > > > Lonnie > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
28 messages has been excluded from this view by a project administrator.
