For discussion of Alpine Linux development and developer support

5 3

[alpine-devel] openssl 1.1 support

Natanael Copa
Details
Message ID
<20181024171950.2343fefd@ncopa-desktop.copa.dup.pw>
Sender timestamp
1540394390
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] Re: openssl 1.1 support

William Pitcock
Details
Message ID
<CA+T2pCFRThvr1KgRP7cwEr6fVAOWd8Q=S6MaOYrmJRRoJKpOhQ@mail.gmail.com>
In-Reply-To
<20181024171950.2343fefd@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1540424871
DKIM signature
missing
Download raw message
Hello,

On Wed, Oct 24, 2018 at 10:19 AM Natanael Copa <ncopa@alpinelinux.org> wrote:
>
> 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 do not think musl have secure_getenv(3) yet.

> 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?

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

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

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

William

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

[alpine-devel] Re: openssl 1.1 support

Timo Teras
Details
Message ID
<20181024203810.3970da20@vostro>
In-Reply-To
<20181024171950.2343fefd@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1540402690
DKIM signature
missing
Download raw message
On Wed, 24 Oct 2018 17:19:50 +0200
Natanael Copa <ncopa@alpinelinux.org> wrote:

> 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.

Thanks. Sounds like a plan.

> 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.

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?

> 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.

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.

> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Re: openssl 1.1 support

Natanael Copa
Details
Message ID
<20181025103550.18d4cc2c@ncopa-desktop.copa.dup.pw>
In-Reply-To
<CA+T2pCFRThvr1KgRP7cwEr6fVAOWd8Q=S6MaOYrmJRRoJKpOhQ@mail.gmail.com> (view parent)
Sender timestamp
1540456550
DKIM signature
missing
Download raw message
On Wed, 24 Oct 2018 18:47:51 -0500
William Pitcock <nenolod@dereferenced.org> wrote:

...

> > 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 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.

...

> > 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?  
> 
> We can drop it.  IRCv3 STARTTLS has been all but deprecated.

Good.

> > Can you please also have a look at porting libtls-standalone to openssl
> > 1.1?  
> 
> I pushed a new libtls-standalone which builds against openssl 1.1.0 APIs.

Great! thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Re: openssl 1.1 support

Natanael Copa
Details
Message ID
<20181025104450.23747f0a@ncopa-desktop.copa.dup.pw>
In-Reply-To
<20181025103550.18d4cc2c@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1540457090
DKIM signature
missing
Download raw message
On Thu, 25 Oct 2018 10:35:50 +0200
Natanael Copa <ncopa@alpinelinux.org> wrote:

> On Wed, 24 Oct 2018 18:47:51 -0500
> William Pitcock <nenolod@dereferenced.org> wrote:
> 
> ...
> 
> > > 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 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Re: openssl 1.1 support

Natanael Copa
Details
Message ID
<20181025112949.6f869895@ncopa-desktop.copa.dup.pw>
In-Reply-To
<20181024203810.3970da20@vostro> (view parent)
Sender timestamp
1540459789
DKIM signature
missing
Download raw message
On Wed, 24 Oct 2018 20:38:10 +0300
Timo Teras <timo.teras@iki.fi> wrote:

> > 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.  
> 
> 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?

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.

> > 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.  
> 
> 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.

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

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

> 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.

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---