Re: OpenSSL 1.0.2j won't connect to Google

> On Oct 4, 2016, at 12:48 AM, S P Arif Sahari Wibowo <arifs...@yahoo.com> > wrote: > > Macports upgraded my OpenSSL to 1.0.2j and now it cannot connect to Google > servers. Other than updating to the latest releases, we have not made any significant changes to the open

Re: apache2 v openssl 1.0.2g

> > should I have a 1.0.2 version of the libssl dylib? Or did the port miss > updating the ssl.so? If I understand the error, it is looking for obsolete > SSLv2 bits that I would assume have been removed from 1.0.2g > openssl was updated without revbumping a whole bunch of dependents

apache2 v openssl 1.0.2g

I did a port selfupdate/port upgrade outdated today. Trying to restart apache2, I get httpd: Syntax error on line 101 of /opt/local/apache2/conf/httpd.conf: Cannot load /opt/local/apache2/modules/mod_ssl.so into server: dlopen(/opt/local/apache2/modules/mod_ssl.so, 10): Symbol not found:

Re: openssl vs. libressl

e I agree with Larry that MacPorts is not a substitute for upstream patches. I've raised the issue on a Qt ML, where for the 1st answer was that it's "the most common [...] to build OpenSSL without" support for SSL2 and SSL3. It hadn't occurred to me, but surely the e

Re: openssl vs. libressl

On Friday November 13 2015 10:45:32 Dominik Reichardt wrote: > from www.libressl.org: > > "LibreSSL is a version of the TLS/crypto stack forked from OpenSSL in 2014, > with goals of modernizing the codebase, improving security, and applying best > practice development

Re: openssl vs. libressl

> On 13.11.2015, at 11:16, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Friday November 13 2015 10:45:32 Dominik Reichardt wrote: > >> from www.libressl.org: >> >> "LibreSSL is a version of the TLS/crypto stack forked from OpenSSL in 2014,

Re: openssl vs. libressl

> Am 13.11.2015 um 12:21 schrieb René J.V. Bertin : > > You're right that it has the same license. I was under the impression that it > didn't, but should have checked. > > If it has the same license, there shouldn't be a difference in binary package > restrictions,

Re: openssl vs. libressl

On Thursday November 12 2015 15:56:58 Jeremy Huddleston Sequoia wrote: If LibreSSL should become the default, the best compromise in this particular case might yet be to provide a variant that allows Qt to build with the shipped OpenSSL version rather than against the "system"

Re: openssl vs. libressl

> On 13.11.2015, at 10:33, René J.V. Bertin <rjvber...@gmail.com> wrote: > > I don't really want into this kind of discussion, but > >> Libressl doesn't "emulate" OpenSSL. It is a derivative of OpenSSL with a >> focus on better architecture and s

Re: openssl vs. libressl

a variant that allows Qt to build with the > shipped OpenSSL version rather than against the "system" (MacPorts) version. No, the best solution for our users is to fix Qt to not force the use of insecure transport encryption like SSLv2 and instead use functions that pick the most se

Re: openssl vs. libressl

erver will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. This is the best choice when compatibility is a concern. >> Why? What problems are you facing? I've been using Libressl exclusively >> and haven't seen issues in anything I use. > > The problem of se

Re: openssl vs. libressl

have had a > different level of urgency. > >It looks like it does. Again, where? >Why? What problems are you facing? I've been using Libressl exclusively and >haven't seen issues in anything I use. The problem of serving as a guinea pig with software that still depends

Re: openssl vs. libressl

On Friday November 13 2015 11:30:59 Jeremy Huddleston Sequoia wrote: > I don't understand what you mean here. These methods *force* the use of > SSLv2 even if secure alternatives are available: > > qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method > qt.network.ssl: QSslSocket:

Re: openssl vs. libressl

ibrary > someone distantly related fundamental science colleague of mine still relies > on and that magically still works with the latest Qt library... :) That is not a relevant case here. That 20+ year old closed-source binary library was linked against something older than OpenSSL itself. OpenSSL wa

Re: openssl vs. libressl

On 2015-11-13, at 1:33 AM, René J.V. Bertin wrote: > Telling it to "stop using them" is not unlike telling Apple they should stop > shipping anything but the latest version of a whole range of things shipped > with the OS (python comes to mind). There's a responsibility to

Re: openssl vs. libressl

On Friday November 13 2015 12:52:07 Dominik Reichardt wrote: > Yes! You must have missed Ryan's post in this thread when he remarked just > that (same license, same restrictions), one or two days ago. Guess so. This only strengthens my conviction that if anything and for the time being, it's

Re: openssl vs. libressl

On Thursday November 12 2015 08:45:19 Jeremy Huddleston Sequoia wrote: > See this ticket for details about Qt5 + Libressl: > > https://github.com/libressl-portable/openbsd/issues/33 And an official statement from a highly visible Qt dev: "Our current position is "our code is

Re: openssl vs. libressl

33 > > And an official statement from a highly visible Qt dev: > > "Our current position is "our code is written for OpenSSL". If you want to > use > something that emulates OpenSSL, the burden is on you to make sure it's a > good > emulation." Li

Re: openssl issues with el capitan

On Nov 12, 2015, at 6:02 AM, Ryan Schmidt wrote: > > On Nov 12, 2015, at 4:52 AM, rinaldo rui wrote: > >> I am installing “root 6” on el capitan and get the following message: >> >> You do not have an OpenSSL installation suitable for building software.

Re: openssl issues with el capitan

On Nov 12, 2015, at 4:52 AM, rinaldo rui wrote: > I am installing “root 6” on el capitan and get the following message: > > You do not have an OpenSSL installation suitable for building software. > It is recommended you do: > > brew install openssl > brew

Re: openssl vs. libressl

On Nov 10, 2015, at 11:59 AM, Jeremy Huddleston Sequoia wrote: > On Nov 10, 2015, at 00:17, Ryan Schmidt wrote: > >> That's not the same situation. If a user had been using glib2 and then later >> needed to switch to glib2-devel for some reason, everything should still >> work. All the ports

openssl issues with el capitan

hello, I am installing “root 6” on el capitan and get the following message: You do not have an OpenSSL installation suitable for building software. It is recommended you do: brew install openssl brew link --force openssl The question is: what is the equivalent command in macports? I have

Re: openssl vs. libressl

not resolve SSLv2_client_method qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method That's with a previously built Qt 5.5.0 though (i.e. with openssl installed), though I don't see how this particular error would go away by building against libressl.

Re: openssl vs. libressl

rom the looks of it, libressl emulates a recent enough openssl version to activate the code that refers to SSL_CTRL_SET_CURVES, but doesn't actually provide the token. R. ___ macports-users mailing list macports-users@lists.macosforge.org ht

Re: openssl vs. libressl

SSL_CTRL_SET_CURVES, > ^ > make[3]: *** [.obj/qsslcontext_openssl.o] Error 1 > > > From the looks of it, libressl emulates a recent enough openssl version to > activate the code that refers to SSL_CTRL_SET_CURVES, but does

Re: openssl vs. libressl

On Tuesday November 10 2015 18:55:51 Jeremy Huddleston Sequoia wrote: >Actually, this won't solve the problem. The entire problem here is that >OpenSSL and Libressl are note compatible. Projects need to be recompiled to >use one or the other. The only way to do this in a way tha

Re: openssl vs. libressl

;>>> On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: >>>> >>>>> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a >>>>> rebuild is needed to make things work, then this >>>> >>>> Yes, but at least on

Re: openssl vs. libressl

cPorts was support productivity on things other than MacPorts itself, and I think that's probably the case for a majority of users. If true, that imposes a rather conservative approach. As I've said before, I fear that patching in a way to support parallel installation of openssl and libressl is

Re: openssl vs. libressl

On Wednesday November 11 2015 08:14:59 Bradley Giesbrecht wrote: > > On Nov 11, 2015, at 4:15 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > I believe most openssl dependent ports are not binary distributable due to > the openssl license. There is indeed some k

Fwd: openssl vs. libressl

rem...@macports.org>, MacPorts Users <macports-users@lists.macosforge.org> > Subject: Re: openssl vs. libressl > >> On Nov 11, 2015, at 4:15 AM, René J.V. Bertin <rjvber...@gmail.com >> <mailto:rjvber...@gmail.com>> wrote: >> >> - when a user

Re: openssl vs. libressl

I agree, but “better license” has nothing to do with that, does it ? My point is we should look at the best technical solution, and THAT should be the only factor. Anything else is ancillary. > On Nov 11, 2015, at 10:54 AM, Brandon Allbery wrote: > > On Wed, Nov 11, 2015

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 12:05 PM, <wood...@gmail.com> wrote: > But in this case, I don’t see one, openssl has been fine being distributed > the way it is, its just that some people want a new-shiny here. So binary archives are a new-shiny with no practical significance. Got it. -

Re: openssl vs. libressl

om >> <mailto:rjvber...@gmail.com>> wrote: >> >> - when a user made the opposite choice (say libressl instead of openssl), >> doing `port install curl` (for example) will translate to `port install curl >> +libressl` which means s/he won't benefit of binary pa

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 11:52 AM, wrote: > I don’t believe a “better license” should be the dictating factor, I > believe what should dictate what is included is what has better > functionality. This is politics, and TBH is not a technical reason for > inclusion or exclusion.

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 11:57 AM, René J.V. <rjvber...@gmail.com> wrote: > On Wednesday November 11 2015 08:14:59 Bradley Giesbrecht wrote: > > > On Nov 11, 2015, at 4:15 AM, René J.V. Bertin <rjvber...@gmail.com> > wrote: > > > I believe most openssl dependen

Re: openssl vs. libressl

But in this case, I don’t see one, openssl has been fine being distributed > the way it is, its just that some people want a new-shiny here. > > So binary archives are a new-shiny with no practical significance. Got it. > > -- > brandon s allbery kf8nh

Re: openssl vs. libressl

On Wed, Nov 11, 2015 at 12:00 PM, wrote: > I agree, but “better license” has nothing to do with that, does it ? It is the license that blocks binary distribution, with specific exemptions. Oddly enough, licenses are not merely political noise; they actually have practical

Re: openssl vs. libressl

But in this case, I don’t see one, openssl has been fine being distributed the way it is, its just that some people want a new-shiny here. > On Nov 11, 2015, at 11:00 AM, Brandon Allbery <allber...@gmail.com> wrote: > > On Wed, Nov 11, 2015 at 12:00 PM, <wood...@gmail.c

Re: openssl vs. libressl

future, and preferably not until it's become more common mainstream Linux distributions that also use binary packages. My suggestion with the automagically set default variants was made with the idea that it'd be a temporary solution to facilitate testing the use of libressl instead of openssl

Re: openssl vs. libressl

> On Nov 11, 2015, at 4:15 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > - when a user made the opposite choice (say libressl instead of openssl), > doing `port install curl` (for example) will translate to `port install curl > +libressl` which means s/he wo

Re: openssl vs. libressl

acPorts is a bug, not a >> solution. > > ?? Why? > It leaves the educated user with a choice regardless of which of openssl or > libressl is the default/preferred flavour. That is always a good thing IMHO. It is a bad thing when users who exercise a choice run into pro

Re: openssl vs. libressl

as support productivity > on things other than MacPorts itself, and I think that's probably the case > for a majority of users. If true, that imposes a rather conservative approach. > > As I've said before, I fear that patching in a way to support parallel > installation of open

Re: openssl vs. libressl

that users who don't need poppler support in graphviz will now be able to get a binary of graphviz instead of having to build it from source. Many users want this convenience. Those users who require poppler support in graphviz can use the +poppler variant. Both openssl and libressl are licensed

Re: openssl vs. libressl

On Tuesday November 10 2015 09:27:27 Brandon Allbery wrote: > As quoted from Rainer Müller: > > See both the official statement and a blog post from a Gentoo developer > > explaining the problem: Right ... exactly the same posts I found myself. I was looking for a link to gentoo.org or

Re: openssl vs. libressl

On 2015-11-10 15:21, Daniel J. Luke wrote: > We could have a port “mp-ssl-lib” that defaults to depending on one > of the ssl libs (say openssl). It could also be installed as > mp-ssl-lib +libressl which would modify it’s dependencies and install > libressl and not openssl. > >

Re: openssl vs. libressl

dt wrote: >>> >>>> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a >>>> rebuild is needed to make things work, then this >>> >>> Yes, but at least on Linux libressl installs libraries with different >>> numbers (l

Re: openssl vs. libressl

ary archives built with the default option would not > work on a system with a different variant choice on mp-ssl-lib. > > Explicit variants in all ports are the only way to prevent that, as the > port contents will actually be different depending on whether you link > against open

Re: openssl vs. libressl

On Nov 9, 2015, at 6:10 PM, Jeremy Huddleston Sequoia wrote: > On Nov 9, 2015, at 13:10, René J.V. Bertin wrote: > >> On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: >> >>> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a >>&

Re: openssl vs. libressl

erything should still Indeed. Still, the mod Jeremy introduced is the best/only way I know to allow choice that doesn't involve introducing an SSL PortGroup that provides +openssl and +libressl variants. >I don't know how carefully the ffmpeg developers version their software. Neither do I,

Re: openssl vs. libressl

er > explaining the problem: > > https://github.com/libressl-portable/portable#compatibility-with-openssl > > > https://blog.flameeyes.eu/2014/07/libressl-drop-in-and-abi-leakage > -- brandon s allbery kf8nh sine n

Re: openssl vs. libressl

On Tuesday November 10 2015 09:21:19 Daniel J. Luke wrote: >Other ports would all depend on ‘mp-ssl-lib’ and not directly only openssl or >libressl. > >It’s not a perfect solution, but may be nicer than adding +openssl/+libressl >to every possible port. Hmmm, I shou

Re: openssl vs. libressl

choice regardless of which of openssl or libressl is the default/preferred flavour. That is always a good thing IMHO. > It might be better to take the choice away from the user and just make a > decision that we want libressl to be our default ssl library in MacPorts. > Change the li

Re: openssl vs. libressl

On Nov 10, 2015, at 5:12 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > Indeed. Still, the mod Jeremy introduced is the best/only way I know to allow > choice that doesn't involve introducing an SSL PortGroup that provides > +openssl and +libressl variants. One other way to

Re: openssl vs. libressl

olve introducing an SSL PortGroup that provides >> +openssl and +libressl variants. > > One other way to handle it would be how we tried to handle perl5 for a while > (which doesn’t really work that well for perl, but may apply here). > > We could have a port “mp-ssl-lib” tha

Re: openssl vs. libressl

On Monday November 09 2015 15:27:54 Ryan Schmidt wrote: > > Interesting. I think it was FreeBSD that tried to do that (both API and > > ABI) and failed at both, and said rebuild stuff for one or the other. > > Apparently they were the ones who made the mistake, and it actually works > > if

Re: openssl vs. libressl

ports . You should not do this. It might work for some binaries, but it is not guaranteed to work in all cases. See both the official statement and a blog post from a Gentoo developer explaining the problem: https://github.com/libressl-portable/portable#compatibility-with-openssl https://blog.fl

Re: openssl vs. libressl

On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: > In r139229 Jeremy made libressl a drop-in replacement for openssl. If a > rebuild is needed to make things work, then this Yes, but at least on Linux libressl installs libraries with different numbers (libssl.so.35 vs libssl.so

Re: openssl vs. libressl

On Nov 9, 2015, at 3:12 PM, Brandon Allbery wrote: > On Mon, Nov 9, 2015 at 4:05 PM, Ryan Schmidt wrote: >> In r139229 Jeremy made libressl a drop-in replacement for openssl. > > Interesting. I think it was FreeBSD that tried to do that (both API and ABI) > and failed at both

Re: openssl vs. libressl

On Monday November 09 2015 16:11:54 Jeremy Huddleston Sequoia wrote: hi, > > Now what if you do > > > > %> ln -s libssl.35.dylib libssl.1.0.0.dylib ? > > > > (assuming that libressl indeed installs libssl.35.dylib) > > > > If that works, it can be handled with a very simple post-destroot

Re: openssl vs. libressl

On Mon, Nov 9, 2015 at 8:31 PM, René J.V. wrote: > First quick tests (downloading a couple of release tarballs from github, > with /opt/local/bin/curl) suggests that it works. Which doesn't really > surprise me too much: both libraries are written in C. As long as dependent

Re: openssl vs. libressl

On Mon, Nov 9, 2015 at 3:39 PM, René J.V. <rjvber...@gmail.com> wrote: > I understand that libressl aims to be API-compatible with openssl so that > it can act as a drop-in replacement. How far does that go, far enough that > one can symlink the libssl and libcrypto runtimes fr

openssl vs. libressl

Hi, I understand that libressl aims to be API-compatible with openssl so that it can act as a drop-in replacement. How far does that go, far enough that one can symlink the libssl and libcrypto runtimes from the one port to the shared libraries of the other, without having to rebuild

Re: openssl vs. libressl

aries are written in C. As long as dependent software > sticks to public APIs (and those APIs are indeed compatible), the binary > libraries should be compatible too, regardless of how different they are > "behind the scenes". The problem is that while the API is compatible, the ABI

Re: openssl vs. libressl

On Nov 9, 2015, at 2:43 PM, Brandon Allbery wrote: > On Mon, Nov 9, 2015 at 3:39 PM, René J.V. wrote: >> I understand that libressl aims to be API-compatible with openssl so that it >> can act as a drop-in replacement. How far does that go, far enough that one >> c

Re: openssl vs. libressl

On Mon, Nov 9, 2015 at 4:05 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > In r139229 Jeremy made libressl a drop-in replacement for openssl. Interesting. I think it was FreeBSD that tried to do that (both API and ABI) and failed at both, and said rebuild stuff for one or

Re: openssl vs. libressl

> On Nov 9, 2015, at 13:40, René J.V. Bertin wrote: > > On Monday November 09 2015 15:27:54 Ryan Schmidt wrote: > >>> Interesting. I think it was FreeBSD that tried to do that (both API and >>> ABI) and failed at both, and said rebuild stuff for one or the other. >>>

Re: openssl vs. libressl

> On Nov 9, 2015, at 13:10, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: > >> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a >> rebuild is needed to make things work, then this &

Re: openssl - could not find the C header files

> Anyway, I gave up compiling it myself and installed tor 0.2.6.9_1 through > MacPorts. > To keep all my stuff I just copied then the tor binary to the previous tor > 0.2.6.6 (git-bb8c4e69ca5c8bca), which I compiled myself before. > > mv /usr/local/bin/tor /usr/local/bin/tor.old > cp

Re: openssl - could not find the C header files

> Am 18.10.2015 um 09:44 schrieb Jeremy Huddleston Sequoia > <jerem...@macports.org>: > > No, OS X does not ship with Libressl. OS X 10.11 ships with OpenSSL 0.9.8zg > at /usr/lib/libssl.0.9.8.dylib and OpenSSL 0.9.7l at > /usr/lib/libssl.0.9.7.dylib. These binaries

Re: openssl - could not find the C header files

> Am 18.10.2015 um 09:44 schrieb Jeremy Huddleston Sequoia > <jerem...@macports.org>: >>> >>> You probably got the system OpenSSL the last time you built it. 10.11 >>> doesn't have OpenSSL any more (I think it has LibreSSL? which is not 100% >>

Re: openssl - could not find the C header files

It looks like tor uses "--with-openssl-dir". There are a couple other packages you might want to install in macports and specify similarly: libevent, zlib, libminiupnpc On Sat, Oct 17, 2015 at 1:44 PM, Brandon Allbery <allber...@gmail.com> wrote: > On Sat, Oct 17, 2015 at

Re: openssl - could not find the C header files

On Oct 17, 2015, at 6:00 PM, Frank Röhm wrote: > Yes there still seems to be openssl in 10.11, but old version, OpenSSL > 0.9.8zg 14 July 2015 find I in /usr/bin/openssl > I renamed it to …OLD and linked the macports openssl to this path. > > MacBook:tor-0.2.7.3-rc f$ ls -al /

Re: openssl - could not find the C header files

> On Oct 17, 2015, at 16:00, Frank Röhm <francwal...@gmx.net> wrote: > > >> Am 17.10.2015 um 20:44 schrieb Brandon Allbery <allber...@gmail.com>: >> >> On Sat, Oct 17, 2015 at 2:24 PM, Frank Röhm <francwal...@gmx.net> wrote: >> checking fo

Re: openssl - could not find the C header files

On Sat, Oct 17, 2015 at 7:00 PM, Frank Röhm <francwal...@gmx.net> wrote: > MacBook:tor-0.2.7.3-rc root# ./configure --with-openssl=/opt/local > configure: WARNING: unrecognized options: --with-openssl > I haven't built tor, so I was guessing as to the configure option (I sp

Re: openssl - could not find the C header files

> Am 17.10.2015 um 20:44 schrieb Brandon Allbery <allber...@gmail.com>: > > On Sat, Oct 17, 2015 at 2:24 PM, Frank Röhm <francwal...@gmx.net> wrote: > checking for openssl directory... configure: WARNING: We found the libraries > for openssl, but we could not find t

openssl - could not find the C header files

/configure” in the tor source dir, I get this error: ... checking for openssl directory... configure: WARNING: We found the libraries for openssl, but we could not find the C header files. You may need to install a devel package. configure: error: Missing headers; unable to proceed. openssl is

Re: openssl - could not find the C header files

On Sat, Oct 17, 2015 at 2:24 PM, Frank Röhm <francwal...@gmx.net> wrote: > checking for openssl directory... configure: WARNING: We found the > libraries for openssl, but we could not find the C header files. You may > need to install a devel package. > configure: error: Missi

Re: openssl - could not find the C header files

It's probably not related to your current problem, but I wanted to point out: On Oct 17, 2015, at 1:24 PM, Frank Röhm wrote: > openssl is installed: > > MacBook:dports root# port list installed > ... > openssl@1.0.2d devel/openssl > … Th

Fwd: Fwd: Bug in openssl s_client verification

/contact.php does not use the word secure or security. -- Forwarded message -- From: Jeffrey Walton noloa...@gmail.com Date: Thu, Jul 9, 2015 at 7:20 AM Subject: Re: Fwd: Bug in openssl s_client verification To: sec...@macports.org, secur...@macports.org Cc: Matt Caswell m

Re: Bug in openssl s_client verification

bothered them to set up this alias. Since we don't have a dedicated security group there is no separate mailing list where these addresses would go to anyway. Instead, the OpenSSL maintainers in MacPorts are the correct points of contact here. -- Forwarded message -- From

kdepim4-runtime upgrade failure on 10.9.x due to non-upgraded openssl and webkit-gtk

openssl1.0.1g_0 1.0.1h_0 py-sip 4.15.5_0 4.16.1_0 py26-sip 4.15.5_0 4.16.1_0 py27-gdbm 2.7.6_0 2.7.7_0 py27-jinja22.7.2_0 2.7.3_0 py27

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

Hi Clemens, - Dovecot still has an old copy of OpenSSL embedded that it uses for those places that handle the TLS connection. I think that one is unlikely given that you did rebuild dovecot and that it has been revbumped. Nevertheless you should be able to rule it out by re

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

Am 28.04.14 10:27, schrieb Winfried Dietmayer: This is all really weird. Thank you so far for your help , any further help is of course much appreciated. Not sure, if this helps, but i just installed dovecot freshly from macports on 10.9.2 with the default configuration, and it does not seem

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

Hi Winfried I reinstalled dovecot from the MacPorts packages server but to no avail. The vulnerability is still there. OK, so we know it's not a statically linked OpenSSL (at least not in dovecot, it might still be in one of dovecot's dependencies). Since those are only libiconv, zlib

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

MacPort or via the original tarballs. - apache is not vulnerable using the same OpenSSL library. - dovecot is not vulnerable if the machine is safe-booted. This is all really weird. I haven't read the whole thread in detail, so surely this has been done already - did you check what openssl

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

: /opt/local/lib/libssl.1.0.0.dylib Apr 23 10:55:55 Winfrieds-.local dovecot[66453]: imap-login: Error: dyld: loaded: /opt/local/lib/libcrypto.1.0.0.dylib If the path is the same, please run $ strings /opt/local/lib/libssl.1.0.0.dylib | grep 'OpenSSL' and paste the output

Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

Hello, I use the following version of dovecot2 and OpenSSL: $ port installed | egrep dovecot|openssl -- dovecot2 @2.2.12_0 (active) -- openssl @1.0.1g_0 (active) I attack the dovecot server: $ ./cardiac-arrest.py -a -p 993 localhost | grep -i fail -- [FAIL

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

Hi, I use the following version of dovecot2 and OpenSSL: $ port installed | egrep dovecot|openssl -- dovecot2 @2.2.12_0 (active) -- openssl @1.0.1g_0 (active) I attack the dovecot server: $ ./cardiac-arrest.py -a -p 993 localhost | grep -i fail

Re: Heartbleed: dovecot2 is still vulnerable after upgrade of OpenSSL library

Hi Clemens, thank you for your quick response. But I’m not sure whether you are right. I forced a rebuild of first the OpenSSL library and then of dovecot. I already posted the result. According to your proposition this should have solved the issue. But it didn’t. dovecot2 does link

Re: OpenSSL

On 8. April 2014 05:34:28 MESZ, Ludwig macpo...@metaspasm.org wrote: What else do I need to do about the addressed vulnerability besides updating the port — generate new keys or what? ...as far as i informed about the current security notice / patch in OpenSSH (!) it makes no sense to generate

Re: OpenSSL

Hello, I wonder, how feasible would it be to replace the system OpenSSL with the one from MacPorts? If security updates are pushed this quickly it would make sense for just about any OS X version, but even more so for those of us still running 10.6 ... R. On Tuesday April 08 2014 08:24:16

Re: OpenSSL

In article 2628775.Ob0fHhrzob@patux, René J.V. Bertin rjvber...@gmail.com wrote: I wonder, how feasible would it be to replace the system OpenSSL with the one from MacPorts? If security updates are pushed this quickly it would make sense for just about any OS X version, but even more so

OpenSSL

to heartbleed.com, any data that was in the memory of the process using openssl could have been revealed to an attacker. That would include private keys. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org https

Re: OpenSSL

in curcumstances that a new client connects to a DNS faked host when not verifying the host key fingerprint during the host verifying process. According to heartbleed.com, any data that was in the memory of the process using openssl could have been revealed to an attacker. That would include private

Re: OpenSSL

On Monday April 07 2014 23:58:37 Ned Deily wrote: Don't even think of that! First, as you may know, most Apple-supplied programs don't use OpenSSL anyway (at least since 10.7 when it was This I didn't know ... officially deprecated). Second, the Heartbleed bug only applies to OpenSSL

Re: OpenSSL

[Niels Dettenbach n...@syndicat.com (2014-04-08 12:46:27 UTC)] Anyhow: where server secret keys could be changed more easily (i.e. SSH host keys) this should be done. But ssh does not use the openssl libraries, so there is no point, as this bug will not have exposed the ssh host keys

Re: OpenSSL

On Tue, Apr 8, 2014 at 2:03 PM, Harald Hanche-Olsen han...@math.ntnu.nowrote: But ssh does not use the openssl libraries, so there is no point, as this bug will not have exposed the ssh host keys. Actually, it does use the libraries. But only for crypto; it does not use the SSL protocol

Re: OpenSSL

Am Dienstag, 8. April 2014, 20:03:30 schrieb Harald Hanche-Olsen: But ssh does not use the openssl libraries, so there is no point, as this bug will not have exposed the ssh host keys. hmm, i'm not deep into the OpenSSH developement yet, but i thought that OpenSSH does even use (or at least

Re: OpenSSL

On Apr 8, 2014, at 11:31 AM, Niels Dettenbach wrote: Am Dienstag, 8. April 2014, 20:03:30 schrieb Harald Hanche-Olsen: But ssh does not use the openssl libraries, so there is no point, as this bug will not have exposed the ssh host keys. hmm, i'm not deep into the OpenSSH developement yet

Re: OpenSSL

On Tue, Apr 8, 2014 at 2:49 PM, Kastus Shchuka macpo...@tprfct.net wrote: On Apr 8, 2014, at 11:31 AM, Niels Dettenbach wrote: But as far as i can read til now OpenSSH uses OpenSSL code not related to TLS/SSL or the ASN.1 parser which is affected here - but yesterday and today some

  1   2   3   >