Created attachment 380554 [details] ucspi-ssl-0.94.ebuild Current version in portage (0.70-r1) is affected by heartbleed. Even after updating openssl and recompiling ucspi-ssl testing it for heartbleed result in: kern.info: sslserver[31035]: segfault at b2b8b00 ip 00000320e6973a24 sp 00007e1e8e459f10 error 4 in sslserver[320e6968000+15000] kern.alert: grsec: Segmentation fault occurred at 000000000b2b8b00 in /usr/bin/sslserver[sslserver:31035] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sslserver[sslserver:30956] uid/euid:0/0 gid/egid:0/0 According to home page http://www.superscript.com/ucspi-ssl/ it doesn't supported anymore, but author recommends few forks. Latest version on home page is 0.73, but looks like it uses modified build scripts, and current ebuild is unable to handle it. I think Erwin Hoffman’s fork http://www.fehcom.de/ipnet/ucspi-ssl.html is most up-to-date and supported. Also it's based on 0.70, so current ebuild is able to handle it with trivial modifications: no needs in separate patch (I believe it's already included in this fork) and there is more doc and man pages to install. Ebuild for that fork attached.
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.