Bug 6527 - openldap new security issue CVE-2012-1164
: openldap new security issue CVE-2012-1164
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
:
: lwn.net/Vulnerabilities/502712/
: MGA1TOO mga2-64-OK mga2-32-OK mga1-64...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2012-06-20 21:41 CEST by David Walser
Modified: 2012-08-05 02:49 CEST (History)
6 users (show)

See Also:
Source RPM: openldap-2.4.29-2.mga2.src.rpm
CVE:


Attachments
ldap.log (30.89 KB, text/plain)
2012-07-03 03:50 CEST, Dave Hodgins
Details

Description David Walser 2012-06-20 21:41:17 CEST
RedHat has issued an advisory today (June 20):
https://rhn.redhat.com/errata/RHSA-2012-0899.html

This was partially fixed in 2.4.29, but the last change didn't make it in until after (the third one linked in the RedHat bug):
https://bugzilla.redhat.com/show_bug.cgi?id=802514

Mageia 1, Mageia 2, and Cauldron are affected.
Comment 1 Buchan Milne 2012-06-20 21:59:06 CEST
Can you confirm the missing patch is http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=463c1fa25d45e393dc1f1ea235286f79e872fad0

I actually had this queued up, but wanted to update to 2.4.30, then there was version freeze etc.

Will look at this early tomorrow morning once confirmed.
Comment 2 David Walser 2012-06-20 22:36:45 CEST
Yes, that is the missing patch.

Note that all three patches are missing in Mageia 1, as it has 2.4.25.  The first two patches went into the 2.4.29 release.
Comment 3 Buchan Milne 2012-06-21 21:13:55 CEST
For cauldron, I have just submitted 2.4.31.

For Mageia 2, I submitted 2.4.29-2.1mga2 to core/updates_testing.

I will start looking at Mageia 1 now.
Comment 4 David Walser 2012-06-21 23:08:43 CEST
Updates for Mageia 2 and Cauldron built by Buchan.  Mageia 1 pending.

Saving the package list for later...
openldap-2.4.29-2.1.mga2
openldap-servers-2.4.29-2.1.mga2
openldap-clients-2.4.29-2.1.mga2
libldap2.4_2-2.4.29-2.1.mga2
libldap2.4_2-devel-2.4.29-2.1.mga2
libldap2.4_2-static-devel-2.4.29-2.1.mga2
openldap-doc-2.4.29-2.1.mga2
openldap-tests-2.4.29-2.1.mga2
openldap-testprogs-2.4.29-2.1.mga2

from openldap-2.4.29-2.1.mga2.src.rpm
Comment 5 Buchan Milne 2012-06-22 20:13:26 CEST
I have just submitted openldap-2.4.25-1.2mga1 to core/updates_testing for Mageia 1.

Packages should be available in just over an hour.
Comment 6 David Walser 2012-06-22 21:16:10 CEST
Update for Mageia 1 built by Buchan.  Full advisory to come.

openldap-2.4.25-1.2.mga1
openldap-servers-2.4.25-1.2.mga1
openldap-clients-2.4.25-1.2.mga1
libldap2.4_2-2.4.25-1.2.mga1
libldap2.4_2-devel-2.4.25-1.2.mga1
libldap2.4_2-static-devel-2.4.25-1.2.mga1
openldap-doc-2.4.25-1.2.mga1
openldap-tests-2.4.25-1.2.mga1
openldap-testprogs-2.4.25-1.2.mga1

from openldap-2.4.25-1.2.mga1.src.rpm
Comment 7 David Walser 2012-06-22 21:21:31 CEST
Advisory:
========================

Updated openldap packages fix security vulnerability:

A denial of service flaw was found in the way the OpenLDAP server daemon
(slapd) processed certain search queries requesting only attributes and
no values. In certain configurations, a remote attacker could issue a
specially-crafted LDAP search query that, when processed by slapd, would
cause slapd to crash due to an assertion failure (CVE-2012-1164).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1164
https://rhn.redhat.com/errata/RHSA-2012-0899.html
========================

Updated packages in core/updates_testing:
========================
openldap-2.4.25-1.2.mga1
openldap-servers-2.4.25-1.2.mga1
openldap-clients-2.4.25-1.2.mga1
libldap2.4_2-2.4.25-1.2.mga1
libldap2.4_2-devel-2.4.25-1.2.mga1
libldap2.4_2-static-devel-2.4.25-1.2.mga1
openldap-doc-2.4.25-1.2.mga1
openldap-tests-2.4.25-1.2.mga1
openldap-testprogs-2.4.25-1.2.mga1
openldap-2.4.29-2.1.mga2
openldap-servers-2.4.29-2.1.mga2
openldap-clients-2.4.29-2.1.mga2
libldap2.4_2-2.4.29-2.1.mga2
libldap2.4_2-devel-2.4.29-2.1.mga2
libldap2.4_2-static-devel-2.4.29-2.1.mga2
openldap-doc-2.4.29-2.1.mga2
openldap-tests-2.4.29-2.1.mga2
openldap-testprogs-2.4.29-2.1.mga2

from SRPMS:
openldap-2.4.25-1.2.mga1.src.rpm
openldap-2.4.29-2.1.mga2.src.rpm
Comment 8 claire robinson 2012-06-30 17:36:16 CEST
Testing mga2 64

This is easy to test by installing openldap-tests

Start the ldap service

# service ldap start             (for mga1)

or

# systemctl start ldap.service   (for mga2)

Then

# cd /usr/share/openldap/tests/
# ./run all > ldaptest
# grep -e ">>>>>" ldaptest
Comment 9 claire robinson 2012-06-30 18:51:52 CEST
Testing complete mga2 64

All tests successful.
Comment 10 claire robinson 2012-07-01 21:43:36 CEST
Testing mga2 32
Comment 11 claire robinson 2012-07-01 21:46:55 CEST
Testing mga1 64
Comment 12 claire robinson 2012-07-01 22:06:58 CEST
Testing complete mga1 64
All tests succeeded
Comment 13 claire robinson 2012-07-01 22:43:55 CEST
Testing complete mga2 32
All tests succeded
Comment 14 Dave Hodgins 2012-07-02 03:47:09 CEST
On Mageia 1 i586, I'm getting
# service ldap start
awk: (FILENAME=/usr/share/openldap/schema/inetorgperson.schema FNR=155) fatal: cannot open file `/usr/share/openldap/schema/rfc2739.schema' for reading (No such file or directory)
Starting slapd (ldap + ldaps):                                                                      [FAILED]
Comment 15 Dave Hodgins 2012-07-02 03:49:10 CEST
Note that I previously had kolab installed, but have since removed it.

Is there some directory that I need to clean?
Comment 16 David Walser 2012-07-02 03:58:11 CEST
(In reply to comment #15)
> Note that I previously had kolab installed, but have since removed it.
> 
> Is there some directory that I need to clean?

That rfc2739.schema file comes from kolab, so it probably added it into your /etc/openldap/slapd.conf file somewhere.  Try and nuke it out of there or maybe reconfigure it from a fresh slapd.conf file.
Comment 17 Dave Hodgins 2012-07-02 08:28:19 CEST
Thanks.  I uninstalled openldap and openldap-servers, removed the directories
/etc/openldap, /var/lib/ldap*, then reinstalled the two packages, but still get

service ldap start
Starting slapd (ldap + ldaps):                                                                      [FAILED]

with no indication in any log file of why.  Running it under strace doesn't
show anything obvious.  I'll try installing it on a clean Mageia 1 install
later.
Comment 18 Dave Hodgins 2012-07-03 03:50:25 CEST
Created attachment 2518 [details]
ldap.log

Seems my "clean" Mageia 1 installation isn't clean enough.

It's still failing with
main: TLS init def ctx failed: -1

I can try doing a fresh install of Mageia 1, if you think that
will make the difference, but I'd rather figure out what is
actually causing it to fail.

I did try uninstalling, removing everything I could find related
to ldap including /etc/pki/tls/*/ldap.pem, and then reinstalling
but am still getting the failure.
Comment 19 David Walser 2012-07-03 03:55:56 CEST
Strange.  I haven't tried the update, but the current one works fine for me on Mageia 1.  I actually can't get TLS/SSL working on Mageia 2.  My setup is loosely based on Vincent Danen's documentation:
http://linsec.ca/usermgmt/openldap.php
Comment 20 David Walser 2012-07-03 20:59:19 CEST
OK, I found a few issues with the Mageia 2 package that haven't been addressed by this update.

First, when it is installing, you get an error message:
awk: cmd. line:1: warning: regexp component `[:space:]' should probably be `[[:space:]]'

Caused by a line early in %post servers:
dbs=`awk 'BEGIN {OFS=":"} /[:space:]*^database[:space:]*\w*/ {db=$2;suf="";dir=""}; /^[:space:]*suffix[:space:]*\w*/ {suf=$2;if((db=="bdb"||db=="ldbm")&&(suf!=""&&dir!="")) print dir,suf};/^[:space:]*directory[:space:]*\w*/ {dir=$2; if((db=="bdb"||db=="ldbm")&&(suf!=""&&dir!="")) print dir,suf};' "$SLAPDCONF" $(awk  '/^[[:blank:]]*include[[:blank:]]*/ {print $2}' "$SLAPDCONF")|sed -e 's/"//g'`

Second, on a server I upgraded at home, the ldap service will not start unless I comment out all the TLS stuff in slapd.conf.  I haven't been able to reproduce this setting up a server VM from scratch at work.

Finally, the openldap-migration package with the migration scripts from padl.com has gone missing.
Comment 21 claire robinson 2012-07-03 23:33:29 CEST
I don't get that problem mga2 64

# systemctl status ldap.service
ldap.service - LSB: LDAP servers (slapd)
          Loaded: loaded (/etc/rc.d/init.d/ldap)
          Active: active (running) since Tue, 03 Jul 2012 09:32:57 +0100; 12h ago
        Main PID: 2164 (slapd)
          CGroup: name=systemd:/system/ldap.service
                  └ 2164 /usr/sbin/slapd -u ldap -g ldap -l local4 -s 0 -h ldap:/// lda...

Jul 03 09:32:57 mega ldap[1682]: Starting slapd (ldap + ldaps): [  OK  ]

# systemctl restart ldap.service
# systemctl status ldap.service
ldap.service - LSB: LDAP servers (slapd)
          Loaded: loaded (/etc/rc.d/init.d/ldap)
          Active: active (running) since Tue, 03 Jul 2012 22:27:34 +0100; 20s ago
         Process: 1746 ExecStop=/etc/rc.d/init.d/ldap stop (code=exited, status=0/SUCCESS)
         Process: 1779 ExecStart=/etc/rc.d/init.d/ldap start (code=exited, status=0/SUCCESS)
        Main PID: 1801 (slapd)
          CGroup: name=systemd:/system/ldap.service
                  └ 1801 /usr/sbin/slapd -u ldap -g ldap -l local4 -s 0 -h ldap:/// lda...

Jul 03 22:27:34 mega ldap[1779]: Starting slapd (ldap + ldaps): [  OK  ]

# rpm -qa | grep openldap
openldap-testprogs-2.4.29-2.1.mga2
openldap-tests-2.4.29-2.1.mga2
openldap-extra-schemas-1.3-13.mga1
openldap-clients-2.4.29-2.1.mga2
openldap-2.4.29-2.1.mga2
openldap-servers-2.4.29-2.1.mga2

In the morning I'll try reinstalling again from Release and updating to check the %post error, I wonder if it's just i586 that has problems.
Comment 22 claire robinson 2012-07-03 23:35:38 CEST
From slapd.conf

# To allow TLS-enabled connections, create /etc/ssl/openldap/ldap.pem
# and uncomment the following lines.
#TLSRandFile            /dev/random
#TLSCipherSuite         HIGH:MEDIUM:+SSLv2
TLSCertificateFile      /etc/pki/tls/certs/ldap.pem
TLSCertificateKeyFile   /etc/pki/tls/private/ldap.pem
#TLSCACertificatePath   /etc/ssl/openldap/
#TLSCACertificateFile    /etc/ssl/cacert.pem
TLSCACertificateFile    /etc/pki/tls/certs/ldap.pem
#TLSVerifyClient never # ([never]|allow|try|demand)
Comment 23 claire robinson 2012-07-04 11:50:51 CEST
It seems the problems you're having with TLS may be due to us creating a separate bug (bug 4428) so that a previous security update (bug 3193) could be validated, the bug has not yet been addressed.

It seems it is a simple fix at least, but not a regression.
Comment 24 Buchan Milne 2012-07-04 13:02:06 CEST
(In reply to comment #20)
> OK, I found a few issues with the Mageia 2 package that haven't been addressed
> by this update.
> 
> First, when it is installing, you get an error message:
> awk: cmd. line:1: warning: regexp component `[:space:]' should probably be
> `[[:space:]]'
> 
> Caused by a line early in %post servers:
> dbs=`awk 'BEGIN {OFS=":"} /[:space:]*^database[:space:]*\w*/
> {db=$2;suf="";dir=""}; /^[:space:]*suffix[:space:]*\w*/
> {suf=$2;if((db=="bdb"||db=="ldbm")&&(suf!=""&&dir!="")) print
> dir,suf};/^[:space:]*directory[:space:]*\w*/ {dir=$2;
> if((db=="bdb"||db=="ldbm")&&(suf!=""&&dir!="")) print dir,suf};' "$SLAPDCONF"
> $(awk  '/^[[:blank:]]*include[[:blank:]]*/ {print $2}' "$SLAPDCONF")|sed -e
> 's/"//g'`

Looks like whoever fixed #5605 didn't look at this. I will fix it in cauldron, but it shouldn't be an issue unless someone is upgrading from Mandriva 2009 or something.

> Second, on a server I upgraded at home, the ldap service will not start unless
> I comment out all the TLS stuff in slapd.conf.

You would have to provide details, but usually this is due to certificates missing or permissions incorrect.

> I haven't been able to
> reproduce this setting up a server VM from scratch at work.
> 
> Finally, the openldap-migration package with the migration scripts from
> padl.com has gone missing.

AFAIK, we haven't ever shipped openldap-migration, I have been migrating it out of the package over some years (in Mandriva) and shipping it standalone as migrationtools. But, it seems migrationtools has not been imported into Mageia.
Comment 25 Buchan Milne 2012-07-04 13:05:14 CEST
(In reply to comment #23)
> It seems the problems you're having with TLS may be due to us creating a
> separate bug (bug 4428) so that a previous security update (bug 3193) could be
> validated, the bug has not yet been addressed.
> 
> It seems it is a simple fix at least, but not a regression.

bug 4428 should not be relevant to Mageia 2.
Comment 26 David Walser 2012-07-04 15:40:20 CEST
(In reply to comment #24)
> Looks like whoever fixed #5605 didn't look at this. I will fix it in cauldron,
> but it shouldn't be an issue unless someone is upgrading from Mandriva 2009 or
> something.

So it's just a harmless warning?  OK.

> You would have to provide details, but usually this is due to certificates
> missing or permissions incorrect.

Is there a good way to do this?  I tried running slapd directly with Config as the debug mode.  I saw that it was complaining about ldap.pem, but it did not say what the issue with it was.  I deleted it and it was regenerated automatically, but the same problem was still there.  Shouldn't the package handle this?

> AFAIK, we haven't ever shipped openldap-migration, I have been migrating it out
> of the package over some years (in Mandriva) and shipping it standalone as
> migrationtools. But, it seems migrationtools has not been imported into Mageia.

OK, I hadn't noticed it wasn't in Mageia 1.  It could be imported into updates_testing.
Comment 27 Samuel Verschelde 2012-07-08 21:38:33 CEST
(In reply to comment #8)
> Testing mga2 64
> 
> This is easy to test by installing openldap-tests 

/me dreams of a world where all packages come with a test suite :)

On MGA1 32, I've got the same as Dave : service ldap start fails due to bug #4428

After workarounding it, the testsuite complained a lot that it couldn't find /usr/bin/ldif-filter (several times for each test I think), so I can't tell whether the tests went fine or not, although the output suggests that all tests passed but one : ">>>>> ./scripts/test022-ppolicy failed for bdb (exit 80)"

Tests results are the same then those for the previous update, so there's no regression, but I'm still interested by answers to those questions which can be then addressed in another bug report.

In summary:
* 2 bugs found, one of which is already known (bug #4428) and for which it would be excellent to provide another update if that's possible
* no regression
Comment 28 David Walser 2012-07-09 02:54:46 CEST
(In reply to comment #20)
> Second, on a server I upgraded at home, the ldap service will not start unless
> I comment out all the TLS stuff in slapd.conf.  I haven't been able to
> reproduce this setting up a server VM from scratch at work.

OK, got it working on my server at home.  Made a comment on the details here:
https://bugs.mageia.org/show_bug.cgi?id=4428#c1
Comment 29 Buchan Milne 2012-07-09 11:41:24 CEST
(In reply to comment #8)
> Testing mga2 64
> 
> This is easy to test by installing openldap-tests

I note that the test suite is run on a default build of the package (including all builds on the build system). The test suite is provided for easy running of specific tests with possibly changes, and for the example configurations they provide.

> 
> Start the ldap service
> 
> # service ldap start             (for mga1)
> 
> or
> 
> # systemctl start ldap.service   (for mga2)
> 

It isn't necessary to start slapd to run the tests, the test suite starts its own instances.
Comment 30 Buchan Milne 2012-07-09 11:47:04 CEST
(In reply to comment #27)
> (In reply to comment #8)
> > Testing mga2 64
> > 
> > This is easy to test by installing openldap-tests 
> 
> /me dreams of a world where all packages come with a test suite :)

Even better, this package has its test suite run during every default build (can be disabled with --without test). But, this doesn't guarantee that the test suite we ship separately will work.

> 
> On MGA1 32, I've got the same as Dave : service ldap start fails due to bug
> #4428
> 
> After workarounding it, the testsuite complained a lot that it couldn't find
> /usr/bin/ldif-filter (several times for each test I think), so I can't tell
> whether the tests went fine or not, although the output suggests that all tests
> passed but one : ">>>>> ./scripts/test022-ppolicy failed for bdb (exit 80)"

ldif-filter was added in 2.4.29-1.mga2 for Mageia 2.

> 
> Tests results are the same then those for the previous update, so there's no
> regression, but I'm still interested by answers to those questions which can be
> then addressed in another bug report.

Is it *really* worth fixing? Or, more critically, is it really worthwhile delaying the security updates further?

> In summary:
> * 2 bugs found, one of which is already known (bug #4428) and for which it
> would be excellent to provide another update if that's possible
> * no regression

Both of which would actually be more useful via backports, so we should not really waste time delaying the security updates which could rather be spent on backports ...
Comment 31 claire robinson 2012-07-09 11:49:12 CEST
Is there a better way for us to test this Buchan? I remember one of these tests failing on a previous update so I think they're probably still useful.

We are trying to build a repository of testing procedures on the wiki, if you would like to contribute a procedure it would be gratefully received :)

See here:
https://wiki.mageia.org/en/Category:Testing_procedures

Thanks
Comment 32 Buchan Milne 2012-07-09 11:53:23 CEST
It is more than 2 weeks that the updates have been available in updates_testing, and people have been arguing about:
1)A message that appears during the update (that also would have appeared in an upgrade from Mandriva to Mageia 1) that has no significance.
2)A default configuration file which doesn't work, but that was like that at release of Mageia 1.
3)ldif-filter not shipped in the test suite, but the test suite is run during any build and must pass for the packages to complete ...

I can fix all 3 issues in minutes, but then new packages need to be built and tested, and when initially building the updates, I assumed we were targetting days and not weeks for patching remotely exploitable bugs. As such, I didn't go looking for every minor bug (as I would in a bugfix update).

Please, let me know what we can do to not delay these updates by another week.
Comment 33 David Walser 2012-07-09 12:00:35 CEST
I'm OK with releasing these now.  Since I initially couldn't get it working in Mageia 2 on my upgrade, I wanted to be sure nothing needed to be fixed in the package.  Now that I understand the issue, I know nothing needs to be done there.

As far as the message printed during the update, I don't remember seeing that during upgrade to Mageia 1.  Maybe it's a change in awk in Mageia 2 that it prints that warning now.  As long as it still *works* it's no big deal and can just be fixed in Cauldron.

I think we can validate this now.
Comment 34 claire robinson 2012-07-09 12:05:48 CEST
ldif-filter was a problem for the last update on mga1 also IIRC but it wasn't thought to be an issue at the time.

It is our duty to report bugs that we find during testing. I'm not sure why you feel that is delaying an update or arguing? I'm sure you realise that we test many many packages between openldap updates so are not instantly aware of which bugs are regressions and which are not. Testing for that takes further time, which we all obviously want to keep to a minimum.

We are short of people in the QA team which inevitably leads to delays so if your offer to help was sincere then we would be glad of it, thankyou. We have been asking for packagers to help with validating updates for several weeks :)

AFAICT testing is complete for this (going by the whiteboard) so we should validate. Unfortunately there is a large backlog of bugs waiting to be pushed by sysadmin at the moment though.

I'll validate this update now as testing seems completed.
Comment 35 claire robinson 2012-07-09 12:08:07 CEST
Validating.

Please see comment 7 for advisory and srpm.

Could sysadmin please push from core/updates_testing to core/updates.

Thanks!
Comment 36 claire robinson 2012-07-09 12:28:01 CEST
Now that is done do you think it would be wise to create a bugfix so these issues are not found again during testing next time Buchan?
Comment 37 Samuel Verschelde 2012-07-09 14:07:22 CEST
It looks like Buchan (In reply to comment #30)
> (In reply to comment #27)
> > 
> > Tests results are the same then those for the previous update, so there's no
> > regression, but I'm still interested by answers to those questions which can
> > then be addressed in another bug report.
> 
> Is it *really* worth fixing? Or, more critically, is it really worthwhile
> delaying the security updates further?

I said *which can then be addressed in another bug report*, who talked about delaying the security update?

> 
> > In summary:
> > * 2 bugs found, one of which is already known (bug #4428) and for which it
> > would be excellent to provide another update if that's possible
> > * no regression
> 
> Both of which would actually be more useful via backports, so we should not
> really waste time delaying the security updates which could rather be spent on
> backports ...

Why do some packagers seem to think that each time we ask a question we are going to block the update? I reported that there were no regressions, so we are validating the update, no need to be paranoid about QA blocking updates for every bug found. 

Can't we ask questions while we are testing the updates candidates?
Comment 38 Buchan Milne 2012-07-09 17:33:33 CEST
(In reply to comment #32)
> It is more than 2 weeks that the updates have been available in
> updates_testing, and people have been arguing about:
> 1)A message that appears during the update (that also would have appeared in an
> upgrade from Mandriva to Mageia 1) that has no significance.

This should have said upgrade from Mageia 1 to Mageia 2. I have fixed in svn for cauldron (r269073), Mageia 2 (r269074) and Mageia 1 (r269079)

> 2)A default configuration file which doesn't work, but that was like that at
> release of Mageia 1.

For what it is worth, I have fixed the default config file in Mageia 1 svn (r269079).

Refactoring the scripts should probably be done due to systemd requirements and back-config (/etc/openldap/slapd.d, which we don't use by default), and should probably do some validation and warning of the paths and types of files.

> 3)ldif-filter not shipped in the test suite, but the test suite is run during
> any build and must pass for the packages to complete ...

This only affects Mageia 1, and I have fixed in Mageia 1 svn (r269079)
Comment 39 Buchan Milne 2012-07-09 17:45:12 CEST
(In reply to comment #37)

> Why do some packagers seem to think that each time we ask a question we are
> going to block the update? I reported that there were no regressions, so we are
> validating the update, no need to be paranoid about QA blocking updates for
> every bug found. 
> 
> Can't we ask questions while we are testing the updates candidates?

Timelines for this bug:
1)Reported 2012-06-20 21:41:17 CEST
2)Responded: 2012-06-20 21:59:06 CEST
3)Fix for mga 2 submitted before 2012-06-21 21:13:55 CEST (24 hours)
4)Fix for mga 1 submitted before 2012-06-22 20:13:26 CEST
(all fixes available within 48 hours)
5)First test reported 2012-06-30 17:36:16 CEST
(more than a week later)
6)Testing by Claire completed on all releases by 2012-07-01 22:43:55 CEST
[....]
7)Validated 2012-07-09 12:05:48 CEST

Now, sure, I should have tried and put more effort into pushing bugfixes, but for security updates, surely testing should be done from a working starting point, and validating that nothing further is broken, not necessarily ensuring that all trivial bugfixes that haven't been looked at are addressed, while servers are potentially being DDoS'ed.

Otherwise, I should rather spend more time/place a higher priority on bugfixes (even if there are easy workarounds, or they have no impact on production use) and less time on security updates (though users will have no easy workarounds or resolutions besides building from source).

Unfortunately I don't have time for all my contribution (e.g. missing migrationtools package), let alone QA. However, for security bugs I usually try and drop whatever I can to get packages out.
Comment 40 claire robinson 2012-07-09 18:52:32 CEST
It's easy to say we should start from a working starting point but what you are seeing here is the fallout of not having the bugs fixed or any workarounds in the testing procedures, which weren't provided anyway as it happens.

We're not for the most part openldap users or even familiar with it but we do our best with too few people. We're not sysadmins either, so bugs which probably seem to have simple workarounds for you the maintainer who knows the package and configuration are anything but for us, which means they may well be for our users too.

It is our purpose to report any problems we find. If we find lots of problems during testing there will be lots to report. I'm afraid as much as people recently have been accusing us of 'ensuring all trivial bugs are fixed' in security updates it is not the truth of the matter and frankly that accusation is becoming tiresome now.

I'm sure the bugfix update will ease things if you decide to do it, however we are still short of people, we need the people to do the testing. It's a simple equation unfortunately.
Comment 41 Thomas Backlund 2012-07-09 19:17:13 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0146
Comment 42 Samuel Verschelde 2012-07-09 20:05:43 CEST
(In reply to comment #39)
> 5)First test reported 2012-06-30 17:36:16 CEST
> (more than a week later)
> 6)Testing by Claire completed on all releases by 2012-07-01 22:43:55 CEST
> [....]
> 7)Validated 2012-07-09 12:05:48 CEST
> 

Should be:
6) Testing by Claire completed on all releases but Mageia 1 64 by 2012-07-01 22:43:55 CEST
7) Testing on Mageia 1 64 by Dave, not completed due to failure to start the service, then he probably forgot about it or didn't have time to come back to this update candidate 
[....]
8) Testing by Stormi completed on Mageia 1 64 by 2012-07-08 21:38:33 CEST 
9) Validated 2012-07-09 12:05:48 CEST
Comment 43 Dave Hodgins 2012-08-05 02:49:16 CEST
Sorry about that.  My inbox got flooded a while back by a mass ping,
and I've been slow to get it sorted out, and have been busy with
other tests.  Now sorting out my inbox so I hopefully won't miss
outstanding ones like this.

Note You need to log in before you can comment on or make changes to this bug.