[arch-dev-public] [signoff] libgpg-error 1.6-1 + libgcrypt-1.4.0-1

[Jan de Groot]

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