[arch-dev-public] openssl 1.0 rebuild
Hi all, I created a rebuld list for the just released openssl 1.0.0 (Thanks Dan for fixing the todo list that fast!). These are 236 packages for each architecture; so this will need some kind of planning and a bunch of people to help. But for now I'll at least wait for the Gnome and KDE release and also Allan's heimdal rebuilds. Fedora uses openssl 1 since Fedora 12 which means if there are any issues we'll probably find a solution there. Till then I just need to port the man page patch (easy) and see why it compiles with -DOPENSSL_IA32_SSE2 on x86_64 and if that is an issue at all. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 30/03/10 11:36, Pierre Schmitz wrote:
Hi all,
I created a rebuld list for the just released openssl 1.0.0 (Thanks Dan for fixing the todo list that fast!). These are 236 packages for each architecture; so this will need some kind of planning and a bunch of people to help. But for now I'll at least wait for the Gnome and KDE release and also Allan's heimdal rebuilds.
Nice big list of essential packages there... this looks fun! Any interest in just combining the heimdal rebuilds? They do overlap a lot but heimdal is quite a small rebuild this time so I think it can be finished fast (once GNOME is finished). Allan
On 30/03/10 11:45, Allan McRae wrote:
On 30/03/10 11:36, Pierre Schmitz wrote:
Hi all,
I created a rebuld list for the just released openssl 1.0.0 (Thanks Dan for fixing the todo list that fast!). These are 236 packages for each architecture; so this will need some kind of planning and a bunch of people to help. But for now I'll at least wait for the Gnome and KDE release and also Allan's heimdal rebuilds.
Nice big list of essential packages there... this looks fun!
Any interest in just combining the heimdal rebuilds? They do overlap a lot but heimdal is quite a small rebuild this time so I think it can be finished fast (once GNOME is finished).
Ping Pierre! I will do the initial heimdal rebuilds today if these rebuilds will be done separately. Allan
On Thu, 01 Apr 2010 09:27:53 +1000, Allan McRae <allan@archlinux.org> wrote:
On 30/03/10 11:45, Allan McRae wrote:
On 30/03/10 11:36, Pierre Schmitz wrote:
Hi all,
I created a rebuld list for the just released openssl 1.0.0 (Thanks Dan for fixing the todo list that fast!). These are 236 packages for each architecture; so this will need some kind of planning and a bunch of people to help. But for now I'll at least wait for the Gnome and KDE release and also Allan's heimdal rebuilds.
Nice big list of essential packages there... this looks fun!
Any interest in just combining the heimdal rebuilds? They do overlap a lot but heimdal is quite a small rebuild this time so I think it can be finished fast (once GNOME is finished).
Ping Pierre! I will do the initial heimdal rebuilds today if these rebuilds will be done separately.
Allan
I was just working on it. I think we can combine both rebuilds. The build order should be: openssl heimdal <everything else from [core]> <[extra]> <[community]> I think once we have rebuild [core] we can post a warning to arch-dev-public, push those packages to testing and ask everybody to help rebuilding. PS: Ping me on jabber if you are online atm. -- Pierre Schmitz, https://users.archlinux.de/~pierre
I have rebuild all core and some other packages. It's now time for everybody to join the rebuild party. We rebuild heimdal and openssl at once. See https://dev.archlinux.org/todo/30/ and https://dev.archlinux.org/todo/32/ If you rebuild packages you should build bottom-up; means rebuild the deps of a package first. It's probably best to join our irc channel to communicate which packages you are about to rebuild. If something doesn't build you might find patches at http://cvs.fedoraproject.org/viewvc/rpms/$pkgname And please avoid using versioned deps. Btw: I think we have a problem with the pacman update. Am I right that a -Syu will update pacman first without loading openssl which will result in a broken pacman? This might probably the only valid usage of a versiond dep. If that's true we might consider to keep openssl in tar.gz, too. Happy building, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Mar 31, 2010 at 22:54, Pierre Schmitz <pierre@archlinux.de> wrote:
Btw: I think we have a problem with the pacman update. Am I right that a -Syu will update pacman first without loading openssl which will result in a broken pacman? This might probably the only valid usage of a versiond dep. If that's true we might consider to keep openssl in tar.gz, too. +1 to dep and .tar.gz if that's the case
On Wed, Mar 31, 2010 at 8:54 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
I have rebuild all core and some other packages. It's now time for everybody to join the rebuild party. We rebuild heimdal and openssl at once. See https://dev.archlinux.org/todo/30/ and https://dev.archlinux.org/todo/32/
If you rebuild packages you should build bottom-up; means rebuild the deps of a package first. It's probably best to join our irc channel to communicate which packages you are about to rebuild. If something doesn't build you might find patches at http://cvs.fedoraproject.org/viewvc/rpms/$pkgname
And please avoid using versioned deps.
Btw: I think we have a problem with the pacman update. Am I right that a -Syu will update pacman first without loading openssl which will result in a broken pacman? This might probably the only valid usage of a versiond dep. If that's true we might consider to keep openssl in tar.gz, too.
It is less a problem and more intentional. :) Versioned deps are definitely a tricky subject. I haven't tried it out yet, but shouldn't a new pacman, compiled with the right ldflags, no longer link directly against openssl? The reason that is in there is only because of the libraries it uses; we don't use ssl methods directly in pacman code. Of course if we are explicitly telling it to link, then we would still have a problem. That is what it looks like after pulling down your rebuild; but I'm confused- it shows it still looking for openssl 0.9.8: dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman linux-gate.so.1 => (0xb76ee000) libalpm.so.4 => /usr/lib/libalpm.so.4 (0xb76b0000) libc.so.6 => /lib/libc.so.6 (0xb7569000) libfetch.so => /usr/lib/libfetch.so (0xb755b000) libarchive.so.2 => /usr/lib/libarchive.so.2 (0xb751c000) libssp.so.0 => /usr/lib/libssp.so.0 (0xb7518000) /lib/ld-linux.so.2 (0xb76ef000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb74cf000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000) libacl.so.1 => /lib/libacl.so.1 (0xb7374000) libattr.so.1 => /lib/libattr.so.1 (0xb736f000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7348000) liblzma.so.0 => /usr/lib/liblzma.so.0 (0xb7327000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7316000) libz.so.1 => /usr/lib/libz.so.1 (0xb7301000) libdl.so.2 => /lib/libdl.so.2 (0xb72fd000) libpthread.so.0 => /lib/libpthread.so.0 (0xb72e3000) -Dan
On 01/04/10 13:15, Dan McGee wrote:
dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000)
Thats openssl. I'm rebuilding pacman with versioned deps on libarchive and libfetch and those with versioned deps on openssl. That way, pacman will upgrade itself _and_ its deps. Allan
On 01/04/10 13:23, Allan McRae wrote:
On 01/04/10 13:15, Dan McGee wrote:
dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000)
Thats openssl.
Nevermind... I miss-read your email. I guess pacman links against this for md5sum checking?
On Wed, Mar 31, 2010 at 10:23 PM, Allan McRae <allan@archlinux.org> wrote:
On 01/04/10 13:15, Dan McGee wrote:
dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000)
Thats openssl. I'm rebuilding pacman with versioned deps on libarchive and libfetch and those with versioned deps on openssl. That way, pacman will upgrade itself _and_ its deps.
See my later email, but this rebuild isn't necessary...
On Wed, 31 Mar 2010 22:15:48 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
I'm confused- it shows it still looking for openssl 0.9.8:
dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman .. libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb74cf000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000) ..
You have probably an old version of libarchive/libfetch installed. Don't trust ldd here. Within my updated chroot it looks fine: ldd /usr/bin/pacman linux-vdso.so.1 => (0x00007fffc47c7000) libalpm.so.4 => /usr/lib/libalpm.so.4 (0x00007f74abefc000) libc.so.6 => /lib/libc.so.6 (0x00007f74abba6000) libfetch.so => /usr/lib/libfetch.so (0x00007f74ab996000) libarchive.so.2 => /usr/lib/libarchive.so.2 (0x00007f74ab754000) /lib/ld-linux-x86-64.so.2 (0x00007f74ac11d000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f74ab4f9000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f74ab143000) libacl.so.1 => /lib/libacl.so.1 (0x00007f74aaf3c000) libattr.so.1 => /lib/libattr.so.1 (0x00007f74aad38000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f74aab10000) liblzma.so.0 => /usr/lib/liblzma.so.0 (0x00007f74aa8f0000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f74aa6e0000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f74aa4c8000) libdl.so.2 => /lib/libdl.so.2 (0x00007f74aa2c4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f74aa0a8000) There are also no *.0.9.8 files in my build chroot; so it's quite impossible it linked agaisnt them. :-) -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Mar 31, 2010 at 10:35 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Wed, 31 Mar 2010 22:15:48 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
I'm confused- it shows it still looking for openssl 0.9.8:
dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman .. libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb74cf000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000) ..
You have probably an old version of libarchive/libfetch installed. Don't trust ldd here. Within my updated chroot it looks fine:
ldd /usr/bin/pacman linux-vdso.so.1 => (0x00007fffc47c7000) libalpm.so.4 => /usr/lib/libalpm.so.4 (0x00007f74abefc000) libc.so.6 => /lib/libc.so.6 (0x00007f74abba6000) libfetch.so => /usr/lib/libfetch.so (0x00007f74ab996000) libarchive.so.2 => /usr/lib/libarchive.so.2 (0x00007f74ab754000) /lib/ld-linux-x86-64.so.2 (0x00007f74ac11d000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f74ab4f9000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f74ab143000) libacl.so.1 => /lib/libacl.so.1 (0x00007f74aaf3c000) libattr.so.1 => /lib/libattr.so.1 (0x00007f74aad38000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f74aab10000) liblzma.so.0 => /usr/lib/liblzma.so.0 (0x00007f74aa8f0000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f74aa6e0000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f74aa4c8000) libdl.so.2 => /lib/libdl.so.2 (0x00007f74aa2c4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f74aa0a8000)
There are also no *.0.9.8 files in my build chroot; so it's quite impossible it linked agaisnt them. :-)
So in that case, this matters not at all because pacman doesn't directly link against those libraries (at least your new version). Considering I did that ldd on my i686 machine that knows nothing at all about the rebuild and we didn't have any missing libraries detected, we are fine. -Dan
On 01/04/10 13:47, Dan McGee wrote:
On Wed, Mar 31, 2010 at 10:35 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
On Wed, 31 Mar 2010 22:15:48 -0500, Dan McGee<dpmcgee@gmail.com> wrote:
I'm confused- it shows it still looking for openssl 0.9.8:
dmcgee@dublin /tmp/pacman-extracted $ ldd usr/bin/pacman .. libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0xb74cf000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb737c000) ..
You have probably an old version of libarchive/libfetch installed. Don't trust ldd here. Within my updated chroot it looks fine:
ldd /usr/bin/pacman linux-vdso.so.1 => (0x00007fffc47c7000) libalpm.so.4 => /usr/lib/libalpm.so.4 (0x00007f74abefc000) libc.so.6 => /lib/libc.so.6 (0x00007f74abba6000) libfetch.so => /usr/lib/libfetch.so (0x00007f74ab996000) libarchive.so.2 => /usr/lib/libarchive.so.2 (0x00007f74ab754000) /lib/ld-linux-x86-64.so.2 (0x00007f74ac11d000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f74ab4f9000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f74ab143000) libacl.so.1 => /lib/libacl.so.1 (0x00007f74aaf3c000) libattr.so.1 => /lib/libattr.so.1 (0x00007f74aad38000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f74aab10000) liblzma.so.0 => /usr/lib/liblzma.so.0 (0x00007f74aa8f0000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f74aa6e0000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f74aa4c8000) libdl.so.2 => /lib/libdl.so.2 (0x00007f74aa2c4000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f74aa0a8000)
There are also no *.0.9.8 files in my build chroot; so it's quite impossible it linked agaisnt them. :-)
So in that case, this matters not at all because pacman doesn't directly link against those libraries (at least your new version). Considering I did that ldd on my i686 machine that knows nothing at all about the rebuild and we didn't have any missing libraries detected, we are fine.
Hmm... readelf -d /usr/bin/pacman .... 0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] ....
pacman -Qo /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8 is owned by openssl 0.9.8n-1
That is on my i686 machine without doing any upgrades yet. So the versioned dep on pacman -> libarchive/libfetch -> openssl is really needed. The needed rebuilds are now in [testing]. Allan
On Thu, 01 Apr 2010 13:52:17 +1000, Allan McRae <allan@archlinux.org> wrote:
readelf -d /usr/bin/pacman
.... 0x00000001 (NEEDED) Shared library: [libcrypto.so.0.9.8] ....
pacman -Qo /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8 is owned by openssl 0.9.8n-1
That is on my i686 machine without doing any upgrades yet.
So the versioned dep on pacman -> libarchive/libfetch -> openssl is really needed. The needed rebuilds are now in [testing].
The new pacman doesnÄt link against libcrypto anymore. That's possible a result of being build with the new --needed ldflag? -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 01/04/10 14:24, Pierre Schmitz wrote:
The new pacman doesnÄt link against libcrypto anymore. That's possible a result of being build with the new --needed ldflag?
Yes it is... I thought the last version was but it turns out that it was not.
On Wed, Mar 31, 2010 at 7:54 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
If you rebuild packages you should build bottom-up; means rebuild the deps of a package first. It's probably best to join our irc channel to communicate which packages you are about to rebuild. If something doesn't build you might find patches at http://cvs.fedoraproject.org/viewvc/rpms/$pkgname
And please avoid using versioned deps.
This is probably a stupid question, but... How exactly do you know whether to use versioned deps? For example, I was going to rebuild mutt which currently requires openssl>=0.9.8e from when Tobias maintained it. Do I need to update the dep version or will 0.9.8e still suffice?
On 02/04/10 03:18, Thayer Williams wrote:
On Wed, Mar 31, 2010 at 7:54 PM, Pierre Schmitz<pierre@archlinux.de> wrote:
If you rebuild packages you should build bottom-up; means rebuild the deps of a package first. It's probably best to join our irc channel to communicate which packages you are about to rebuild. If something doesn't build you might find patches at http://cvs.fedoraproject.org/viewvc/rpms/$pkgname
And please avoid using versioned deps.
This is probably a stupid question, but...
How exactly do you know whether to use versioned deps? For example, I was going to rebuild mutt which currently requires openssl>=0.9.8e from when Tobias maintained it. Do I need to update the dep version or will 0.9.8e still suffice?
I'd just remove it. Basically the arguement against widespread usage of versioned deps is if you put a versioned openssl>=1.0 there and someone does "pacman -Sy mutt", it will pull in the new openssl and break many packages on their system. If you do not put it there, it will only break mutt. Allan
Am 30.03.2010 03:36, schrieb Pierre Schmitz:
I created a rebuld list for the just released openssl 1.0.0 (Thanks Dan for fixing the todo list that fast!). These are 236 packages for each architecture; so this will need some kind of planning and a bunch of people to help. But for now I'll at least wait for the Gnome and KDE release and also Allan's heimdal rebuilds.
Fedora uses openssl 1 since Fedora 12 which means if there are any issues we'll probably find a solution there. Till then I just need to port the man page patch (easy) and see why it compiles with -DOPENSSL_IA32_SSE2 on x86_64 and if that is an issue at all.
The new openssl breaks RADIUS authentication with wpa_supplicant for me. It fails to verify the CA certificate and aborts authentication. It works if I disable verification of the certificates in the configuration (which is bad, but still helps).
Am 07.04.2010 11:49, schrieb Thomas Bächler:
Fedora uses openssl 1 since Fedora 12 which means if there are any issues we'll probably find a solution there. Till then I just need to port the man page patch (easy) and see why it compiles with -DOPENSSL_IA32_SSE2 on x86_64 and if that is an issue at all.
The new openssl breaks RADIUS authentication with wpa_supplicant for me. It fails to verify the CA certificate and aborts authentication. It works if I disable verification of the certificates in the configuration (which is bad, but still helps).
Thanks to a hint from Pierre, I fixed it: # update-ca-certificates --fresh The hashes in /etc/ssl/certs are different from the ones before the command, so I suspect there will be more failures like this. Can we please get the above command in post_install in the case we are upgrading from a version older than 1.0.0?
On Thu, 08 Apr 2010 11:41:12 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
Thanks to a hint from Pierre, I fixed it: # update-ca-certificates --fresh The hashes in /etc/ssl/certs are different from the ones before the command, so I suspect there will be more failures like this. Can we please get the above command in post_install in the case we are upgrading from a version older than 1.0.0?
The new ca-certificates packages does this for you. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 08.04.2010 15:38, schrieb Pierre Schmitz:
On Thu, 08 Apr 2010 11:41:12 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
Thanks to a hint from Pierre, I fixed it: # update-ca-certificates --fresh The hashes in /etc/ssl/certs are different from the ones before the command, so I suspect there will be more failures like this. Can we please get the above command in post_install in the case we are upgrading from a version older than 1.0.0?
The new ca-certificates packages does this for you.
Very nice, thank you. This should also solve Jim's problem, see his reply to my first post.
On Wed, 07 Apr 2010, Thomas Bächler wrote:
The new openssl breaks RADIUS authentication with wpa_supplicant for me. It fails to verify the CA certificate and aborts authentication. It works if I disable verification of the certificates in the configuration (which is bad, but still helps).
I looked through my fetchmail log: fetchmail: Server certificate verification error: unable to get local issuer certificate 139953489753768:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1056: fetchmail: SSL connection failed. fetchmail: socket error while fetching from xxxxxxx@xxxxxxxxx.xx@xxxx.xxxxxxxxxx.xxx fetchmail: Query status=2 (SOCKET) turns out, I had to c_rehash .certs and everything was fine. I wonder how many other things might be effected ... -T
On Wed, 14 Apr 2010 12:32:09 -0700, Tobias Kieslich <tobias@justdreams.de> wrote:
On Wed, 07 Apr 2010, Thomas Bächler wrote:
The new openssl breaks RADIUS authentication with wpa_supplicant for me. It fails to verify the CA certificate and aborts authentication. It works if I disable verification of the certificates in the configuration (which is bad, but still helps).
I looked through my fetchmail log: fetchmail: Server certificate verification error: unable to get local issuer certificate 139953489753768:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1056: fetchmail: SSL connection failed. fetchmail: socket error while fetching from xxxxxxx@xxxxxxxxx.xx@xxxx.xxxxxxxxxx.xxx fetchmail: Query status=2 (SOCKET)
turns out, I had to c_rehash .certs and everything was fine. I wonder how many other things might be effected ...
-T
See http://bugs.archlinux.org/task/19043 You should use the system cert store instead. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, 14 Apr 2010, Pierre Schmitz wrote:
See http://bugs.archlinux.org/task/19043 You should use the system cert store instead.
-- Pierre Schmitz, https://users.archlinux.de/~pierre
Darn, I asked google, but they hadn't found that yet :P My certs are on a USB stick to move ~ between boxes, so system wide is no option. More over, most people will follow the tutorials on google that all point you to using ~/.certs So we might wann issues some news on the homepage on that. -T
On Wed, 14 Apr 2010 14:29:44 -0700, Tobias Kieslich <tobias@justdreams.de> wrote:
More over, most people will follow the tutorials on google that all point you to using ~/.certs So we might wann issues some news on the homepage on that.
Well, including yourself there were two people having this issue. So I am not sure if it's really worth posting a news item about this. But of course I wont mind if you write one. :-) -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (7)
-
Allan McRae
-
Daenyth Blank
-
Dan McGee
-
Pierre Schmitz
-
Thayer Williams
-
Thomas Bächler
-
Tobias Kieslich