| 2017-06-19 08:26:42 |
John Bester |
bug |
|
|
added bug |
| 2017-06-20 18:44:52 |
Andreas Hasenack |
apache2 (Ubuntu): importance |
Undecided |
High |
|
| 2017-06-20 18:44:57 |
Andreas Hasenack |
apache2 (Ubuntu): status |
New |
Triaged |
|
| 2017-06-20 18:45:03 |
Andreas Hasenack |
tags |
amd64 xenial |
amd64 server-next xenial |
|
| 2017-06-21 19:33:35 |
Andreas Hasenack |
apache2 (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-06-21 19:33:39 |
Andreas Hasenack |
apache2 (Ubuntu): status |
Triaged |
In Progress |
|
| 2017-06-22 14:34:12 |
Andreas Hasenack |
affects |
apache2 (Ubuntu) |
libapache2-mod-auth-pgsql (Ubuntu) |
|
| 2017-06-22 17:36:02 |
Andreas Hasenack |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865553 |
|
| 2017-06-22 17:36:02 |
Andreas Hasenack |
bug task added |
|
libapache2-mod-auth-pgsql (Debian) |
|
| 2017-06-22 17:38:52 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/libapache2-mod-auth-pgsql/+git/libapache2-mod-auth-pgsql/+merge/326173 |
|
| 2017-06-22 17:42:21 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2017-06-22 18:27:19 |
Bug Watch Updater |
libapache2-mod-auth-pgsql (Debian): status |
Unknown |
New |
|
| 2017-07-13 12:59:40 |
Andreas Hasenack |
attachment added |
|
artful-mod-auth-pgsql-null-check-1698758.debdiff https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-pgsql/+bug/1698758/+attachment/4914083/+files/artful-mod-auth-pgsql-null-check-1698758.debdiff |
|
| 2017-07-13 13:01:29 |
Gianfranco Costamagna |
libapache2-mod-auth-pgsql (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2017-07-13 14:50:46 |
Launchpad Janitor |
libapache2-mod-auth-pgsql (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2017-07-18 20:58:05 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/libapache2-mod-auth-pgsql/+git/libapache2-mod-auth-pgsql/+merge/327657 |
|
| 2017-07-18 21:02:36 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-07-18 21:02:36 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-07-18 21:02:36 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-07-18 21:05:08 |
Andreas Hasenack |
attachment added |
|
trusty-libapache2-mod-auth-pgsql.debdiff https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-pgsql/+bug/1698758/+attachment/4917187/+files/trusty-libapache2-mod-auth-pgsql.debdiff |
|
| 2017-07-18 21:10:12 |
Andreas Hasenack |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2017-07-18 21:14:55 |
Andreas Hasenack |
attachment removed |
trusty-libapache2-mod-auth-pgsql.debdiff https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-pgsql/+bug/1698758/+attachment/4917187/+files/trusty-libapache2-mod-auth-pgsql.debdiff |
|
|
| 2017-07-19 15:11:09 |
Robie Basak |
bug task added |
|
libapache2-mod-auth-pgsql (Ubuntu Trusty) |
|
| 2017-07-19 15:11:14 |
Robie Basak |
bug task added |
|
libapache2-mod-auth-pgsql (Ubuntu Xenial) |
|
| 2017-07-19 15:11:20 |
Robie Basak |
bug task added |
|
libapache2-mod-auth-pgsql (Ubuntu Zesty) |
|
| 2017-07-19 16:44:11 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Trusty): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-07-19 16:44:12 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-07-19 16:44:14 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Zesty): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2017-07-19 16:44:18 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Trusty): status |
New |
In Progress |
|
| 2017-07-19 16:44:21 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-07-19 16:44:25 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Zesty): status |
New |
In Progress |
|
| 2017-07-19 16:44:43 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2017-07-19 16:44:45 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-07-19 16:44:46 |
Andreas Hasenack |
libapache2-mod-auth-pgsql (Ubuntu Zesty): importance |
Undecided |
High |
|
| 2017-07-19 16:59:46 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/libapache2-mod-auth-pgsql/+git/libapache2-mod-auth-pgsql/+merge/327729 |
|
| 2017-07-19 17:01:05 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/libapache2-mod-auth-pgsql/+git/libapache2-mod-auth-pgsql/+merge/327730 |
|
| 2017-07-19 19:04:44 |
Andreas Hasenack |
description |
I have configured a .htaccess to use libapache2-mod-auth-pgsql to authenticate a user against a postgres database. The settings are as follows:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted off
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
If I set Auth_PG_encrypted to off, then authentication works but the downside is that I have to save plain unencrypted password on the database. If I set Auth_PG_encrypted to on, a segmentation fault occurs. A typical password to be contained in ApachePassword field is the following (for password "password"): "{SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=" - This matches exactly to what would be generated by htpasswd -s.
Here is the error log entry I get:
[pid 9662] AH00052: child pid 9670 exit signal Segmentation fault (11)
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apache2 2.4.18-2ubuntu3.2
ProcVersionSignature: Ubuntu 4.4.0-79.100-generic 4.4.67
Uname: Linux 4.4.0-79-generic x86_64
Apache2ConfdDirListing: False
Apache2Modules:
Error: command ['/usr/sbin/apachectl', '-D DUMP_MODULES'] failed with exit code 1: [Mon Jun 19 09:48:04.146971 2017] [so:warn] [pid 8403] AH01574: module dav_module is already loaded, skipping
apache2: Syntax error on line 140 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/session_dbd.load: Cannot load /usr/lib/apache2/modules/mod_session_dbd.so into server: /usr/lib/apache2/modules/mod_session_dbd.so: undefined symbol: ap_hook_session_save
Action '-D DUMP_MODULES' failed.
The Apache error log may have more information.
ApportVersion: 2.20.1-0ubuntu2.6
Architecture: amd64
Date: Mon Jun 19 09:47:34 2017
SourcePackage: apache2
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.apache2.apache2.conf: [modified]
modified.conffile..etc.apache2.mods-available.dav.load: [modified]
modified.conffile..etc.apache2.sites-available.000-default.conf: [modified]
mtime.conffile..etc.apache2.apache2.conf: 2017-06-03T16:27:12.439856
mtime.conffile..etc.apache2.mods-available.dav.load: 2017-06-03T16:31:51.028040
mtime.conffile..etc.apache2.sites-available.000-default.conf: 2016-11-11T14:57:50 |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages:
sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it:
$ sudo -u postgres -H createdb userdb
$ cat > /tmp/prepare.sql <<EOFEOF
CREATE TABLE UserLogin (Username text, ApachePassword text);
INSERT INTO UserLogin VALUES ('ubuntu-invalidhash', '{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=');
INSERT INTO UserLogin VALUES ('ubuntu-md5', '$1$0UiJQbpc$QoJQqJIT1DCHtQYGwJHZh0');
INSERT INTO UserLogin VALUES ('ubuntu-sha256', '$5$.oyALiVLtCvfBa$cvNlH7IxsirDkBN/vIvHB54p0MPwqxSyiulqnYVMxt/');
INSERT INTO UserLogin VALUES ('ubuntu-sha512', '$6$mbXQ/gDvUCn$Hs6sz8LAWN3fX1I/MoaJjsYSIYs8tqOUjgoQnXLY4X1dTSlBhbyiJYpTZZDEALXw.hRL97e7l/.xI7qZi0Phe.');
INSERT INTO UserLogin VALUES ('ubuntu-des', 'CYwwQkoOVS3oE');
EOFEOF
$ sudo -u postgres -H psql userdb -f /tmp/prepare.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:06:12 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages:
sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it:
$ sudo -u postgres -H createdb userdb
$ cat > /tmp/prepare.sql <<EOFEOF
CREATE TABLE UserLogin (Username text, ApachePassword text);
INSERT INTO UserLogin VALUES ('ubuntu-invalidhash', '{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=');
INSERT INTO UserLogin VALUES ('ubuntu-md5', '$1$0UiJQbpc$QoJQqJIT1DCHtQYGwJHZh0');
INSERT INTO UserLogin VALUES ('ubuntu-sha256', '$5$.oyALiVLtCvfBa$cvNlH7IxsirDkBN/vIvHB54p0MPwqxSyiulqnYVMxt/');
INSERT INTO UserLogin VALUES ('ubuntu-sha512', '$6$mbXQ/gDvUCn$Hs6sz8LAWN3fX1I/MoaJjsYSIYs8tqOUjgoQnXLY4X1dTSlBhbyiJYpTZZDEALXw.hRL97e7l/.xI7qZi0Phe.');
INSERT INTO UserLogin VALUES ('ubuntu-des', 'CYwwQkoOVS3oE');
EOFEOF
$ sudo -u postgres -H psql userdb -f /tmp/prepare.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it (http://pastebin.ubuntu.com/25127514/ for better formatting):
$ sudo -u postgres -H createdb userdb
$ cat > /tmp/prepare.sql <<EOFEOF
CREATE TABLE UserLogin (Username text, ApachePassword text);
INSERT INTO UserLogin VALUES ('ubuntu-invalidhash', '{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=');
INSERT INTO UserLogin VALUES ('ubuntu-md5', '$1$0UiJQbpc$QoJQqJIT1DCHtQYGwJHZh0');
INSERT INTO UserLogin VALUES ('ubuntu-sha256', '$5$.oyALiVLtCvfBa$cvNlH7IxsirDkBN/vIvHB54p0MPwqxSyiulqnYVMxt/');
INSERT INTO UserLogin VALUES ('ubuntu-sha512', '$6$mbXQ/gDvUCn$Hs6sz8LAWN3fX1I/MoaJjsYSIYs8tqOUjgoQnXLY4X1dTSlBhbyiJYpTZZDEALXw.hRL97e7l/.xI7qZi0Phe.');
INSERT INTO UserLogin VALUES ('ubuntu-des', 'CYwwQkoOVS3oE');
EOFEOF
$ sudo -u postgres -H psql userdb -f /tmp/prepare.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:06:39 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it (http://pastebin.ubuntu.com/25127514/ for better formatting):
$ sudo -u postgres -H createdb userdb
$ cat > /tmp/prepare.sql <<EOFEOF
CREATE TABLE UserLogin (Username text, ApachePassword text);
INSERT INTO UserLogin VALUES ('ubuntu-invalidhash', '{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=');
INSERT INTO UserLogin VALUES ('ubuntu-md5', '$1$0UiJQbpc$QoJQqJIT1DCHtQYGwJHZh0');
INSERT INTO UserLogin VALUES ('ubuntu-sha256', '$5$.oyALiVLtCvfBa$cvNlH7IxsirDkBN/vIvHB54p0MPwqxSyiulqnYVMxt/');
INSERT INTO UserLogin VALUES ('ubuntu-sha512', '$6$mbXQ/gDvUCn$Hs6sz8LAWN3fX1I/MoaJjsYSIYs8tqOUjgoQnXLY4X1dTSlBhbyiJYpTZZDEALXw.hRL97e7l/.xI7qZi0Phe.');
INSERT INTO UserLogin VALUES ('ubuntu-des', 'CYwwQkoOVS3oE');
EOFEOF
$ sudo -u postgres -H psql userdb -f /tmp/prepare.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it (contents of prepare.sql at http://pastebin.ubuntu.com/25127514/ for better formatting):
$ sudo -u postgres -H createdb userdb
$ cat > /tmp/prepare.sql <<EOFEOF
CREATE TABLE UserLogin (Username text, ApachePassword text);
INSERT INTO UserLogin VALUES ('ubuntu-invalidhash', '{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=');
INSERT INTO UserLogin VALUES ('ubuntu-md5', '$1$0UiJQbpc$QoJQqJIT1DCHtQYGwJHZh0');
INSERT INTO UserLogin VALUES ('ubuntu-sha256', '$5$.oyALiVLtCvfBa$cvNlH7IxsirDkBN/vIvHB54p0MPwqxSyiulqnYVMxt/');
INSERT INTO UserLogin VALUES ('ubuntu-sha512', '$6$mbXQ/gDvUCn$Hs6sz8LAWN3fX1I/MoaJjsYSIYs8tqOUjgoQnXLY4X1dTSlBhbyiJYpTZZDEALXw.hRL97e7l/.xI7qZi0Phe.');
INSERT INTO UserLogin VALUES ('ubuntu-des', 'CYwwQkoOVS3oE');
EOFEOF
$ sudo -u postgres -H psql userdb -f /tmp/prepare.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:07:40 |
Andreas Hasenack |
attachment added |
|
test-users.sql https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-pgsql/+bug/1698758/+attachment/4917783/+files/test-users.sql |
|
| 2017-07-19 19:08:20 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it (contents of prepare.sql at http://pastebin.ubuntu.com/25127514/ for better formatting):
$ sudo -u postgres -H createdb userdb
$ cat > /tmp/prepare.sql <<EOFEOF
CREATE TABLE UserLogin (Username text, ApachePassword text);
INSERT INTO UserLogin VALUES ('ubuntu-invalidhash', '{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=');
INSERT INTO UserLogin VALUES ('ubuntu-md5', '$1$0UiJQbpc$QoJQqJIT1DCHtQYGwJHZh0');
INSERT INTO UserLogin VALUES ('ubuntu-sha256', '$5$.oyALiVLtCvfBa$cvNlH7IxsirDkBN/vIvHB54p0MPwqxSyiulqnYVMxt/');
INSERT INTO UserLogin VALUES ('ubuntu-sha512', '$6$mbXQ/gDvUCn$Hs6sz8LAWN3fX1I/MoaJjsYSIYs8tqOUjgoQnXLY4X1dTSlBhbyiJYpTZZDEALXw.hRL97e7l/.xI7qZi0Phe.');
INSERT INTO UserLogin VALUES ('ubuntu-des', 'CYwwQkoOVS3oE');
EOFEOF
$ sudo -u postgres -H psql userdb -f /tmp/prepare.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:14:15 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use. Type "password" without the quotes when prompted:
$ sudo -u postgres -H createuser www -P
could not change directory to "/root": Permission denied
Enter password for new role:
Enter it again:
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file:
cat <<EOFEOF | sudo tee /var/www/html/.htaccess
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
EOFEOF
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these somewhere between the <virtualhost> lines:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
CREATE ROLE
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
GRANT
* Create the /var/www/html/.htaccess with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:22:59 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
CREATE ROLE
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
GRANT
* Create the /var/www/html/.htaccess with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:23:46 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:35:17 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
Testing ubuntu-invalidhash... FAIL
Testing ubuntu-md5... OK
Testing ubuntu-sha256... OK
Testing ubuntu-sha512... OK
Testing ubuntu-des... OK
The fixed version must have all tests with the result OK.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
To test each login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
The apache logs will show the segfault when ubuntu-invalidhash is tried:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
Trying just that one manually:
$ curl http://ubuntu-invalidhash:secret@localhost -o /dev/null -f
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (52) Empty reply from server
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ curl http://ubuntu-invalidhash:secret@localhost -o /dev/null -f
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 456 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 401
And the test loop will return 22 for that user, and no errors for the rest:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:41:21 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
ubuntu-invalidhash
ubuntu-md5
ubuntu-sha256
ubuntu-sha512
ubuntu-des
To test each login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
The apache logs will show the segfault when ubuntu-invalidhash is tried:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
Trying just that one manually:
$ curl http://ubuntu-invalidhash:secret@localhost -o /dev/null -f
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (52) Empty reply from server
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ curl http://ubuntu-invalidhash:secret@localhost -o /dev/null -f
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 456 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 401
And the test loop will return 22 for that user, and no errors for the rest:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:45:32 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
The libapache2-mod-auth-pgsql module will cause a segfault error in apache if its encrypted support is enabled ("Auth_PG_encrypted on") and a hash format not supported by crypt(3) is used.
Since this is an apache module, users might be tempted to use htpasswd(1) to generate such hashes. The option to generate SHA hashes (-s) in particular will generate a hash incompatible with crypt(3), which will then return NULL and cause the segfault in unpatched versions of this apache module.
The fix catches the situation when crypt(3) returns NULL and logs the event as an unsupported hash type being found, and denies the login.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
And we get this fact logged:
[Wed Jul 19 19:38:56.547337 2017] [auth_pgsql:error] [pid 10035:tid 140550732678912] [client 127.0.0.1:56946] [mod_auth_pgsql.c] - ERROR - PG user ubuntu-invalidhash: unsupported CRYPT format
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
|
| 2017-07-19 19:56:53 |
Andreas Hasenack |
description |
[Impact]
The libapache2-mod-auth-pgsql module will cause a segfault error in apache if its encrypted support is enabled ("Auth_PG_encrypted on") and a hash format not supported by crypt(3) is used.
Since this is an apache module, users might be tempted to use htpasswd(1) to generate such hashes. The option to generate SHA hashes (-s) in particular will generate a hash incompatible with crypt(3), which will then return NULL and cause the segfault in unpatched versions of this apache module.
The fix catches the situation when crypt(3) returns NULL and logs the event as an unsupported hash type being found, and denies the login.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
And we get this fact logged:
[Wed Jul 19 19:38:56.547337 2017] [auth_pgsql:error] [pid 10035:tid 140550732678912] [client 127.0.0.1:56946] [mod_auth_pgsql.c] - ERROR - PG user ubuntu-invalidhash: unsupported CRYPT format
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance |
[Impact]
The libapache2-mod-auth-pgsql module will cause a segfault error in apache if its encrypted support is enabled ("Auth_PG_encrypted on") and a hash format not supported by crypt(3) is used.
Since this is an apache module, users might be tempted to use htpasswd(1) to generate such hashes. The option to generate SHA hashes (-s) in particular will generate a hash incompatible with crypt(3), which will then return NULL and cause the segfault in unpatched versions of this apache module.
The fix catches the situation when crypt(3) returns NULL and logs the event as an unsupported hash type being found, and denies the login.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
And we get this fact logged:
[Wed Jul 19 19:38:56.547337 2017] [auth_pgsql:error] [pid 10035:tid 140550732678912] [client 127.0.0.1:56946] [mod_auth_pgsql.c] - ERROR - PG user ubuntu-invalidhash: unsupported CRYPT format
[Regression Potential]
The patch seems pretty straight forward and uses a well documented crypt(3) return value in the case of errors.
This is a very old module that hasn't been built in a while (see [other info] below. It's possible that just by rebuilding it with the new environment available in each ubuntu release since vivid could introduce unknowns. Hopefully, if that happens, it will be immediately noticed by the people who use it and will test this SRU.
[Other Info]
Upstream doesn't have a bugtracker or public code hosting that I could find, so I forwarded the patch via email. No response so far.
This module hasn't been rebuilt since vivid and seems unmaintained, being at version 2.0.3 since the precise days:
libapache2-mod-auth-pgsql | 2.0.3-5build2 | precise
libapache2-mod-auth-pgsql | 2.0.3-6 | trusty
libapache2-mod-auth-pgsql | 2.0.3-6.1 | vivid
libapache2-mod-auth-pgsql | 2.0.3-6.1 | xenial
libapache2-mod-auth-pgsql | 2.0.3-6.1 | yakkety
libapache2-mod-auth-pgsql | 2.0.3-6.1 | zesty
libapache2-mod-auth-pgsql | 2.0.3-6.1ubuntu1 | artful
- Debian's last changelog entry is from August 2013
- Fedora killed it in July 2011
- I couldn't find it in SuSE |
|
| 2017-07-19 19:59:43 |
Andreas Hasenack |
description |
[Impact]
The libapache2-mod-auth-pgsql module will cause a segfault error in apache if its encrypted support is enabled ("Auth_PG_encrypted on") and a hash format not supported by crypt(3) is used.
Since this is an apache module, users might be tempted to use htpasswd(1) to generate such hashes. The option to generate SHA hashes (-s) in particular will generate a hash incompatible with crypt(3), which will then return NULL and cause the segfault in unpatched versions of this apache module.
The fix catches the situation when crypt(3) returns NULL and logs the event as an unsupported hash type being found, and denies the login.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
And we get this fact logged:
[Wed Jul 19 19:38:56.547337 2017] [auth_pgsql:error] [pid 10035:tid 140550732678912] [client 127.0.0.1:56946] [mod_auth_pgsql.c] - ERROR - PG user ubuntu-invalidhash: unsupported CRYPT format
[Regression Potential]
The patch seems pretty straight forward and uses a well documented crypt(3) return value in the case of errors.
This is a very old module that hasn't been built in a while (see [other info] below. It's possible that just by rebuilding it with the new environment available in each ubuntu release since vivid could introduce unknowns. Hopefully, if that happens, it will be immediately noticed by the people who use it and will test this SRU.
[Other Info]
Upstream doesn't have a bugtracker or public code hosting that I could find, so I forwarded the patch via email. No response so far.
This module hasn't been rebuilt since vivid and seems unmaintained, being at version 2.0.3 since the precise days:
libapache2-mod-auth-pgsql | 2.0.3-5build2 | precise
libapache2-mod-auth-pgsql | 2.0.3-6 | trusty
libapache2-mod-auth-pgsql | 2.0.3-6.1 | vivid
libapache2-mod-auth-pgsql | 2.0.3-6.1 | xenial
libapache2-mod-auth-pgsql | 2.0.3-6.1 | yakkety
libapache2-mod-auth-pgsql | 2.0.3-6.1 | zesty
libapache2-mod-auth-pgsql | 2.0.3-6.1ubuntu1 | artful
- Debian's last changelog entry is from August 2013
- Fedora killed it in July 2011
- I couldn't find it in SuSE |
[Impact]
The libapache2-mod-auth-pgsql module will cause a segfault error in apache if its encrypted support is enabled ("Auth_PG_encrypted on") and a hash format not supported by crypt(3) is used.
Since this is an apache module, users might be tempted to use htpasswd(1) to generate such hashes. The option to generate SHA hashes (-s) in particular will generate a hash incompatible with crypt(3), which will then return NULL and cause the segfault in unpatched versions of this apache module.
The fix catches the situation when crypt(3) returns NULL and logs the event as an unsupported hash type being found, and denies the login.
[Test Case]
* install the packages on the Ubuntu release you are testing:
$ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
* create the database and populate it with the test users from the attached test-users.sql file:
$ sudo -u postgres -H createdb userdb
$ sudo -u postgres -H psql userdb -f test-users.sql
* Create the DB user we will use:
$ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
* Grant access:
$ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
* Create the /var/www/html/.htaccess file with this content:
AuthType basic
AuthName "My Auth"
Require valid-user
AuthBasicProvider pgsql
Auth_PG_authoritative On
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user www
Auth_PG_pwd password
Auth_PG_database userdb
Auth_PG_encrypted on
Auth_PG_pwd_table UserLogin
Auth_PG_uid_field Username
Auth_PG_pwd_field ApachePassword
* Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
<Directory /var/www/html>
AllowOverride AuthConfig
</Directory>
* Enable the mod-auth-pgsql module:
$ sudo a2enmod 000_auth_pgsql
* Restart apache:
$ sudo service apache2 restart
To try each test login, use a loop like this:
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; echo $?; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid 140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11), possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will just record a normal authentication problem for the ubuntu-invalidhash user (since the hash is not supported) instead of an "empty reply from server":
$ for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s; echo $?; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
And we get this fact logged:
[Wed Jul 19 19:38:56.547337 2017] [auth_pgsql:error] [pid 10035:tid 140550732678912] [client 127.0.0.1:56946] [mod_auth_pgsql.c] - ERROR - PG user ubuntu-invalidhash: unsupported CRYPT format
[Regression Potential]
The patch seems pretty straight forward and uses a well documented crypt(3) return value in the case of errors.
This is a very old module that hasn't been built in a while (see [other info] below. It's possible that just by rebuilding it with the new environment available in each ubuntu release since vivid could introduce unknowns. Hopefully, if that happens, it will be immediately noticed by the people who use it and will test this SRU.
[Other Info]
Upstream doesn't have a bugtracker or public code hosting that I could find, so I forwarded the patch via email. No response so far.
This module hasn't been rebuilt since vivid and seems unmaintained, being at version 2.0.3 since the precise days:
libapache2-mod-auth-pgsql | 2.0.3-5build2 | precise
libapache2-mod-auth-pgsql | 2.0.3-6 | trusty
libapache2-mod-auth-pgsql | 2.0.3-6.1 | vivid
libapache2-mod-auth-pgsql | 2.0.3-6.1 | xenial
libapache2-mod-auth-pgsql | 2.0.3-6.1 | yakkety
libapache2-mod-auth-pgsql | 2.0.3-6.1 | zesty
libapache2-mod-auth-pgsql | 2.0.3-6.1ubuntu1 | artful
- Debian's last changelog entry is from August 2013
- Fedora killed it in July 2011
- I couldn't find it in SuSE |
|
| 2017-07-19 21:22:04 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2017-07-27 14:24:45 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-08-01 16:16:00 |
Andreas Hasenack |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2017-08-02 11:51:47 |
Chris J Arges |
libapache2-mod-auth-pgsql (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-08-02 11:51:51 |
Chris J Arges |
bug |
|
|
added subscriber SRU Verification |
| 2017-08-02 11:51:54 |
Chris J Arges |
tags |
amd64 server-next xenial |
amd64 server-next verification-needed xenial |
|
| 2017-08-02 11:53:15 |
Chris J Arges |
libapache2-mod-auth-pgsql (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2017-08-02 11:55:05 |
Chris J Arges |
libapache2-mod-auth-pgsql (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-08-03 14:21:55 |
Andreas Hasenack |
tags |
amd64 server-next verification-needed xenial |
amd64 server-next verification-done-zesty verification-needed xenial |
|
| 2017-08-03 14:27:48 |
Andreas Hasenack |
tags |
amd64 server-next verification-done-zesty verification-needed xenial |
amd64 server-next verification-done-xenial verification-done-zesty verification-needed xenial |
|
| 2017-08-03 14:40:59 |
Andreas Hasenack |
tags |
amd64 server-next verification-done-xenial verification-done-zesty verification-needed xenial |
amd64 server-next verification-done-trusty verification-done-xenial verification-done-zesty verification-needed xenial |
|
| 2017-08-08 18:42:34 |
Andreas Hasenack |
tags |
amd64 server-next verification-done-trusty verification-done-xenial verification-done-zesty verification-needed xenial |
amd64 server-next verification-done verification-done-trusty verification-done-xenial verification-done-zesty xenial |
|
| 2017-08-10 15:50:16 |
Launchpad Janitor |
libapache2-mod-auth-pgsql (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2017-08-10 15:50:28 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-08-10 15:52:22 |
Launchpad Janitor |
libapache2-mod-auth-pgsql (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-08-10 15:55:32 |
Launchpad Janitor |
libapache2-mod-auth-pgsql (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2020-06-09 16:49:31 |
Robie Basak |
tags |
amd64 server-next verification-done verification-done-trusty verification-done-xenial verification-done-zesty xenial |
amd64 verification-done verification-done-trusty verification-done-xenial verification-done-zesty xenial |
|
| 2024-05-02 01:31:23 |
Bug Watch Updater |
libapache2-mod-auth-pgsql (Debian): status |
New |
Fix Released |
|
