Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 516868 - <sys-apps/ucspi-ssl-0.94-r1: heartbleed vulnerability
Summary: <sys-apps/ucspi-ssl-0.94-r1: heartbleed vulnerability
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [noglsa]
Keywords:
Depends on: 545682 547156
Blocks:
  Show dependency tree
 
Reported: 2014-07-11 05:55 UTC by Alex Efros
Modified: 2016-11-17 08:16 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ucspi-ssl-0.94.ebuild (ucspi-ssl-0.94.ebuild,1.20 KB, text/plain)
2014-07-11 05:55 UTC, Alex Efros
no flags Details
ucspi-ssl-0.94-r1.ebuild (ucspi-ssl-0.94-r1.ebuild,1.27 KB, text/plain)
2014-07-20 15:10 UTC, Alex Efros
no flags Details
ebuild updated to EAPI=5 (ucspi-ssl-0.94-r2.ebuild,1.09 KB, text/plain)
2015-04-01 14:55 UTC, Alex Efros
no flags Details
ucspi-ssl-0.94-r2.ebuild (ucspi-ssl-0.94-r2.ebuild,1.08 KB, text/plain)
2015-04-02 23:52 UTC, Alex Efros
no flags Details
ucspi-ssl-0.94-r2.ebuild (ucspi-ssl-0.94-r2.ebuild,1.11 KB, text/plain)
2015-04-17 06:17 UTC, Alex Efros
no flags Details
files/ucspi-ssl-0.94-verbose.patch (ucspi-ssl-0.94-verbose.patch,408 bytes, patch)
2015-04-19 02:18 UTC, Alex Efros
no flags Details | Diff
ucspi-ssl-0.94-r2.ebuild (ucspi-ssl-0.94-r2.ebuild,1.15 KB, text/plain)
2015-04-19 02:19 UTC, Alex Efros
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Efros 2014-07-11 05:55:45 UTC
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.
Comment 1 Alex Efros 2014-07-20 15:10:48 UTC
Created attachment 381140 [details]
ucspi-ssl-0.94-r1.ebuild

fix compability with x86, tested on amd64 & x86
Comment 2 Kristian Fiskerstrand (RETIRED) gentoo-dev 2014-09-04 13:44:46 UTC
(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
Comment 4 Alex Efros 2015-03-31 15:08:24 UTC
(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).
Comment 5 Ian Delaney (RETIRED) gentoo-dev 2015-04-01 13:01:54 UTC
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.
Comment 6 Alex Efros 2015-04-01 13:53:13 UTC
(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.
Comment 7 Alex Efros 2015-04-01 14:55:10 UTC
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
Comment 8 Alex Efros 2015-04-01 14:56:35 UTC
(In reply to Alex Efros from comment #7)
> Differences are:
- set all KEYWORDS to ~ARCH
Comment 9 Ian Delaney (RETIRED) gentoo-dev 2015-04-02 08:24:14 UTC
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
Comment 10 Alex Efros 2015-04-02 23:47:55 UTC
(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
Comment 11 Alex Efros 2015-04-02 23:52:48 UTC
Created attachment 400438 [details]
ucspi-ssl-0.94-r2.ebuild
Comment 12 Ian Delaney (RETIRED) gentoo-dev 2015-04-03 13:56:11 UTC
  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
Comment 13 Agostino Sarubbo gentoo-dev 2015-04-03 15:38:39 UTC
amd64 stable
Comment 14 Jeroen Roovers (RETIRED) gentoo-dev 2015-04-03 19:36:19 UTC
Do what now?
Comment 15 Ian Delaney (RETIRED) gentoo-dev 2015-04-04 01:53:02 UTC
(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.
Comment 16 Yury German Gentoo Infrastructure gentoo-dev 2015-04-04 15:45:45 UTC
Arches, please test and mark stable:

=sys-apps/ucspi-ssl-0.94

Target Keywords : "alpha amd64 arm hppa ia64 ppc ppc64 spark x86"
Comment 17 Agostino Sarubbo gentoo-dev 2015-04-13 09:45:29 UTC
alpha stable
Comment 18 Agostino Sarubbo gentoo-dev 2015-04-14 12:33:04 UTC
ia64 stable
Comment 19 Alex Efros 2015-04-17 06:17:00 UTC
Created attachment 401428 [details]
ucspi-ssl-0.94-r2.ebuild

Proposed fix for bug 545682 (HPPA).
Comment 20 Alex Efros 2015-04-19 02:18:00 UTC
Created attachment 401578 [details, diff]
files/ucspi-ssl-0.94-verbose.patch
Comment 21 Alex Efros 2015-04-19 02:19:24 UTC
Created attachment 401580 [details]
ucspi-ssl-0.94-r2.ebuild

Add ucspi-ssl-0.94-verbose.patch as recommended in bug 546992
Comment 22 Ian Delaney (RETIRED) gentoo-dev 2015-04-19 06:36:46 UTC
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?
Comment 23 Yury German Gentoo Infrastructure gentoo-dev 2015-04-19 12:30:38 UTC
There are both r1 and r2 here, which one you want re-stabilized? Or you can just call yourself.
Comment 24 Pacho Ramos gentoo-dev 2015-04-19 18:52:08 UTC
Looks like -r2 wasn't committed to the tree, -r1 should be the candidate... but is bug 545682 fixed by that revision?
Comment 25 Alex Efros 2015-04-19 21:15:06 UTC
(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.
Comment 26 Ian Delaney (RETIRED) gentoo-dev 2015-04-20 01:25:47 UTC
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
Comment 27 Jeroen Roovers (RETIRED) gentoo-dev 2015-04-20 05:38:13 UTC
Stable for HPPA.
Comment 28 Jeroen Roovers (RETIRED) gentoo-dev 2015-04-20 05:41:36 UTC
  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.
Comment 29 Agostino Sarubbo gentoo-dev 2015-04-20 09:38:25 UTC
(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.
Comment 30 Jeroen Roovers (RETIRED) gentoo-dev 2015-04-21 20:38:27 UTC
Stable for PPC64.
Comment 31 Jeroen Roovers (RETIRED) gentoo-dev 2015-04-21 20:38:58 UTC
(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.
Comment 32 Pacho Ramos gentoo-dev 2015-04-26 16:59:10 UTC
ppc stable
Comment 33 Markus Meier gentoo-dev 2015-05-21 16:31:45 UTC
arm stable
Comment 34 Jack Morgan (RETIRED) gentoo-dev 2015-05-29 04:23:28 UTC
sparc stable
Comment 35 Michael Palimaka (kensington) gentoo-dev 2015-12-08 17:24:44 UTC
Old versions have since been removed.
Comment 36 Yury German Gentoo Infrastructure gentoo-dev 2015-12-31 04:43:22 UTC
GLSA Vote: Yes
New GLSA Request filed.
Comment 37 Aaron Bauman (RETIRED) gentoo-dev 2016-11-17 08:16:50 UTC
I am closing this due to the age of the bug and the vulnerability does not require a GLSA.