Subject: [alpine-devel] openssl 1.1 support

From: Natanael Copa <[email-masked]>
Date: Wed, 24 Oct 2018 17:19:50 +0200

Hi Timo, William and list,

I didn't remember that I already had done testing/openssl1.1 so I
re-did the work as testing/openssl. I think I'm losing it... :-/

The plan is now to merge main/openssl1.0, testing/openssl1.1 and
testing/openssl into a single main/openssl, rebuild all packages that
currently is linked to libssl against openssl, and finally move
main/libressl to community/libressl.

I have currently disabled weak crypto in openssl configure, I am not
sure we need any of those, so I would appreciate some feedback there. I
have also built it with no-async for now, but I think we may need
enable it for nodejs.

Timo, Do you think you can help with add support for openssl 1.1 to
apk-tools? Can you also look over the patch list[1] and see if there
are some of those patches that we need? I suspect we need
0004-fix-default-ca-path-for-apps.patch[2], but it would be nice if you
can confirm that.

There are also some patches that fedora uses that we may want. Some of
fedoras patches are for multilib and FIPS support, which I don't think
we care about (yet), but there are some that replaces getenv() with
secure_getenv(). I think we may want do something similar. It would be
nice if you can help me look over their patches[3] and let me know which
ones of them you think we should take.

Timo, do you want continue be listed as the maintainer for openssl? I
will still help with the full "world" rebuild against openssl 1.1.

William, can you please have a look at the irc tls patch[4]? Is this
something we still want/need? If so, can you rebase it for openssl 1.1?

Can you please also have a look at porting libtls-standalone to openssl
1.1?

Thanks!

-nc

[1]: https://git.alpinelinux.org/cgit/aports/tree/main/openssl1.0/
[2]: https://git.alpinelinux.org/cgit/aports/tree/main/openssl1.0/0004-fix-default-ca-path-for-apps.patch
[3]: https://src.fedoraproject.org/cgit/rpms/openssl.git/tree/
[4]: https://git.alpinelinux.org/cgit/aports/tree/main/openssl1.0/0006-add-ircv3-tls-3.1-extension-support-to-s_client.patch

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Wed, 24 Oct 2018 20:38:10 +0300

On Wed, 24 Oct 2018 17:19:50 +0200

> main/libressl to community/libressl.

Thanks. Sounds like a plan.

> sure we need any of those, so I would appreciate some feedback there.
> I have also built it with no-async for now, but I think we may need
> enable it for nodejs.

Ok. no-async should work with libucontext. Need to figure out how to
ship libucontext - as per-package dependency+extra LIBS flag; or
somehow sneak it in to libc-dev?

> 0004-fix-default-ca-path-for-apps.patch[2], but it would be nice if
> you can confirm that.

Ok. Yes, they made some structs hidden, so need to go through the code
to allocate those dynamically. I'll work on this. Not sure if I get it
done this week - I'll try, but it may be early next week at worst case
when I get to this.

I'll look at the patches too. From top of my head, I think we don't
need 100[1-4], they target VIA Padlock. I used to do them for specific
need, but I don't need them anymore.

0003-use-termios.patch is not needed if it builds.

0004 we may need. To double check.

0009 we may need, it can be verified by checking rpath of
libraries/openssl binary with readelf. Though, they seemed to revamped
the build system so this needs to be checked.

0010-ssl-env-zlib.patch seems to be fixed upstream, by disabling
compression explicitly. You need explicit openssl api call now to
enable ssl/tsl compression. Not worth adding our environment var there
to not add surprises to user.

> nice if you can help me look over their patches[3] and let me know
> which ones of them you think we should take.
> 

I can help with the work. I have been updating it and reviewing update
patches occasionally. But seems others have made it before me on
several times. I've been recently working on few other things.

Thanks for this effort and making things go forward!
Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 25 Oct 2018 11:29:49 +0200

On Wed, 24 Oct 2018 20:38:10 +0300

> somehow sneak it in to libc-dev?

I don't think we want sneak it in to libc-dev. I prefer handle it
per-package.

I think we can remove the no-async and link with libucontext when the
need arises.

> 0003-use-termios.patch is not needed if it builds.

It builds without it.
 
> 0004 we may need. To double check.

Ok, this is then only one left that needs checking then.

> the build system so this needs to be checked.

Seems like its not needed:

ncopa-edge-x86_64:~/aports/testing/openssl$ scanelf -Rr pkg/
 TYPE   RPATH FILE 
ET_DYN   -   pkg/openssl/usr/bin/openssl 
ET_DYN   -   pkg/libssl1.1/lib/libssl.so.1.1 
ET_DYN   -   pkg/openssl-dbg/usr/lib/debug/usr/lib/libssl.so.1.1.debug 
ET_DYN   -   pkg/openssl-dbg/usr/lib/debug/usr/lib/libcrypto.so.1.1.debug 
ET_DYN   -   pkg/openssl-dbg/usr/lib/debug/usr/lib/engines-1.1/capi.so.debug 
ET_DYN   -   pkg/openssl-dbg/usr/lib/debug/usr/lib/engines-1.1/padlock.so.debug 
ET_DYN   -   pkg/openssl-dbg/usr/lib/debug/usr/lib/engines-1.1/afalg.so.debug 
ET_DYN   -   pkg/openssl-dbg/usr/lib/debug/usr/bin/openssl.debug 
ET_DYN   -   pkg/libcrypto1.1/usr/lib/engines-1.1/capi.so 
ET_DYN   -   pkg/libcrypto1.1/usr/lib/engines-1.1/padlock.so 
ET_DYN   -   pkg/libcrypto1.1/usr/lib/engines-1.1/afalg.so 
ET_DYN   -   pkg/libcrypto1.1/lib/libcrypto.so.1.1 

-nc

---

---

From: William Pitcock <[email-masked]>
Date: Wed, 24 Oct 2018 18:47:51 -0500

Hello,

On Wed, Oct 24, 2018 at 10:19 AM Natanael Copa <[email-masked]> wrote:
> secure_getenv().

I do not think musl have secure_getenv(3) yet.

> I think we may want do something similar. It would be

We can drop it.  IRCv3 STARTTLS has been all but deprecated.

> Can you please also have a look at porting libtls-standalone to openssl

I pushed a new libtls-standalone which builds against openssl 1.1.0 APIs.

William

William

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 25 Oct 2018 10:35:50 +0200

On Wed, 24 Oct 2018 18:47:51 -0500
William Pitcock <[email-masked]> wrote:

...

> I do not think musl have secure_getenv(3) yet.

We don't but its relatively easy to implement same functionality:

inline *char secure_getenv(const char *name) {
	return getauxval(AT_SECURE) ? NULL : getenv(name);
}

I think it may be good that we do that so that nobody gets a nasty
surprise if a suid binary is linked to openssl.

...

> We can drop it.  IRCv3 STARTTLS has been all but deprecated.

Good.

> I pushed a new libtls-standalone which builds against openssl 1.1.0 APIs.

Great! thanks!

-nc

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 25 Oct 2018 10:44:50 +0200

On Thu, 25 Oct 2018 10:35:50 +0200

> surprise if a suid binary is linked to openssl.

It seems that they have applied something to solve that upstream:

https://github.com/openssl/openssl/commit/79c2c741303ed188214b9299a51c837635f7e9a8

I guess we can backport that.

-nc

---