On Tue, 2008-01-08 at 09:40 -0600, Aaron Griffin wrote:
On Jan 8, 2008 9:22 AM, Dan McGee <dpmcgee@gmail.com> 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.