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.
CC: (none) => bgmilneWhiteboard: (none) => MGA2TOO, MGA1TOO
CC: (none) => bgmilne
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.
Status: NEW => ASSIGNED
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.
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.
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
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.
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
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
Version: Cauldron => 2Assignee: bugsquad => qa-bugsWhiteboard: MGA2TOO, MGA1TOO => MGA1TOO
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
Testing complete mga2 64 All tests successful.
Hardware: i586 => AllWhiteboard: MGA1TOO => MGA1TOO mga2-64-OK
Testing mga2 32
Testing mga1 64
Testing complete mga1 64 All tests succeeded
Whiteboard: MGA1TOO mga2-64-OK => MGA1TOO mga2-64-OK mga1-64-OK
Testing complete mga2 32 All tests succeded
Whiteboard: MGA1TOO mga2-64-OK mga1-64-OK => MGA1TOO mga2-64-OK mga2-32-OK mga1-64-OK
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]
CC: (none) => davidwhodgins
Note that I previously had kolab installed, but have since removed it. Is there some directory that I need to clean?
(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.
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.
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.
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
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.
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.
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)
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.
(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.
(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.
(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.
(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
CC: (none) => stormiWhiteboard: MGA1TOO mga2-64-OK mga2-32-OK mga1-64-OK => MGA1TOO mga2-64-OK mga2-32-OK mga1-64-OK mga1-32-OK
(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
(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.
(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 ...
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
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.
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.
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.
Validating. Please see comment 7 for advisory and srpm. Could sysadmin please push from core/updates_testing to core/updates. Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
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?
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?
(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)
(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.
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.
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0146
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
(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
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.