Summary: | <sys-apps/ucspi-ssl-0.94-r1: heartbleed vulnerability | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Alex Efros <powerman-asdf> | ||||||||||||||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||
Severity: | normal | CC: | proxy-maint, toto | ||||||||||||||||
Priority: | Normal | ||||||||||||||||||
Version: | unspecified | ||||||||||||||||||
Hardware: | All | ||||||||||||||||||
OS: | Linux | ||||||||||||||||||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=531300 https://bugs.gentoo.org/show_bug.cgi?id=531298 |
||||||||||||||||||
Whiteboard: | B3 [noglsa] | ||||||||||||||||||
Package list: | Runtime testing required: | --- | |||||||||||||||||
Bug Depends on: | 545682, 547156 | ||||||||||||||||||
Bug Blocks: | |||||||||||||||||||
Attachments: |
|
Description
Alex Efros
2014-07-11 05:55:45 UTC
Created attachment 381140 [details]
ucspi-ssl-0.94-r1.ebuild
fix compability with x86, tested on amd64 & x86
(In reply to Alex Efros from comment #1) > Created attachment 381140 [details] > ucspi-ssl-0.94-r1.ebuild > > fix compability with x86, tested on amd64 & x86 Hi Alex, I'm CCing the proxy-maintainers project[0] on this bug report in the event you are interesting in working with them as a proxy maintainer of this package. [0] http://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Do you mean http://www.fehcom.de/ipnet/ucspi-ssl/ucspi-ssl-0.84.tgz http://www.fehcom.de/ipnet/ucspi-ssl/ucspi-ssl-0.94.tgz http://www.fehcom.de/ipnet/ucspi-ssl/ucspi-ssl-0.95a.tgz ? "http://www.fehcom.de/ipnet/ucspi-ssl/${P}.tgz" doesn't fetch, today. (In reply to Kristian Fiskerstrand from comment #2) > Hi Alex, I'm CCing the proxy-maintainers project[0] on this bug report in > the event you are interesting in working with them as a proxy maintainer of > this package. > > [0] http://wiki.gentoo.org/wiki/Project:Proxy_Maintainers I'm ok to become a proxy maintainer for this, and may be few other packages - I'm anyway support them in my overlay for years. What I should do in addition to publishing ebuilds here like I already did? (In reply to Ian Delaney from comment #3) > "http://www.fehcom.de/ipnet/ucspi-ssl/${P}.tgz" doesn't fetch, today. Now sure about what was the issue at "today", but for me it works ok all this time (and I've just tested this again). Cancel about the "http://www.fehcom.de/ipnet/ucspi-ssl/${P}.tgz" doesn't fetch, today. was attempting something wrong, however, DEPEND=">=dev-libs/openssl-0.9.6g sys-apps/ucspi-tcp" RDEPEND="${DEPEND}" ~/cvsPortage/gentoo-x86/sys-apps/ucspi-ssl $ ebuild ucspi-ssl-0.94-r1.ebuild clean compile socket.lib` `cat ssl.lib` `cat socket.lib` `cat perlembed.lib` >>> Source compiled. says that dev-libs/openssl and or sys-apps/ucspi-tcp are RDEPENDs not DEPENDs. I do not have sys-apps/ucspi-tcp emerged nor can I. After trying a few mirrors it fails to fetch. The build and install phases can be verified however I suspect DEPEND and RDEPEND may need reversing. Oh no. There is NO EAPI set, at all. This is a major oversight. RDEPEND="${DEPEND}" were the norm in older EAPIs. With EAPI 5 it is generally plain wrong. This is close but needs these correcting. We will also need some other participants to assure the sys-apps/ucspi-tcp can be acquired and emerged. Once these are done I can commit it with you as proxy. Good luck. (In reply to Ian Delaney from comment #5) > I do not have sys-apps/ucspi-tcp emerged nor can I. After trying a few > mirrors it fails to fetch. I've just fetched it without any issues: # rm /usr/portage-distfiles/ucspi-tcp-0.88* # emerge -1 ucspi-tcp ... >>> Emerging (1 of 1) sys-apps/ucspi-tcp-0.88-r17::gentoo >>> Downloading 'http://tux.rainside.sk/gentoo/distfiles/ucspi-tcp-0.88.tar.gz' --2015-04-01 16:48:50-- http://tux.rainside.sk/gentoo/distfiles/ucspi-tcp-0.88.tar.gz Resolving tux.rainside.sk (tux.rainside.sk)... 212.89.225.155 Connecting to tux.rainside.sk (tux.rainside.sk)|212.89.225.155|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 53019 (52K) [application/x-gzip] Saving to: ‘/usr/portage-distfiles/ucspi-tcp-0.88.tar.gz’ /usr/portage-distfi 100%[=====================>] 51.78K --.-KB/s in 0.09s 2015-04-01 16:48:51 (564 KB/s) - ‘/usr/portage-distfiles/ucspi-tcp-0.88.tar.gz’ saved [53019/53019] * ucspi-tcp-0.88.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * ucspi-rss.diff SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Downloading 'http://tux.rainside.sk/gentoo/distfiles/ucspi-tcp-0.88-man.tar.gz' --2015-04-01 16:48:51-- http://tux.rainside.sk/gentoo/distfiles/ucspi-tcp-0.88-man.tar.gz Resolving tux.rainside.sk (tux.rainside.sk)... 212.89.225.155 Connecting to tux.rainside.sk (tux.rainside.sk)|212.89.225.155|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7562 (7.4K) [application/x-gzip] Saving to: ‘/usr/portage-distfiles/ucspi-tcp-0.88-man.tar.gz’ /usr/portage-distfi 100%[=====================>] 7.38K --.-KB/s in 0.02s 2015-04-01 16:48:51 (338 KB/s) - ‘/usr/portage-distfiles/ucspi-tcp-0.88-man.tar.gz’ saved [7562/7562] * ucspi-tcp-0.88-man.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Downloading 'http://tux.rainside.sk/gentoo/distfiles/ucspi-tcp-0.88-rblspp.patch' --2015-04-01 16:48:51-- http://tux.rainside.sk/gentoo/distfiles/ucspi-tcp-0.88-rblspp.patch Resolving tux.rainside.sk (tux.rainside.sk)... 212.89.225.155 Connecting to tux.rainside.sk (tux.rainside.sk)|212.89.225.155|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 6565 (6.4K) [text/x-diff] Saving to: ‘/usr/portage-distfiles/ucspi-tcp-0.88-rblspp.patch’ /usr/portage-distfi 100%[=====================>] 6.41K --.-KB/s in 0.02s 2015-04-01 16:48:51 (316 KB/s) - ‘/usr/portage-distfiles/ucspi-tcp-0.88-rblspp.patch’ saved [6565/6565] * ucspi-tcp-0.88-rblspp.patch SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... > Oh no. There is NO EAPI set, at all. This is a major oversight. Yeah, some very old ebuilds in my overlay doesn't have EAPI, I'll fix this. Created attachment 400344 [details]
ebuild updated to EAPI=5
Differences are:
- added EAPI=5
- added all ARCH in KEYWORDS and drop redundant ldflags patching
- drop unused IUSE=tls
- move ucspi-tcp to RDEPEND
- use src_prepare() instead of src_unpack() as repoman recommends
- update top comment from skel.ebuild
(In reply to Alex Efros from comment #7) > Differences are: - set all KEYWORDS to ~ARCH Was going to mention src_unpack but you found it when using EAPI5. Check on 2 things; see if make || die "make failed" can -> emake unmerge dev-libs/openssl, re-run the ebuild with /path/to/sys-apps/ucspi-ssl $ sudo ebuild ucspi-ssl-0.94.ebuild clean install if it fails to build it proves >=dev-libs/openssl-0.9.6g is indeed a DEPEND otherwise it also need shifting to RDEPEND Otherwise looking very good, almost there. Re-post and likely it will be ready for me to commit (In reply to Ian Delaney from comment #9) > Check on 2 things; > see if make || die "make failed" can -> emake Well, I've already checked this before - it fails. But I've just look at error message more closely and it looks like something was run in wrong order. So I've tried `emake -j1` and this way it works. I'll attach updated ebuild now. > unmerge dev-libs/openssl ./compile sslclient.c In file included from sslclient.c:11:0: ucspissl.h:9:25: fatal error: openssl/ssl.h: No such file or directory #include <openssl/ssl.h> ^ compilation terminated. Makefile:696: recipe for target 'sslclient.o' failed make: *** [sslclient.o] Error 1 Created attachment 400438 [details]
ucspi-ssl-0.94-r2.ebuild
repo.eapi.deprecated 1 sys-apps/ucspi-ssl/ucspi-ssl-0.70-r1.ebuild: 0 upstream.workaround 1 sys-apps/ucspi-ssl/ucspi-ssl-0.94.ebuild: Upstream parallel compilation bug (ebuild calls emake -j1 on line: 38) but we'll live with that for now. 03 Apr 2015; Ian Delaney <idella4@gentoo.org> metadata.xml, ucspi-ssl-0.94.ebuild: set Alex Efros as proxy maintainer in metadata.xml, fix slot issue for dep dev-libs/openssl *ucspi-ssl-0.94 (03 Apr 2015) 03 Apr 2015; Ian Delaney <idella4@gentoo.org> +ucspi-ssl-0.94.ebuild: bump; ebuild preapred by Alex Efros in Bug #516868 I suggest the sec team reset to stable request and make stable. ALL arches amd64 stable Do what now? (In reply to Jeroen Roovers from comment #14) > Do what now? It appears you seek clarification. you have already done jer@gentoo.org 2015-04-03 19:35:41 UTC Keywords STABLEREQ all is all set and in motion. Arches, please test and mark stable: =sys-apps/ucspi-ssl-0.94 Target Keywords : "alpha amd64 arm hppa ia64 ppc ppc64 spark x86" alpha stable ia64 stable Created attachment 401428 [details] ucspi-ssl-0.94-r2.ebuild Proposed fix for bug 545682 (HPPA). Created attachment 401578 [details, diff]
files/ucspi-ssl-0.94-verbose.patch
Created attachment 401580 [details] ucspi-ssl-0.94-r2.ebuild Add ucspi-ssl-0.94-verbose.patch as recommended in bug 546992 revbumped mainly due to many of the arches already passed stable testing. *ucspi-ssl-0.94-r1 (19 Apr 2015) 19 Apr 2015; Ian Delaney <idella4@gentoo.org> +ucspi-ssl-0.94-r1.ebuild, +files/ucspi-ssl-0.94-verbose.patch: revbump; patch to fix deficit in qmail eclass wrt Bugs #516868 #546992 blueknight do you care to call on arches to make stable this revbump? There are both r1 and r2 here, which one you want re-stabilized? Or you can just call yourself. Looks like -r2 wasn't committed to the tree, -r1 should be the candidate... but is bug 545682 fixed by that revision? (In reply to Pacho Ramos from comment #24) > is bug 545682 fixed by that revision? It's better to test it to be sure, but I think so - substring "-m64" doesn't exists in sources anymore at all. I strongly suggest we await some + confirmation to TEST_REQUEST in 545682 before we proceed here, quite likely keeping to a revised -r1. We wait and see now Stable for HPPA. 09 Apr 2015; Agostino Sarubbo <ago@gentoo.org> ucspi-ssl-0.94.ebuild: Stable for x86, wrt bug #516868 I am amazed at how this could possibly have worked. (In reply to Jeroen Roovers from comment #28) > 09 Apr 2015; Agostino Sarubbo <ago@gentoo.org> ucspi-ssl-0.94.ebuild: > Stable for x86, wrt bug #516868 > > I am amazed at how this could possibly have worked. I'm sure there was a script error. Stable for PPC64. (In reply to Agostino Sarubbo from comment #29) > (In reply to Jeroen Roovers from comment #28) > > 09 Apr 2015; Agostino Sarubbo <ago@gentoo.org> ucspi-ssl-0.94.ebuild: > > Stable for x86, wrt bug #516868 > > > > I am amazed at how this could possibly have worked. > > I'm sure there was a script error. You should probably not be doing any keywording if you trust your scripts that much. ppc stable arm stable sparc stable Old versions have since been removed. GLSA Vote: Yes New GLSA Request filed. I am closing this due to the age of the bug and the vulnerability does not require a GLSA. |