Am Thu, 3 Jan 2008 13:28:49 -0600 schrieb "Aaron Griffin" :

I'd test.. but I have no idea what these libs do and/or are for. What test did you perform?

http://www.gnupg.org/related_software/libraries.en.html libgcrypt Libgcrypt is a general purpose cryptographic library based on the code from GnuPG. It provides functions for all cryptographic building blocks: symmetric ciphers, hash algorithms, MACs, public key algorithms, large integer functions, random numbers and a lot of supporting functions. libgpg-error Libgpg-error is helper library used by a couple of other projects to provide a common set of error codes and descriptions. I haven't done any deep testing. I'm happy that lddd didn't report any broken linking. I took these packages just to prevent that they are not orphaned. If we have somebody who knows them better tell me. For my system: [root@workstation64 andyrtr]# env LANG=C pacman -Qi libgpg-error libgcrypt | grep Required Required By : dirmngr gpgme libgcrypt libksba Required By : cryptsetup dirmngr gnupg2 libnetworkmanager libxslt Test any of these packages and tell me if you find something broken. -Andy

-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Dan McGee Verzonden: dinsdag 8 januari 2008 16:22 Aan: Public mailing list for ArchLinux development Onderwerp: Re: [arch-dev-public] [signoff] libgpg-error 1.6-1 + libgcrypt-1.4.0-1

http://bugs.archlinux.org/task/9114

So...we have some issues here, and this got moved to core. I wanted to go back and see who signed off to see who tested, and am quite surprised to see not a single signoff for i686. Why on earth did this get moved out of testing?

Usually I don't like to point fingers at a single person, but we had a clear breakdown of policy here, and its hard to spread the blame.

-Dan

I tested on amd64 and didn't see anything weird there. As far as I can remember we had reports of working packages from Hussam about this one, but for the rest there's no confirmation about the state on i686.

On Tue, 2008-01-08 at 09:40 -0600, Aaron Griffin wrote:

On Jan 8, 2008 9:22 AM, Dan McGee wrote:

...

http://bugs.archlinux.org/task/9114

So...we have some issues here, and this got moved to core. I wanted to go back and see who signed off to see who tested, and am quite surprised to see not a single signoff for i686. Why on earth did this get moved out of testing?

Usually I don't like to point fingers at a single person, but we had a clear breakdown of policy here, and its hard to spread the blame.

Thanks for pointing this out Dan. It is true. We didn't have any signoffs here for i686. I brought up the topic of testing, but do not actually use any of the encryption and pgp type stuff, so wouldn't even know where to begin.

This little testing policy was put in place for a reason. Not to make people's lives harder, but, in fact to make them easier. Less errors are a good thing. And the first time we let our policy collapse, we have (according to that bug report) at least 3 packages crashing due to this update that was pushed to core inappropriately.

Andy, next time please be more careful. Now we have to mop up a mess created by being too hasty.

So, do we rollback the libgcrypt in core, or do we wait? Jan, you appear to have done some investigation - could you fill us in?

I think it's wise to disable the padlock engine in libgcrypt. I took a look at the code, this is what I found: --disable-padlock-support Disable support for the PadLock engine of VIA processors. The default is to use PadLock if available. Try this if you get problems with assembler code. So this is all about VIA chips. How many users do we have with VIA chips and how many of them use the padlock engine? Then looking at the valgrind reports, there's a bug in _gcry_detect_hw_features. This function sets hw_features to 0 and then has some ifdef code that will check for __i386__. If it's __i386__ (which is not true on amd64), the detect_ia32_gnuc() function is called. This function only tests for a VIA processor with padlock engine. I might have tracked down the bug though. According to bugreports, the invalid read of size 1 is at line 95 in that file, which is a strcmp operation on a variable that has been terminated by a 0 sign instead of a NULL character. I'll upload a package with the fix so people can test. If I have one report of the package fixing the problem, I'd like to have it moved to i686 core.

On Tue, 2008-01-08 at 09:40 -0600, Aaron Griffin wrote:

On Jan 8, 2008 9:22 AM, Dan McGee wrote:

...

http://bugs.archlinux.org/task/9114

So...we have some issues here, and this got moved to core. I wanted to go back and see who signed off to see who tested, and am quite surprised to see not a single signoff for i686. Why on earth did this get moved out of testing?

Usually I don't like to point fingers at a single person, but we had a clear breakdown of policy here, and its hard to spread the blame.

Thanks for pointing this out Dan. It is true. We didn't have any signoffs here for i686. I brought up the topic of testing, but do not actually use any of the encryption and pgp type stuff, so wouldn't even know where to begin.

This little testing policy was put in place for a reason. Not to make people's lives harder, but, in fact to make them easier. Less errors are a good thing. And the first time we let our policy collapse, we have (according to that bug report) at least 3 packages crashing due to this update that was pushed to core inappropriately.

Andy, next time please be more careful. Now we have to mop up a mess created by being too hasty.

So, do we rollback the libgcrypt in core, or do we wait? Jan, you appear to have done some investigation - could you fill us in?

libgcrypt 1.4.0-1.1-i686.pkg.tar.gz is in core now. I disabled VIA padlock support and one of the reporters confirmed the bug as fixed with this version.