| Summary: | apache-2.0.51.tar.gz no longer available | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vincenzo Romano <vincenzo.romano> |
| Component: | [OLD] Server | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
| Status: | VERIFIED WONTFIX | ||
| Severity: | blocker | CC: | cyber.tf, olofmogren |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Vincenzo Romano
2004-09-28 06:13:04 UTC
Not much we can do about this, it's still on the distfiles mirrors, so it's available to Gentoo users (we addressed the Satisfy errata already in -r1). A new 2.0.52 ebuild will hopefully show up soon, though. I agree it's not a bug, but it is not a good behaviour as well! The point is that emerge failed to find it anywhere! I had to switch back to 2.0.50!!! And the same happened with ssmtp_2.60.9.tar.gz (needed by vixie-cron) and some other packages. I think, in the case of apache, that the portage DB refers to some unstable release that has been deleted. I do a "emerge sync; emerge -u apache". Portage is not able to retrieve the file in any mirror. Could you please check? I'm using 2004.2. A lot of mirrors dont have 2.0.51 anymore. Problem packages with security-fixes depended on 2.0.51 are subversion 1.0.8 php_mod 4.3.9 2.0.52 should be rolled out ASAP. httpd-2.0.51.tar.gz exists on the main distfiles mirror, http://gentoo.osuosl.org/. If you can't get it from any of the mirrors in GENTOO_MIRRORS (in make.conf), change your mirrors - they're out of date! Elfyn, that depends. Or see it relative... Apache 2.0.51 (and _only_ .51;) has a serious security hole. That is the reason that this package has been deleted on the major sites. Ok, gentoo hat fixed that with a patch in a very short time, but this ebuild (2.0.51-r1) need the buggy 2.0.51-tarball to install. I see it the other way: If a mirror still provides 2.0.51, then __this__ mirror is out of date. That means, that the ebuild 2.0.51-r1 has a problem: It fixes a problem from a software, that should not be on the net anymore. Anyway.. to save time for the gentoo-users, 2.0.52 should be made stable asap. Going back to 2.0.50 needs a additional compile for the 2.0.51-r1 users. (my 2 Cent) While you are right in the fact that 2.0.51 has a huge security hole, Gentoo _has_ patched that hole. So if a user decides to install a pristine 2.0.51 (without the Gentoo patch), it is their own responsibility. The 2.0.52 ebuild will take some time be marked stable as the 2.0.51-r1 ebuild was already pushed stable for the Sastify directive. Therefore, this bug as far as we are concerned does not involve Gentoo as a whole, and we'll get 2.0.52 in as soon as we possibly can. Assigning this can't fix since Gentoo can't change the availability of 2.0.51 on the net as a whole, and Gentoo mirrors should still contain the 2.0.51 tarball with the corresponding patch for the Sastify directive. Hello all again. I don't think we can say "Status:RESOLVED" and "Resolution: CANTFIX". Because there's no slution. I used "mirrorselect" and would not change the mirror list by hand. If everyone would point to a single mirror server, it would be overloaded and thus bypassing the mirror concept itself. This kind of toubles happened to me with a bunch of packages in a fresh new "emerge system" from the net. And possibly will happen to everyone. The solution would be: once a package gets banned because of a security hole, it should not be patched, but rollbacked to the previous stable version. Or upgraded to the new one. So, in the case of Apache, the 2.0.51 should disappear in favour of 2.0.52 or 2.0.50 if that one is not ready for delivery. I think you all agree this is Priority-1 and Blocking. So we need to reopen it. Were not fixing this. It is on the Gentoo mirrors. Please stop reopening this. 2.0.52 will be in soon. That's OK: it i my option #1! But in the meantime only one mirror has 2.0.51! *** Bug 66220 has been marked as a duplicate of this bug. *** *** Bug 66280 has been marked as a duplicate of this bug. *** Closing. |
