Re: Problems with openssl 1.0.2 update

[Dr. Peter Voigt]

On Tue, 24 Mar 2015 11:14:03 +1100
Kubilay Kocak  wrote:

> On 24/03/2015 12:53 AM, Gerhard Schmidt wrote:
> > On 23.03.2015 14:17, Mike Tancsa wrote:
> >> On 3/23/2015 6:33 AM, Gerhard Schmidt wrote:
> >>> Hi,
> >>>
> >>> we experiencing a problem after upgrading  the openssl port to
> >>> openssl 1.0.2.
> >>>
> >>> /usr/bin/vi started to crash after some seconds with segfault.
> >>
> >> Is you vi linked to openssl ?
> >>
> 
> Let's get this into an issue report @ Bugzilla
> 
> Please add this mailing lists threads URL to the issue report in the
> URL field as well
> 
> Koobs
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscr...@freebsd.org"

Well, I have added already PR 198788

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198788
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Kubilay Kocak]

On 24/03/2015 12:53 AM, Gerhard Schmidt wrote:
> On 23.03.2015 14:17, Mike Tancsa wrote:
>> On 3/23/2015 6:33 AM, Gerhard Schmidt wrote:
>>> Hi,
>>>
>>> we experiencing a problem after upgrading  the openssl port to openssl
>>> 1.0.2.
>>>
>>> /usr/bin/vi started to crash after some seconds with segfault.
>>
>> Is you vi linked to openssl ?
>>

Let's get this into an issue report @ Bugzilla

Please add this mailing lists threads URL to the issue report in the URL
field as well

Koobs

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Matt Smith]

On Mar 23 11:36, Matt Smith wrote:

On Mar 23 11:33, Gerhard Schmidt wrote:

Hi,

we experiencing a problem after upgrading  the openssl port to openssl
1.0.2.

/usr/bin/vi started to crash after some seconds with segfault.
/rescue/vi works just fine. Deleting the openssl 1.0.2 package
everything works just fine again. Installing the old openssl 1.0.1_18
package it still works just fine.

it seams that besides vi the bash also has this problem. Anybody
experiencing the same or is this something specific to my system.

I'm running FreeBSD 10.1 updated tonight.



There is definitely something not right. See this too 
https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/

I haven't had a chance yet to test it again in more detail, but 
someone reported that postfix was broken, and I had PHP-FPM racing and 
taking up 50+ load average on my box which I guess was probably nginx 
hitting it with tons of requests. Mine is 10.1-STABLE amd64.




I've just reinstalled openssl 1.0.2, and recompiled all ports that link 
to openssl. And I'm still getting huge problems. PHP-FPM races and 
starts loads of processes and uses 50+ load average making the machine 
unresponsive. And trying to run a /bin/sh shell script gives this:


sh: environment corrupt; missing value for USERNAME

This is clearly very dangerous and broken. Backing out to openssl 1.0.1 
fixes everything.



--
Matt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: On-going laptop brightness issues

[Bigby James]

I just saw that this feature got MFC'd in revision r280369 this afternoon. I've 
been
keeping an eye on it, as it's pretty much the only feature that hasn't worked
properly on my laptop and so the last remaining bit I needed for the "Golden
FreeBSD Experience." I want to give my thanks to the developers involved, as 
well
as to Kevin, who's been following this longer---and done more about
it---than I have. Just another reason to love this OS, its community and its
hard-working contributors. I've yet to update my systems in response to the
OpenSSL security advisory, so I'll back up my local source tree and start with a
clean pull this evening, and check back in a few days to report how things are
working. Thanks again, all. Take care.

-- 
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Jenkins build is back to normal : FreeBSD_stable_10 #1303

[jenkins-admin]

See 

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Dr. Peter Voigt]

On Mon, 23 Mar 2015 12:04:33 +0100
Kurt Jaeger  wrote:

> Hi!
> 
> > we experiencing a problem after upgrading  the openssl port to
> > openssl 1.0.2.
> 
> I have 1.0.2 installed on my testbox.
> 
> vi works fine.
> 
> > /usr/bin/vi started to crash after some seconds with segfault.
> 
> Do you have a coredump ?
> 

Do you use openldap authentication? I do.

I could even rebuild all ports depending on openssl - with the
exception of postfix. I found that disabling openldap support for
postfix sovled this.

But after some time I found lots of programs and services core dumping
- including vim and base vi.

As I was not sure what and how to downgrade I restored my UFS2 root
partition from a 24 h old dump.

Regards,
Peter
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Guido Falsi]

On 03/23/15 13:40, Guido Falsi wrote:
> On 03/23/15 11:33, Gerhard Schmidt wrote:
>> Hi,
>>
>> we experiencing a problem after upgrading  the openssl port to openssl
>> 1.0.2.
>>
>> /usr/bin/vi started to crash after some seconds with segfault.
>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package
>> everything works just fine again. Installing the old openssl 1.0.1_18
>> package it still works just fine.
>>
>> it seams that besides vi the bash also has this problem. Anybody
>> experiencing the same or is this something specific to my system.
>>
>> I'm running FreeBSD 10.1 updated tonight.
> 
> I am seeing runtime problems with asterisk13 (which I maintain), caused
> by the OpenSSL update fallout.
> 
> In this case, after some analysis, I concluded the problem is the
> libsrtp port requiring OpenSSL from ports(for a reason), causing
> asterisk to link to that too, which would be correct.
> 
> Asterisk also uses the security/trousers port, which links to system
> OpenSSL. This ensues a conflict which now results in asterisk
> segfaulting and stopping to work.
> 
> I'm investigating what can be done about this. As a local solution I can
> force the trousers port to link against OpenSSL from ports, but this
> will not fix the general problem. As a port maintaner I ony see
> modifying the trousers port to depend on ports OpenSSL as a solution, is
> this acceptable?
> 

Quick followup to keep anyone interested informed(and for ML archives
just in case).

The only "fix" I could commit to fix the binary package was removing the
SRTP option from the defaults, avoiding to pull in the libsrtp port
which itself pulled in OpenSSL from ports, causing the library mix.

I'm not proud of such a solution, but was unable to do anything better
right away. If someone has a better solution, please send patches.

So for now anyone wanting to use SRTP with asterisk will have to build
his own packages. :(

-- 
Guido Falsi 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Help debugging stable/10

[Shane Ambler]

On 25/12/2014 23:03, Andriy Gapon wrote:

On 25/12/2014 11:29, Hans Petter Selasky wrote:

The cam_sim_free() is stuck, blocking the rest of that controller from
enumerating. It might look like a non-USB stack issue.

MAV: Do you have some ideas where to start looking, now we have a dump? Any
refcounts to check in particular?


Apparently sim->refcount > 0.
Not sure how to check who has the reference(s).



I am now running
FreeBSD leader.local 10.1-STABLE FreeBSD 10.1-STABLE #4 r279865: Thu
Mar 12 14:25:28 ACDT 2015 root@leader.local:/usr/obj/usr/src/sys
/GENERIC  amd64

I have just tried running with a custom kernel, GENERIC plus DDB GDB
DEADLKRES INVARIANTS INVARIANT_SUPPORT WITNESS WITNESS_SKIPSPIN

When starting Xorg I got a duplicate lock message coming from nvidia,
after running for maybe 20 mins it just reset without warning. I then
decided to go back to the GENERIC kernel and on restarting I got some
lock reversal messages.

nvidia-driver-346.47

nvidia0:  on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: Boot video device
hdac0:  mem 0xfb08-0xfb083fff irq 17 at 
device 0.1 on pci1


Full dmesg and other kgdb outputs I have collected are at -
http://shaneware.biz/freebsddebugdata/


Trying to mount root from zfs:zrpleader []...
ums0: 4> on usbus2

ums0: 3 buttons and [XYZ] coordinates ID=0
ums1:  on usbus2
ums1: 6 buttons and [XY] coordinates ID=1
uhid0:  on usbus2
uhid1:  on 
usbus2

uhid0: at uhub5, port 2, addr 5 (disconnected)
ums1: at uhub5, port 2, addr 5 (disconnected)
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to 
deny, logging disabled

acquiring duplicate lock of same type: "os.lock_sx"
 1st os.lock_sx @ nvidia_os.c:609
 2nd os.lock_sx @ nvidia_os.c:609
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe0238b8d400

kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238b8d4b0
witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe0238b8d540
_sx_xlock() at _sx_xlock+0x75/frame 0xfe0238b8d580
os_acquire_mutex() at os_acquire_mutex+0x32/frame 0xfe0238b8d5a0
_nv010785rm() at _nv010785rm+0x18/frame 0xfe000f2fee90
dmapbase() at 0xf8001cc40e80/frame 0xf8001cc40e18
kernphys() at 0xc1d1/frame 0xf8001cc40e00
(null)() at 0xfec5e000/frame 0xc1d10001
acquiring duplicate lock of same type: "os.lock_mtx"
 1st os.lock_mtx @ nvidia_os.c:783
 2nd os.lock_mtx @ nvidia_os.c:783
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe0238b8d0e0

kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238b8d190
witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe0238b8d220
__mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfe0238b8d270
os_acquire_spinlock() at os_acquire_spinlock+0x1b/frame 0xfe0238b8d280
_nv012385rm() at _nv012385rm+0xd75/frame 0xfebceef0
pid 3568 (gsettings-data-conv), uid 1001: exited on signal 5




Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system 
process `vnlru' to stop...done
Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system 
process `bufdaemon' to stop...done
Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system 
process `syncer' to stop...
Mar 24 00:24:25 leader kernel: Syncing disks, vnodes remaining...0 0 0 0 
0 0 0 0 done

Mar 24 00:24:25 leader kernel: All buffers synced.
Mar 24 00:24:25 leader kernel: lock order reversal:
Mar 24 00:24:25 leader kernel: 1st 0xf800224555f0 zfs (zfs) @ 
/usr/src/sys/kern/vfs_mount.c:1229
Mar 24 00:24:25 leader kernel: 2nd 0xf800222d67c8 syncer (syncer) @ 
/usr/src/sys/kern/vfs_subr.c:2268

Mar 24 00:24:25 leader kernel: KDB: stack backtrace:
Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at 
db_trace_self_wrapper+0x2b/frame 0xfe022df6e4c0
Mar 24 00:24:25 leader kernel: kdb_backtrace() at 
kdb_backtrace+0x39/frame 0xfe022df6e570
Mar 24 00:24:25 leader kernel: witness_checkorder() at 
witness_checkorder+0xdc2/frame 0xfe022df6e600
Mar 24 00:24:25 leader kernel: __lockmgr_args() at 
__lockmgr_args+0x9ea/frame 0xfe022df6e740
Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 
0xfe022df6e760
Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at 
VOP_LOCK1_APV+0xfc/frame 0xfe022df6e790
Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 
0xfe022df6e800
Mar 24 00:24:25 leader kernel: vputx() at vputx+0x232/frame 
0xfe022df6e860
Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x301/frame 
0xfe022df6e8e0
Mar 24 00:24:25 leader kernel: vfs_unmountall() at 
vfs_unmountall+0x61/frame 0xfe022df6e910
Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 
0xfe022df6e980
Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 
0xfe022df6e9a0
Mar 24 00:24:25 leader kernel: amd64_syscall() at 
amd64_syscall+0x25a/frame 0xfe022df6eab0
Mar 24 0

Re: Problems with openssl 1.0.2 update

[Steven Hartland]

On 23/03/2015 14:38, Gerhard Schmidt wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23.03.2015 15:14, Dewayne Geraghty wrote:


On 24/03/2015 12:16 AM, Gerhard Schmidt wrote:

On 23.03.2015 13:40, Guido Falsi wrote:

On 03/23/15 11:33, Gerhard Schmidt wrote:

Hi,

we experiencing a problem after upgrading  the openssl port to openssl
1.0.2.

/usr/bin/vi started to crash after some seconds with segfault.
/rescue/vi works just fine. Deleting the openssl 1.0.2 package
everything works just fine again. Installing the old openssl 1.0.1_18
package it still works just fine.

it seams that besides vi the bash also has this problem. Anybody
experiencing the same or is this something specific to my system.

I'm running FreeBSD 10.1 updated tonight.

I am seeing runtime problems with asterisk13 (which I maintain), caused
by the OpenSSL update fallout.

In this case, after some analysis, I concluded the problem is the
libsrtp port requiring OpenSSL from ports(for a reason), causing
asterisk to link to that too, which would be correct.

Asterisk also uses the security/trousers port, which links to system
OpenSSL. This ensues a conflict which now results in asterisk
segfaulting and stopping to work.

I'm investigating what can be done about this. As a local solution I can
force the trousers port to link against OpenSSL from ports, but this
will not fix the general problem. As a port maintaner I ony see
modifying the trousers port to depend on ports OpenSSL as a solution, is
this acceptable?


Most Ports link against the port openssl if its installed and agains the
system openssl if not. That should be the prefered way to handle problem.

I don't know if an incompatibility between system an port openssl is a
problem. I've removed the portbuild openssl from this server completely.

As far as i can see the problem is with openldap-client build agains the
ports openssl and used by nss_ldap or pam_ldap modul. I will do some
testing when my test host is ready. Testing on an Production server is
not that good :-)

Regards
Estartu



I only use openssl from ports and have just completed a rebuild of 662
packages for server requirements and include: trousers, ldap client and
server, and 71 other ports built without any issues on amd64 10.1Stable
using clang.  Not so successful on i386 but I don't believe its related
to openssl.

I never had an issue building anything. Using it is the problem. Setup
authentication via ldap (nss_ldap) and you are in hell. Bash crashes
when you try to login. vi crashes when you try to change a file.
Anything that uses nsswitch has some problems.

Does rebuilding all ports with WITH_OPENSSL_PORT=yes set in 
/etc/make.conf help?


Regards
Steve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Gerhard Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23.03.2015 15:14, Dewayne Geraghty wrote:
> 
> 
> On 24/03/2015 12:16 AM, Gerhard Schmidt wrote:
>> On 23.03.2015 13:40, Guido Falsi wrote:
>>> On 03/23/15 11:33, Gerhard Schmidt wrote:
 Hi,

 we experiencing a problem after upgrading  the openssl port to openssl
 1.0.2.

 /usr/bin/vi started to crash after some seconds with segfault.
 /rescue/vi works just fine. Deleting the openssl 1.0.2 package
 everything works just fine again. Installing the old openssl 1.0.1_18
 package it still works just fine.

 it seams that besides vi the bash also has this problem. Anybody
 experiencing the same or is this something specific to my system.

 I'm running FreeBSD 10.1 updated tonight.
>>> I am seeing runtime problems with asterisk13 (which I maintain), caused
>>> by the OpenSSL update fallout.
>>>
>>> In this case, after some analysis, I concluded the problem is the
>>> libsrtp port requiring OpenSSL from ports(for a reason), causing
>>> asterisk to link to that too, which would be correct.
>>>
>>> Asterisk also uses the security/trousers port, which links to system
>>> OpenSSL. This ensues a conflict which now results in asterisk
>>> segfaulting and stopping to work.
>>>
>>> I'm investigating what can be done about this. As a local solution I can
>>> force the trousers port to link against OpenSSL from ports, but this
>>> will not fix the general problem. As a port maintaner I ony see
>>> modifying the trousers port to depend on ports OpenSSL as a solution, is
>>> this acceptable?
>>>
>> Most Ports link against the port openssl if its installed and agains the
>> system openssl if not. That should be the prefered way to handle problem.
>>
>> I don't know if an incompatibility between system an port openssl is a
>> problem. I've removed the portbuild openssl from this server completely.
>>
>> As far as i can see the problem is with openldap-client build agains the
>> ports openssl and used by nss_ldap or pam_ldap modul. I will do some
>> testing when my test host is ready. Testing on an Production server is
>> not that good :-)
>>
>> Regards
>>Estartu
>>
>>
> I only use openssl from ports and have just completed a rebuild of 662
> packages for server requirements and include: trousers, ldap client and
> server, and 71 other ports built without any issues on amd64 10.1Stable
> using clang.  Not so successful on i386 but I don't believe its related
> to openssl.

I never had an issue building anything. Using it is the problem. Setup
authentication via ldap (nss_ldap) and you are in hell. Bash crashes
when you try to login. vi crashes when you try to change a file.
Anything that uses nsswitch has some problems.

Regards
  Estartu
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVECVNAAoJEHTSQ8xFcA2jj6MP/ifZj6q3sK96ak6KQQezM466
kRC/YuCJymzSv30HbAu2P5i2Qmkaqz/72BCVZ+YhS1n4FBw9TxHrnCI77jO94y9P
55pfvSvYzKk6sLkWEOsbqWjPLQcrTUpfHjWHC3d0uvlzVNnyiYoHGBscWMpIvpoG
Jz+yV8NsJEU5Zm4YSRzOd9VM2xaLi+dBSdSmOvWTp77Oa7Rd4vYrDypcPmA2RXa7
cfTU4OBj3XdYgKF0D4E3I0xcqhvlBAgB806oVeWS7xsI3T7X3ZABBWxPf6ErPDOr
a3hSjl3ZyRMku+4wSvqclWQ1GCrUh33oP5UELD81nPnci7RCxIGoUo3OiZTXvzy+
Oh12eTmEpZrpYo0QALV8Z2oxhlzWm91/iIYnfx9wr6Hk9EHYyNWlckwndfFGVcC0
bJ6KmnX3CbcxKN6RPYG38bNFJ5X9v2gqsqJFKy98KHhBlJ3O49OBzHLzFsaN7r24
TbUzwPrK3qIntMgQF5Y8uD7a1mkjpcG0H/3iwB4QZnWS9WMiynIQqTow6EeIEBgj
0TMHFWkbPetn9h9kxbF+XWf10ARVr0kH9OrTZ+2iO2B+uQb65gC5qRno/WWHBmCp
MSuez+SPv3JIu7ArX9nzpEtG1wQd+r3uiGjX2YB2/kw+a+cX3/B1kWk1R1R1F5Qv
/ImcsZjxeR3aNKcDsz9F
=TQFs
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Dewayne Geraghty]

On 24/03/2015 12:16 AM, Gerhard Schmidt wrote:
> On 23.03.2015 13:40, Guido Falsi wrote:
>> On 03/23/15 11:33, Gerhard Schmidt wrote:
>>> Hi,
>>>
>>> we experiencing a problem after upgrading  the openssl port to openssl
>>> 1.0.2.
>>>
>>> /usr/bin/vi started to crash after some seconds with segfault.
>>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package
>>> everything works just fine again. Installing the old openssl 1.0.1_18
>>> package it still works just fine.
>>>
>>> it seams that besides vi the bash also has this problem. Anybody
>>> experiencing the same or is this something specific to my system.
>>>
>>> I'm running FreeBSD 10.1 updated tonight.
>> I am seeing runtime problems with asterisk13 (which I maintain), caused
>> by the OpenSSL update fallout.
>>
>> In this case, after some analysis, I concluded the problem is the
>> libsrtp port requiring OpenSSL from ports(for a reason), causing
>> asterisk to link to that too, which would be correct.
>>
>> Asterisk also uses the security/trousers port, which links to system
>> OpenSSL. This ensues a conflict which now results in asterisk
>> segfaulting and stopping to work.
>>
>> I'm investigating what can be done about this. As a local solution I can
>> force the trousers port to link against OpenSSL from ports, but this
>> will not fix the general problem. As a port maintaner I ony see
>> modifying the trousers port to depend on ports OpenSSL as a solution, is
>> this acceptable?
>>
> Most Ports link against the port openssl if its installed and agains the
> system openssl if not. That should be the prefered way to handle problem.
>
> I don't know if an incompatibility between system an port openssl is a
> problem. I've removed the portbuild openssl from this server completely.
>
> As far as i can see the problem is with openldap-client build agains the
> ports openssl and used by nss_ldap or pam_ldap modul. I will do some
> testing when my test host is ready. Testing on an Production server is
> not that good :-)
>
> Regards
>Estartu
>
>
I only use openssl from ports and have just completed a rebuild of 662
packages for server requirements and include: trousers, ldap client and
server, and 71 other ports built without any issues on amd64 10.1Stable
using clang.  Not so successful on i386 but I don't believe its related
to openssl.

My 2c.
Regards, Dewayne
PS Of the ports I use, only ports-mgmt/pkg and sysutils/monit link
against base openssl as they don't provide an option. :(

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Guido Falsi]

On 03/23/15 14:16, Gerhard Schmidt wrote:
> On 23.03.2015 13:40, Guido Falsi wrote:
>> On 03/23/15 11:33, Gerhard Schmidt wrote:
>>> Hi,
>>>
>>> we experiencing a problem after upgrading  the openssl port to openssl
>>> 1.0.2.
>>>
>>> /usr/bin/vi started to crash after some seconds with segfault.
>>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package
>>> everything works just fine again. Installing the old openssl 1.0.1_18
>>> package it still works just fine.
>>>
>>> it seams that besides vi the bash also has this problem. Anybody
>>> experiencing the same or is this something specific to my system.
>>>
>>> I'm running FreeBSD 10.1 updated tonight.
>>
>> I am seeing runtime problems with asterisk13 (which I maintain), caused
>> by the OpenSSL update fallout.
>>
>> In this case, after some analysis, I concluded the problem is the
>> libsrtp port requiring OpenSSL from ports(for a reason), causing
>> asterisk to link to that too, which would be correct.
>>
>> Asterisk also uses the security/trousers port, which links to system
>> OpenSSL. This ensues a conflict which now results in asterisk
>> segfaulting and stopping to work.
>>
>> I'm investigating what can be done about this. As a local solution I can
>> force the trousers port to link against OpenSSL from ports, but this
>> will not fix the general problem. As a port maintaner I ony see
>> modifying the trousers port to depend on ports OpenSSL as a solution, is
>> this acceptable?
>>
> Most Ports link against the port openssl if its installed and agains the
> system openssl if not. That should be the prefered way to handle problem.
> 

Sorry, I forgot to mention this is happening when building in poudriere.

in poudriere trousers will be unconditionally linked against base
OpenSSL, since nothing will pull in ports openssl when building trousers
(and others I'm discovering).

When poudriere builds asterisk, it will pull in a dependency bringing
OpenSSL from ports and asterisk will link against that, but the binary
package for trousers knows nothing and will still depend on base openssl.

So, the packages will build fine in most cases, but will fail in
unexpected ways at runtime.

I can fix this in my system by putting WITH_OPENSSL_PORT=yes in
make.conf and link everything against that, but this isn't a viable
solution for fixing it on the cluster.

> I don't know if an incompatibility between system an port openssl is a
> problem. I've removed the portbuild openssl from this server completely.

Mostly depends on the port. My fear is there could be other similar
problems lurking in binary packages.

> 
> As far as i can see the problem is with openldap-client build agains the
> ports openssl and used by nss_ldap or pam_ldap modul. I will do some
> testing when my test host is ready. Testing on an Production server is
> not that good :-)

This is a similar problem. but also involves base, so it's even harder
to solve.

-- 
Guido Falsi 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Gerhard Schmidt]

On 23.03.2015 14:17, Mike Tancsa wrote:
> On 3/23/2015 6:33 AM, Gerhard Schmidt wrote:
>> Hi,
>>
>> we experiencing a problem after upgrading  the openssl port to openssl
>> 1.0.2.
>>
>> /usr/bin/vi started to crash after some seconds with segfault.
> 
> Is you vi linked to openssl ?
> 
> /usr/bin/vi:
> libutil.so.9 => /lib/libutil.so.9 (0x800883000)
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x800a95000)
> libc.so.7 => /lib/libc.so.7 (0x800cea000)

no but...

I was finally able to repoduce this problem on my testserver.

The problem is related to nss_ldap or pam_ldap used in the user
authentication.

The openldap-client, nss_ldap and pam_ldap are linked against the ports
openssl lib.

vi crashed when I tried to change a file. First change and vi crashes.

if i remove ldap from /etc/nsswitch.conf and vi is running just fine.

there is definitely a issue with openssl 1.0.2 somewhere

Regards
   Estartu

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Mike Tancsa]

On 3/23/2015 6:33 AM, Gerhard Schmidt wrote:

Hi,

we experiencing a problem after upgrading  the openssl port to openssl
1.0.2.

/usr/bin/vi started to crash after some seconds with segfault.


Is you vi linked to openssl ?

/usr/bin/vi:
libutil.so.9 => /lib/libutil.so.9 (0x800883000)
libncursesw.so.8 => /lib/libncursesw.so.8 (0x800a95000)
libc.so.7 => /lib/libc.so.7 (0x800cea000)




--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Gerhard Schmidt]

On 23.03.2015 13:40, Guido Falsi wrote:
> On 03/23/15 11:33, Gerhard Schmidt wrote:
>> Hi,
>>
>> we experiencing a problem after upgrading  the openssl port to openssl
>> 1.0.2.
>>
>> /usr/bin/vi started to crash after some seconds with segfault.
>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package
>> everything works just fine again. Installing the old openssl 1.0.1_18
>> package it still works just fine.
>>
>> it seams that besides vi the bash also has this problem. Anybody
>> experiencing the same or is this something specific to my system.
>>
>> I'm running FreeBSD 10.1 updated tonight.
> 
> I am seeing runtime problems with asterisk13 (which I maintain), caused
> by the OpenSSL update fallout.
> 
> In this case, after some analysis, I concluded the problem is the
> libsrtp port requiring OpenSSL from ports(for a reason), causing
> asterisk to link to that too, which would be correct.
> 
> Asterisk also uses the security/trousers port, which links to system
> OpenSSL. This ensues a conflict which now results in asterisk
> segfaulting and stopping to work.
> 
> I'm investigating what can be done about this. As a local solution I can
> force the trousers port to link against OpenSSL from ports, but this
> will not fix the general problem. As a port maintaner I ony see
> modifying the trousers port to depend on ports OpenSSL as a solution, is
> this acceptable?
> 
Most Ports link against the port openssl if its installed and agains the
system openssl if not. That should be the prefered way to handle problem.

I don't know if an incompatibility between system an port openssl is a
problem. I've removed the portbuild openssl from this server completely.

As far as i can see the problem is with openldap-client build agains the
ports openssl and used by nss_ldap or pam_ldap modul. I will do some
testing when my test host is ready. Testing on an Production server is
not that good :-)

Regards
   Estartu


-- 
-
Gerhard Schmidt   | E-Mail: schm...@ze.tum.de
TU-München| Jabber: esta...@ze.tum.de
WWW & Online Services |
Tel: 089/289-25270|
Fax: 089/289-25257| PGP-Publickey auf Anfrage



signature.asc
Description: OpenPGP digital signature

Build failed in Jenkins: FreeBSD_stable_10 #1302

[jenkins-admin]

See 

Changes:

[mav] MFC r280293: Add missing variable initialization.

Reported by:Coverity
CID:1288938

--
[...truncated 181605 lines...]
--- usr.sbin.all__D ---
--- autounmountd.o ---
cc  -O2 -pipe   
-I 
-I
 
-I
 -std=gnu99 -Qunused-arguments  -fstack-protector -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition 
-Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -c 

 -o autounmountd.o
--- all_subdir_bhyve ---
--- atkbdc.o ---
cc  -O2 -pipe   -g -O0 -std=gnu99 -Qunused-arguments  -fstack-protector 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -c 
 
-o atkbdc.o
--- lib.all__D ---
--- pam_tacplus.8.gz ---
gzip -cn 

 > pam_tacplus.8.gz
--- usr.sbin.all__D ---
--- acpi.o ---
--- lib.all__D ---
===> lib/libpam/modules/pam_unix (all)
--- usr.sbin.all__D ---
cc  -O2 -pipe   -g -O0 -std=gnu99 -Qunused-arguments  -fstack-protector 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -c 
 -o 
acpi.o
--- all_subdir_autofs ---
--- common.o ---
cc  -O2 -pipe   
-I 
-I
 
-I
 -std=gnu99 -Qunused-arguments  -fstack-protector -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition 
-Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -c 
 
-o common.o
--- lib.all__D ---
--- pam_unix.8.gz ---
gzip -cn 

 > pam_unix.8.gz
--- usr.sbin.all__D ---
--- all_subdir_bhyve ---
--- bhyverun.o ---
--- lib.all__D ---
===> lib/libpam/libpam (all)
--- usr.sbin.all__D ---
cc  -O2 -pipe   -g -O0 -std=gnu99 -Qunused-arguments  -fstack-protector 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -c 

 -o bhyverun.o
--- block_if.o ---
cc  -O2 -pipe   -g -O0 -std=gnu99 -Qunused-arguments  -fstack-protector 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -c 

 -o block_if.o
--- all_subdir_autofs ---
--- defined.o ---
cc  -O2 -pipe   
-I 
-I
 
-I

Re: Problems with openssl 1.0.2 update

[Guido Falsi]

On 03/23/15 11:33, Gerhard Schmidt wrote:
> Hi,
> 
> we experiencing a problem after upgrading  the openssl port to openssl
> 1.0.2.
> 
> /usr/bin/vi started to crash after some seconds with segfault.
> /rescue/vi works just fine. Deleting the openssl 1.0.2 package
> everything works just fine again. Installing the old openssl 1.0.1_18
> package it still works just fine.
> 
> it seams that besides vi the bash also has this problem. Anybody
> experiencing the same or is this something specific to my system.
> 
> I'm running FreeBSD 10.1 updated tonight.

I am seeing runtime problems with asterisk13 (which I maintain), caused
by the OpenSSL update fallout.

In this case, after some analysis, I concluded the problem is the
libsrtp port requiring OpenSSL from ports(for a reason), causing
asterisk to link to that too, which would be correct.

Asterisk also uses the security/trousers port, which links to system
OpenSSL. This ensues a conflict which now results in asterisk
segfaulting and stopping to work.

I'm investigating what can be done about this. As a local solution I can
force the trousers port to link against OpenSSL from ports, but this
will not fix the general problem. As a port maintaner I ony see
modifying the trousers port to depend on ports OpenSSL as a solution, is
this acceptable?

-- 
Guido Falsi 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Matt Smith]

On Mar 23 11:33, Gerhard Schmidt wrote:

Hi,

we experiencing a problem after upgrading  the openssl port to openssl
1.0.2.

/usr/bin/vi started to crash after some seconds with segfault.
/rescue/vi works just fine. Deleting the openssl 1.0.2 package
everything works just fine again. Installing the old openssl 1.0.1_18
package it still works just fine.

it seams that besides vi the bash also has this problem. Anybody
experiencing the same or is this something specific to my system.

I'm running FreeBSD 10.1 updated tonight.



There is definitely something not right. See this too 
https://forums.freebsd.org/threads/postfix-does-not-start-build-anymore-since-upgrade-to-openssl-1-0-2.50959/


I haven't had a chance yet to test it again in more detail, but someone 
reported that postfix was broken, and I had PHP-FPM racing and taking up 
50+ load average on my box which I guess was probably nginx hitting it 
with tons of requests. Mine is 10.1-STABLE amd64.


--
Matt
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with openssl 1.0.2 update

[Kurt Jaeger]

Hi!

> we experiencing a problem after upgrading  the openssl port to openssl
> 1.0.2.

I have 1.0.2 installed on my testbox.

vi works fine.

> /usr/bin/vi started to crash after some seconds with segfault.

Do you have a coredump ?

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Problems with openssl 1.0.2 update

[Gerhard Schmidt]

Hi,

we experiencing a problem after upgrading  the openssl port to openssl
1.0.2.

/usr/bin/vi started to crash after some seconds with segfault.
/rescue/vi works just fine. Deleting the openssl 1.0.2 package
everything works just fine again. Installing the old openssl 1.0.1_18
package it still works just fine.

it seams that besides vi the bash also has this problem. Anybody
experiencing the same or is this something specific to my system.

I'm running FreeBSD 10.1 updated tonight.

Regards
   Estartu

-- 
--
Gerhard Schmidt| E-Mail: schm...@ze.tum.de
Technische Universität München | Jabber: esta...@ze.tum.de
WWW & Online Services  |
Tel: +49 89 289-25270  | PGP-PublicKey
Fax: +49 89 289-25257  | on request
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: dev.cpu.0.freq disapeared

[Dmitry Sivachenko]

> On 23 марта 2015 г., at 9:03, Ian Smith  wrote:
> 
> 
> Do you have Enhanced Speedstep (EST), disabled in your BIOS settings?  
> If so, just turn it on.  Then you should also be able to set running 
> frequency to 'MAX performance' or similar there.
> 
> If not disabled, ie you have EST enabled in BIOS, that points to a real 
> issue of EST detection.  And it still seems strange that enabling p4tcc 
> is enough to have cpufreq(4) include OIDs for freq and freq_levels?
> 


Thanks to all who replied.  This is called Intel SpeedStep Tech in that BIOS 
and it was indeed disabled.

I enabled it and now I have in dmesg
est0:  on cpu0
even with hint.p4tcc.0.disabled="1" 

for each CPU and dev.cpu.0.freq appeared back.

Thanks for your help.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"