Re: [SECURITY] [DLA 1925-1] python2.7 security update
On Tue, Sep 17, 2019 at 07:18:54AM +0200, Pascal Hambourg wrote: > Le 16/09/2019 à 22:34, Roberto C. Sánchez a écrit : > > Package: python2.7 > > Version: 2.7.9-2+deb8u5 > > The i386 build failed. I just tried a local build and it succeeded. How do I request a give-back? Is it a bug against release.debian.org? (I tried the self-service give-back but it won't work on security suites.) Regards, -Roberto -- Roberto C. Sánchez
Re: [SECURITY] [DLA 1925-1] python2.7 security update
On 2019-09-17 14:24, Roberto C. Sánchez wrote: On Tue, Sep 17, 2019 at 07:18:54AM +0200, Pascal Hambourg wrote: Le 16/09/2019 à 22:34, Roberto C. Sánchez a écrit : > Package: python2.7 > Version: 2.7.9-2+deb8u5 The i386 build failed. I just tried a local build and it succeeded. How do I request a give-back? Is it a bug against release.debian.org? (I tried the self-service give-back but it won't work on security suites.) That's intentional, although I must admit that I'd forgotten about LTS's use of -security when I suggested it. You want debian-wb-team@l.d.o or #debian-buildd on OFTC. Regards, Adam
give-back for python2.7 2.7.9-2+deb8u5/jessie-security
wb-team folks, It was brought to my attention that my upload of python2.7 2.7.9-2+deb8u5 to jessie-security failed to build on i386. When I built locally the build succeeded, so I'd like to try a give-back. I attempted to use the self-service give-back site, but it will not operate on the security suites. Could someone reschedule python2.7 2.7.9-2+deb8u5 in jessie-security for another build attempt? Regards, -Roberto -- Roberto C. Sánchez
Re: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi Jan, On Thu, 12 Sep 2019 09:38:13 +0200 Jan Kowalsky wrote: > Hi Mike, > hi Hugo, > > > Am 11.09.19 um 14:04 schrieb Mike Gabriel: > > Hi Hugo, > > > > sorry for the late reply on this urgent matter. > > > > On So 08 Sep 2019 10:46:26 CEST, Hugo Lefeuvre wrote: > > > >> Sorry for the very late answer. For some reason, it looks like the LTS > >> team > >> was not aware of this bug... > >> > >> I am the one who provided these updates. This issue must have slipped > >> through my LDAP tests. I will investigate this as soon as possible and > >> provide a fix consequently. > >> > >> Mike, you did the latest 389-ds-base update. Did you notice anything > >> wrong > >> during your tests? > > > > For uploading 1.3.3.5-4+deb8u6, I unfortunately did not do much smoke > > testing regarding the LDAP query stuff (the patch was about indefinite > > SSL connection hangs). > > > > Let me know, if you need help looking into this (due to e.g. time > > constraints or what not on your side). > > as with version 1.3.5.17-2 everything worked fine, we didn't investiagte > further... > > So I can only report that we didn't encounter any errors with all the > versions shipped in debian 9. > > Regards > Jan I looked into this issue much deeper today and I cannot confirm the observation this bug was originally about. What I did: 1. Setup a fresh 389-ds instance using jessie's original version (see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/) 2. Upgrade to +deb8u4, test login, LDAP queries, etc. -> worked 3. Upgrade to +deb8u5, test login, LDAP queries, etc. -> worked 4. Upgrade to +deb8u6, test login, LDAP queries, etc. -> worked Can you be any chance provide more info about this issue? What exactly are the LDAP queries, that Nextcloud does on your 389-ds server? Can anyone else give feedback about 389-ds in jessie LTS? Any observed problems that look similar to #912224 [1]? Thanks+Greets, Mike [1] https://bugs.debian.org/912224
Re: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi,
On Di 17 Sep 2019 17:38:03 CEST, Mike Gabriel wrote:
What I did:
1. Setup a fresh 389-ds instance using jessie's original version
(see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)
2. Upgrade to +deb8u4, test login, LDAP queries, etc.
-> worked
3. Upgrade to +deb8u5, test login, LDAP queries, etc.
-> worked
4. Upgrade to +deb8u6, test login, LDAP queries, etc.
-> worked
Can you be any chance provide more info about this issue? What
exactly are the LDAP queries, that Nextcloud does on your 389-ds
server?
Can anyone else give feedback about 389-ds in jessie LTS? Any
observed problems that look similar to #912224 [1]?
Thanks+Greets,
Mike
[1] https://bugs.debian.org/912224
completing the story...
During package upgades, I see upgrade failures:
```
root@jessie:~# apt-get install 389-ds-base --reinstall
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu
entfernen und 0 nicht aktualisiert.
Es müssen noch 0 B von 1.459 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 137483 Dateien und Verzeichnisse sind derzeit
installiert.)
Vorbereitung zum Entpacken von .../389-ds-base_1.3.3.5-4+deb8u6_amd64.deb ...
Entpacken von 389-ds-base (1.3.3.5-4+deb8u6) über (1.3.3.5-4+deb8u6) ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
Trigger für systemd (215-17+deb8u13) werden verarbeitet ...
389-ds-base (1.3.3.5-4+deb8u6) wird eingerichtet ...
dpkg: Fehler beim Bearbeiten des Paketes 389-ds-base (--configure):
Unterprozess installiertes post-installation-Skript gab den
Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
389-ds-base
E: Sub-process /usr/bin/dpkg returned an error code (1)
```
The underlying reason of this is this:
```
root@jessie:~# setup-ds -u -s General.UpdateMode=offline
Use of literal control characters in variable names is deprecated at
/usr/lib/x86_64-linux-gnu/dirsrv/perl/DSCreate.pm line 867.
Could not rename config file
'/etc/dirsrv/slapd-jessie/slapd-collations.conf' to
'/var/lib/dirsrv/slapd-jessie/bak.bak/slapd-collations.conf'. Error:
Ungültiger Link über Gerätegrenzen hinweg
Error: could not update the directory server.
Exiting . . .
Log file is '/tmp/setupKkbY5z.log'
```
The fix for it (that one has to apply to
/usr/share/dirsrv/updates/60upgradeconfigfiles.pl and then run
"apt-get install -f") is this:
```
--- updates.orig/60upgradeconfigfiles.pl2018-09-03 09:58:45.911804203
+0200
+++ updates/60upgradeconfigfiles.pl 2018-09-03 09:59:36.420699451 +0200
@@ -31,7 +31,7 @@
next if (! -f $oldname); # does not exist - skip - already
(re)moved
my $newname = "$bakdir/$file";
$! = 0; # clear
-rename $oldname, $newname;
+move $oldname, $newname;
if ($!) {
push @errs, ["error_renaming_config", $oldname, $newname, $!];
}
@@ -57,7 +57,7 @@
next if (! -f $oldname); # does not exist - not backed up
my $newname = $inf->{slapd}->{config_dir} . "/" . $file;
next if (-f $newname); # not removed
-rename $oldname, $newname;
+move $oldname, $newname;
}
return @errs;
}
```
So, an improvement, we could offer is fixing the upgrade of
389-ds-base (which had been broken since jessie got released, in fact).
Greets,
Mike
--
DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
pgp3oOnx3FwNp.pgp
Description: Digitale PGP-Signatur
Re: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi Mike,
Am 17.09.19 um 17:38 schrieb Mike Gabriel:
> What I did:
>
> 1. Setup a fresh 389-ds instance using jessie's original version
> (see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)
>
> 2. Upgrade to +deb8u4, test login, LDAP queries, etc.
>
> -> worked
>
> 3. Upgrade to +deb8u5, test login, LDAP queries, etc.
>
> -> worked
>
> 4. Upgrade to +deb8u6, test login, LDAP queries, etc.
>
> -> worked
>
> Can you be any chance provide more info about this issue? What exactly
> are the LDAP queries, that Nextcloud does on your 389-ds server?
unfortunately not. It was an setup we don't have any more, we updated
nextcloud and moved to an newer ldap version. And in fact at that time I
couldn't figure out the exact problem since the queries worked when I
provided them via ldapsearch command line.
My notes about the error where:
nextcloud-log:
root@nextcloud:/etc# tail -f /srv/ncdata/nextcloud-demo/nextcloud.log
{"reqId":"U7vRHqej7uRmeA2JsBIf","level":3,"time":"2018-10-26T16:26:40+00:00","remoteAddr":"88.198.xx.xxx","user":"--","app":"PHP","method":"POST","url":"\/login?redirect_url=\/apps\/files\/%3Fdir%3D\/%26fileid%3D955&user=demo%40example.org","message":"ldap_control_paged_result_response():
Result is: Protocol error (2) at
\/opt\/nextcloud-demo\/apps\/user_ldap\/lib\/LDAP.php#74","userAgent":"Mozilla\/5.0
(X11; Linux x86_64; rv:52.0) Gecko\/20100101
Firefox\/52.0","version":"14.0.3.0"}
Note the: "Protocol error (2)"
When we encountered the bug we had an replication of multiple ldap
servers with slightly different versions:
Access log of the ldap server with 389-ds version 1.3.3.5-4+deb8u3:
[26/Oct/2018:16:32:41.929490646 +] conn=5364586 op=0 BIND
dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128
version=3
[26/Oct/2018:16:32:41.929803839 +] conn=5364586 op=0 RESULT err=0
tag=97 nentries=0 etime=0 dn="uid=owncloud-bind,ou=special
users,dc=example,dc=org"
[26/Oct/2018:16:32:41.987048655 +] conn=5364586 op=1 SRCH
base="dc=example,dc=org" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))"
attrs="entryuuid nsUniqueId objectguid guid ipauniqueid
distinguishedName uid samaccountname memberOf mail displayName
jpegPhoto thumbnailphoto"
[26/Oct/2018:16:32:41.987905862 +] conn=5364586 op=1 RESULT err=0
tag=101 nentries=1 etime=0 notes=P pr_idx=0 pr_cookie=-1
[26/Oct/2018:16:32:42.459561451 +] conn=5364586 op=2 UNBIND
[26/Oct/2018:16:32:42.459584128 +] conn=5364586 op=2 fd=825 closed - U1
Access log at the other one with 389-ds version 1.3.5.17-2:
[26/Oct/2018:18:29:19 +0200] conn=66 op=0 BIND
dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128
version=3
[26/Oct/2018:18:29:19 +0200] conn=66 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn="uid=owncloud-bind,ou=special users,dc=example,dc=org"
[26/Oct/2018:18:29:19 +0200] conn=66 op=1 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=1 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:19 +0200] conn=66 op=2 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=2 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:19 +0200] conn=66 op=3 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=3 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:32 +0200] conn=66 op=4 UNBIND
[26/Oct/2018:18:29:32 +0200] conn=66 op=4 fd=279 closed - U1
there ist an search base with "null" in access log. But this seems to
happen on the server side. Providing the same query on command line worked.
> Can anyone else give feedback about 389-ds in jessie LTS? Any observed
> problems that look similar to #912224 [1]?
Maybe we've been the only who where affected.
Kind regards
Jan
Re: since update 1.3.3.5-4+deb8u5 php ldap authentification failure
Hi again, Am 17.09.19 um 18:02 schrieb Mike Gabriel: > Hi, > completing the story... > > During package upgades, I see upgrade failures: > > ``` > root@jessie:~# apt-get install 389-ds-base --reinstall > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen > und 0 nicht aktualisiert. > Es müssen noch 0 B von 1.459 kB an Archiven heruntergeladen werden. > Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. > (Lese Datenbank ... 137483 Dateien und Verzeichnisse sind derzeit > installiert.) > Vorbereitung zum Entpacken von > .../389-ds-base_1.3.3.5-4+deb8u6_amd64.deb ... > Entpacken von 389-ds-base (1.3.3.5-4+deb8u6) über (1.3.3.5-4+deb8u6) ... > Trigger für man-db (2.7.0.2-5) werden verarbeitet ... > Trigger für systemd (215-17+deb8u13) werden verarbeitet ... > 389-ds-base (1.3.3.5-4+deb8u6) wird eingerichtet ... > dpkg: Fehler beim Bearbeiten des Paketes 389-ds-base (--configure): > Unterprozess installiertes post-installation-Skript gab den Fehlerwert > 1 zurück > Fehler traten auf beim Bearbeiten von: > 389-ds-base > E: Sub-process /usr/bin/dpkg returned an error code (1) > ``` I've reported this bug in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905184 But unfortunately it doesn't seemed to be backported to lts. In stretch it is fixed. Great that you did now also for jessie. Kind regards Jan
Re: give-back for python2.7 2.7.9-2+deb8u5/jessie-security
On 2019-09-17 16:35, Roberto C. Sánchez wrote: wb-team folks, It was brought to my attention that my upload of python2.7 2.7.9-2+deb8u5 to jessie-security failed to build on i386. When I built locally the build succeeded, so I'd like to try a give-back. I attempted to use the self-service give-back site, but it will not operate on the security suites. Could someone reschedule python2.7 2.7.9-2+deb8u5 in jessie-security for another build attempt? Done. Kind regards and thanks Philipp Kern
