Re: OpenSSL 1.1.1 libssl.so version number

2018-10-13 Thread Cy Schubert 
In message , Don Lewis writes:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
>
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

This is also the issue with ports-mgmt/pkg on a system that still 
requires OpenSSL 1.0.2 from ports in order to support an old client.

cwfw# pkg info
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
required by /usr/local/lib/libpkg.so.4 not defined
cwfw# 

If I remove security/openssl, the above issue is resolved however the 
old client, which should be replaced next year, fails to communicate 
with the server. The classic rock & a hard place scenario.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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

Re: OpenSSL 1.1.1 libssl.so version number

2018-10-13 Thread freebsd . current 

On 2018-10-13 02:56, Don Lewis wrote:

Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
/usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
(1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, 
the

base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
is ambiguous because there are now two different versions of libssl.so
(1.0.2p and 1.1.1) with the same shared library version number.

I stumbled across this when debugging a virtualbox-ose configure
failure.  The test executable was linked to the ports version of
libssl.so but rtld chose the base libssl.so at run time.


I see the same issue with ports-mgmt/pkg when security/openssl 
installed. Have DEFAULT_VERSIONS+=ssl=openssl in /etc/make.conf


After rebuild pkg on 12-ALPHA9 system:

# pkg
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
required by /usr/local/lib/libpkg.so.4 not defined

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

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-13 Thread Ronald Klop 

On Sat, 13 Oct 2018 02:00:16 +0200, Don Lewis  wrote:


On 11 Oct, Don Lewis wrote:

On 11 Oct, Don Lewis wrote:

On 11 Oct, freebsd.curr...@clogic.com.ua wrote:

On 2018-10-10 06:14, Michael Butler wrote:

On 10/9/18 5:34 PM, Glen Barber wrote:

OpenSSL has been updated to version 1.1.1 as of r339270.

It is important to rebuild third-party packages before running:

 # make -C /usr/src delete-old && make -C /usr/src delete-old-libs

Thank you for your patience while this work was in progress, and  
thank

you to all involved for their hard work in getting things ready for
this
update.


So far, I've found two ports that will no longer build. They are:

net-mgmt/net-snmp
security/opencryptoki

I simply chose those that were linked to /usr/lib/libssl.so.8 where  
the

openssl update creates libssl.so.9. There may be more I haven't found
yet,

imb


You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to
use openssl from ports.
Anyway, I think apps from ports need to use openssl from ports.


I've been doing this for a long time, but I still see a fair amount of
breakage with the new base OpenSSL.  I suspect that some ports are
incorrectly stumbling across the new bits in base even though they
shouldn't be looking there.


security/p5-Net-SSLeay is hardwired to use base OpenSSL, so changing the
default version can't be done to unbreak p5-IO-Socket-SSL.

devel/libsoup appears to allow the OpenSSL version to be set, but  
doesn't

have an option for GSSAPI, so it attempts to use base GSSAPI with ports
OpenSSL which is not a valid combo.

emulators/virtualbox-ose is hardwired to use base OpenSSL.


I now think the problem with virtualbox-ose is not the port.  Rather it
is the fact that that the base libssl.so and the libssl.so installed by
the security/openssl have the same shared library version number even
though they are radically different OpenSSL versions.



I added this to libmap.conf:
cat /etc/libmap.conf
# $FreeBSD: head/libexec/rtld-elf/libmap.conf 338741 2018-09-18 00:25:00Z  
brd $

includedir /usr/local/etc/libmap.d
libssl.so.8 libssl.so.9
libcrypto.so.8  libcrypto.so.9

This made pkg run again. And now I'm waiting for the next pkg build to run  
pkg upgrade -f and upgrade everything.

I guess that will solve all issues.

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

Also affects "pkg" (was: Re: OpenSSL 1.1.1 libssl.so version number)

2018-10-13 Thread Stefan Esser 
Am 13.10.18 um 01:56 schrieb Don Lewis:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
> 
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

I'm seeing something possibly related in pkg:

$ ldd /usr/local/lib/libpkg. | grep ssl
libpkg.a libpkg.solibpkg.so.4  libpkg.so.4.0.0

$ldd /usr/local/lib/libpkg.so.4 | grep ssl
libssl.so.9 => /usr/lib/libssl.so.9 (0x800679000)

This results in:

$ pkg -v
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 required by
/usr/local/lib/libpkg.so.4 not defined

My work-around was to copy pkg-static over pkg (I have not checked
whether the static version is linked against the system or ports
version of the library, but I assume the latter).

I have "DEFAULT_VERSIONS+= ssl=openssl" in make.conf but the same
problem exists if pkg is built without that setting.

My local version of portmaster has been changed to use pkg-static
in favor of pkg and I plan to commit that change to the portmaster
port, to make it resilient against this problem.

Regards, STefan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

net/samba48

2018-10-13 Thread Graham Perrin 


How about 4.8 as the default for ports for 12?

Is it too late to throw the suggestion into the mix?

(Does the suggestion even make sense? Excuse the clumsy wording.)

As far as I can tell:

- 4.8 is vastly preferable for compatibility with services from modern versions 
of Windows

… and (personally) nearly all servers that I'm _required_ to use could not be 
used with Dolphin (and so on) with samba47.

TIA



For now I have this in my
/usr/local/etc/poudriere.d/make.conf

DEFAULT_VERSIONS+= samba=4.8

– which is effective, but (of course) some of the associated builds can be 
terribly time-consuming. Particularly when poudriere must 'start from scratch' 
after an update to the jail.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Allan Jude 

On 10/12/2018 11:52, Mike Tancsa wrote:

I am guessing this does not have anything to do with vmm being loaded,
but hardware being initialized in a particular order? If I load vmm in
loader.conf, the box panics at boot up.  However, manually loading it
all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG


Leading up to the crash, I see


ugen0.1: <0x1022 XHCI root HUB> at usbus0
ugen1.1: <0x1b21 XHCI root HUB> at usbus1
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
  usbus1 usbus0
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub2: 4 ports with 4 removable, self powered
uhub1: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x398
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8273d776
stack pointer   = 0x28:0xfe0075d55230
frame pointer   = 0x28:0xfe0075d55270
code segment    = base 0x0, limit 0xf, type 0x1b
     = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  rrw_enter_read_impl+0x36:   lock cmpxchgq
%r14,0x18(%rbx)
db> bt
Tracing pid 1 tid 12 td 0xf8000567d580
rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
start_init() at start_init+0x27/frame 0xfe0075d55a70
fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>


Strange that your crash is in ZFS here...

Can you take a crash dump?

It looks like something is trying to write to uninitialized memory here.



On a normal boot, the next line would be atrtc0

uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
  usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> 
on usbus1

uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub1: 4 ports with 4 removable, self powered
uhub2: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered
atrtc0: providing initial system time
start_init: trying /sbin/init
Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
Setting hostid: 0x094fa67e.
Starting file system checks:
Mounting local filesystems:.


snip




---Mike






--
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSL 1.1.1 libssl.so version number

2018-10-13 Thread Daniel Eischen 


> On Oct 12, 2018, at 10:58 PM, Cy Schubert  wrote:
> 
> In message , Don Lewis writes:
>> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
>> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
>> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
>> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
>> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
>> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
>> is ambiguous because there are now two different versions of libssl.so
>> (1.0.2p and 1.1.1) with the same shared library version number.
>> 
>> I stumbled across this when debugging a virtualbox-ose configure
>> failure.  The test executable was linked to the ports version of
>> libssl.so but rtld chose the base libssl.so at run time.
> 
> This is also the issue with ports-mgmt/pkg on a system that still 
> requires OpenSSL 1.0.2 from ports in order to support an old client.
> 
> cwfw# pkg info
> ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
> required by /usr/local/lib/libpkg.so.4 not defined
> cwfw# 
> 
> If I remove security/openssl, the above issue is resolved however the 
> old client, which should be replaced next year, fails to communicate 
> with the server. The classic rock & a hard place scenario.

Not saying this is a real solution for the general problem, but can you use a 
libmap.conf entry to work around this?

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

Re: Dell latitude 7490 touchpad support?

2018-10-13 Thread Mark Johnston 
On Sat, Sep 29, 2018 at 08:48:57PM +0100, Johannes Lundberg wrote:
> Hi
> 
> I just got a new work laptop and the touchpad does not work. Some
> information points to that this machine has a Microsoft precision touchpad.
> I can't see any USB device so I'm wondering if this is an I2C device?
> 
> Do we have any driver for this?

I tried installing FreeBSD on a Latitude 7480 and hit the same problem.
Some digging turned up this diff, and with it applied I get a working
trackpad: https://reviews.freebsd.org/D16698
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Cy Schubert 
In message <8f033c7c-af8f-1ebc-d787-548634f10...@freebsd.org>, Allan 
Jude write
s:
> On 10/12/2018 11:52, Mike Tancsa wrote:
> > I am guessing this does not have anything to do with vmm being loaded,
> > but hardware being initialized in a particular order? If I load vmm in
> > loader.conf, the box panics at boot up.  However, manually loading it
> > all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
> > RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG
> > 
> > 
> > Leading up to the crash, I see
> > 
> > 
> > ugen0.1: <0x1022 XHCI root HUB> at usbus0
> > ugen1.1: <0x1b21 XHCI root HUB> at usbus1
> > Trying to mount root from zfs:zroot/ROOT/default []...
> > uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
> > Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
> > 3.00/1.00, addr 1> on usbus0
> >   usbus1 usbus0
> > uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
> > uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > uhub1: 8 ports with 8 removable, self powered
> > uhub0: 22 ports with 22 removable, self powered
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x398
> > fault code              = supervisor write data, page not pres
> ent
> > instruction pointer     = 0x20:0x8273d776
> > stack pointer           = 0x28:0xfe0075d55230
> > frame pointer           = 0x28:0xfe0075d55270
> > code segment            = base 0x0, limit 0xf, type 0x1b
> >                          = DPL 0, pres 1, long 1, de
> f32 0, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 1 (kernel)
> > [ thread pid 1 tid 12 ]
> > Stopped at      rrw_enter_read_impl+0x36:       lock cmpxchgq
> > %r14,0x18(%rbx)
> > db> bt
> > Tracing pid 1 tid 12 td 0xf8000567d580
> > rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
> > zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
> > vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
> > vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
> > kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
> > parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
> > vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
> > start_init() at start_init+0x27/frame 0xfe0075d55a70
> > fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > db>
>
> Strange that your crash is in ZFS here...
>
> Can you take a crash dump?
>
> It looks like something is trying to write to uninitialized memory here.
>

I was digging into this before I left on vacation. You can recreate 
this by,

mount -t zfs tank/nonexistent /mnt

A nonexistent dataset or zpool triggers the panic. I discovered it by 
chance through a typo in fstab. The panic occurs with INVARIANTS. 
Without INVARIANTS results in a hard hang.

I got as far as discovering that f_mntfromname pointed to a null string 
but ran out of time before I left.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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