roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
On 17/05/2021 19:32, Kevin Fenzi wrote:
roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 - https://roundcube.net/about/#features. Current PHP is php-5.4.16-48. There is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/.
On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
On 17/05/2021 19:32, Kevin Fenzi wrote:
roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 - https://roundcube.net/about/#features. Current PHP is php-5.4.16-48. There is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/.
Currently epel7 has 1.2.12. We could update to 1.2.13, which fixes 2 of the CVE's... but that leaves 8 more. I don't really think they are going to be doing any more 1.2.x releases now that 1.5 is almost out.
Sorry I wasn't being exact there, it's not php itself, it's various php related things. Like php-pear version 1.10.1 is needed and rhel7 has 1.9.4 and so on.
If you would like to try and get 1.4.x working on epel7 that would be great! Of course the 1.2 -> 1.4 jump would be pretty major for users, but such things happen.
kevin
On 17/05/2021 23:14, Kevin Fenzi wrote:
On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
On 17/05/2021 19:32, Kevin Fenzi wrote:
roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 - https://roundcube.net/about/#features. Current PHP is php-5.4.16-48. There is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/.
Currently epel7 has 1.2.12. We could update to 1.2.13, which fixes 2 of the CVE's... but that leaves 8 more. I don't really think they are going to be doing any more 1.2.x releases now that 1.5 is almost out.
Sorry I wasn't being exact there, it's not php itself, it's various php related things. Like php-pear version 1.10.1 is needed and rhel7 has 1.9.4 and so on.
If you would like to try and get 1.4.x working on epel7 that would be great! Of course the 1.2 -> 1.4 jump would be pretty major for users, but such things happen.
kevin
Let me first say I run ClearOS7 which is a Centos7 clone and we generally use EPEL - it is enabled by default. However, in this case, we do not use the EPEL version of Roundcube - I think ours is set up slightly differently with Sieve and the Global Address Book. However it is not regularly maintained so is often out of date. Our version history is: 1.0.5 1.1.3 1.2.3 1.3.9
I don't know the EPEL packaging but in ClearOS, going from 1.2 -> 1.3 had a few changes to the spec file - capitalisation on the Global Address Book file name and, in the %files section, a load of changes specifying individual files instead of whole directories under plugins. (I am not sure why that was done), but, for the users, the upgrade process was seamless each time.
Nick
On Mon, 17 May 2021 at 18:14, Kevin Fenzi kevin@scrye.com wrote:
On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
On 17/05/2021 19:32, Kevin Fenzi wrote:
roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 - https://roundcube.net/about/#features. Current PHP is php-5.4.16-48.
There
is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/.
Currently epel7 has 1.2.12. We could update to 1.2.13, which fixes 2 of the CVE's... but that leaves 8 more. I don't really think they are going to be doing any more 1.2.x releases now that 1.5 is almost out.
Sorry I wasn't being exact there, it's not php itself, it's various php related things. Like php-pear version 1.10.1 is needed and rhel7 has 1.9.4 and so on.
If you would like to try and get 1.4.x working on epel7 that would be great! Of course the 1.2 -> 1.4 jump would be pretty major for users, but such things happen.
I am wondering if we need a different way to announce reasons for this:
[ ] I no longer use RHEL-7 so can not test [ ] I found that there are too many package updates needed that I do not have time for. [ ] The following RHEL packages are too old for this package to be updated [ ] The upstream is dead and I can not fix ...
On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 17 May 2021 at 18:14, Kevin Fenzi kevin@scrye.com wrote:
On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
On 17/05/2021 19:32, Kevin Fenzi wrote:
roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 - https://roundcube.net/about/#features. Current PHP is php-5.4.16-48.
There
is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/.
Currently epel7 has 1.2.12. We could update to 1.2.13, which fixes 2 of the CVE's... but that leaves 8 more. I don't really think they are going to be doing any more 1.2.x releases now that 1.5 is almost out.
Sorry I wasn't being exact there, it's not php itself, it's various php related things. Like php-pear version 1.10.1 is needed and rhel7 has 1.9.4 and so on.
If you would like to try and get 1.4.x working on epel7 that would be great! Of course the 1.2 -> 1.4 jump would be pretty major for users, but such things happen.
I am wondering if we need a different way to announce reasons for this:
[ ] I no longer use RHEL-7 so can not test [ ] I found that there are too many package updates needed that I do not have time for. [ ] The following RHEL packages are too old for this package to be updated [ ] The upstream is dead and I can not fix ...
Or maybe instead of saying it's retiring, do Fedora's Orphaning format. Announce they are orphaning the package, and if a package is orphaned for a certain amount of time, and has all the orphan annoucements, it get's removed. But I do like your checkbox way for announcing the reasons for retiring/orphaning.
Troy
On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote:
On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen smooge@gmail.com wrote:
...snip...
Here's a scratch build of 1.4.11, but I bet it won't work as many of the php-pear packages are too old. ;(
https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451
I am wondering if we need a different way to announce reasons for this:
[ ] I no longer use RHEL-7 so can not test [ ] I found that there are too many package updates needed that I do not have time for. [ ] The following RHEL packages are too old for this package to be updated [ ] The upstream is dead and I can not fix ...
Or maybe instead of saying it's retiring, do Fedora's Orphaning format. Announce they are orphaning the package, and if a package is orphaned for a certain amount of time, and has all the orphan annoucements, it get's removed. But I do like your checkbox way for announcing the reasons for retiring/orphaning.
Well, thats what goes in the dead.package file when the package is retired. :)
I was just wanting to stop shipping a known vulnerable package and get it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't actually going to work, but happy for someone to prove me wrong. I don't really have the time to investigate further myself.
So, I will orphan it now, if no one takes it in a while, I will retire it then?
kevin
On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote:
On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote:
On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen < smooge@gmail.com> wrote:
...snip...
Here's a scratch build of 1.4.11, but I bet it won't work as many of the php-pear packages are too old. ;(
https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451
why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/ ?
I am wondering if we need a different way to announce reasons for this:
[ ] I no longer use RHEL-7 so can not test [ ] I found that there are too many package updates needed that I do not have time for. [ ] The following RHEL packages are too old for this package to be updated [ ] The upstream is dead and I can not fix ...
Or maybe instead of saying it's retiring, do Fedora's Orphaning format. Announce they are orphaning the package, and if a package is orphaned for a certain amount of time, and has all the orphan annoucements, it get's removed. But I do like your checkbox way for announcing the reasons for retiring/orphaning.
Well, thats what goes in the dead.package file when the package is retired. :)
I was just wanting to stop shipping a known vulnerable package and get it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't actually going to work, but happy for someone to prove me wrong. I don't really have the time to investigate further myself.
So, I will orphan it now, if no one takes it in a while, I will retire it then?
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, 24 May 2021 at 14:36, Sérgio Basto sergio@serjux.com wrote:
On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote:
On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote:
On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen < smooge@gmail.com> wrote:
...snip...
Here's a scratch build of 1.4.11, but I bet it won't work as many of the php-pear packages are too old. ;(
https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451
why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/ ?
EPEL packages may rely on Red Hat SCL's for build dependencies but not run-time dependencies. In this case this would be a run-time dependency requirement.
On 24/05/2021 19:36, Sérgio Basto wrote:
On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote:
On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote:
On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen < smooge@gmail.com> wrote:
...snip...
Here's a scratch build of 1.4.11, but I bet it won't work as many of the php-pear packages are too old. ;(
https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451
why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/ ?
If Roundcube 1.4 doesn't work, 1.3 will.
I am wondering if we need a different way to announce reasons for this:
[ ] I no longer use RHEL-7 so can not test [ ] I found that there are too many package updates needed that I do not have time for. [ ] The following RHEL packages are too old for this package to be updated [ ] The upstream is dead and I can not fix ...
Or maybe instead of saying it's retiring, do Fedora's Orphaning format. Announce they are orphaning the package, and if a package is orphaned for a certain amount of time, and has all the orphan annoucements, it get's removed. But I do like your checkbox way for announcing the reasons for retiring/orphaning.
Well, thats what goes in the dead.package file when the package is retired. :)
I was just wanting to stop shipping a known vulnerable package and get it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't actually going to work, but happy for someone to prove me wrong. I don't really have the time to investigate further myself.
So, I will orphan it now, if no one takes it in a while, I will retire it then?
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
epel-devel@lists.fedoraproject.org
-
Kevin Fenzi -
Nick Howitt -
Stephen John Smoogen -
Sérgio Basto -
Troy Dawson