Debian Bug report logs - #221559
php4: db4 handler for dba doesn't correctly handle 'c' mode

version graph

Package: php4; Maintainer for php4 is (unknown);

Reported by: Matthew Palmer <mpalmer@debian.org>

Date: Wed, 19 Nov 2003 01:48:04 UTC

Severity: important

Found in version 4:4.3.3-3

Fixed in version php4/4:4.3.3-4

Done: Steve Langasek <vorlon@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Adam Conrad <adconrad@0c3.net>:
Bug#221559; Package php4. Full text and rfc822 format available.

Acknowledgement sent to Matthew Palmer <mpalmer@debian.org>:
New Bug report received and forwarded. Copy sent to Adam Conrad <adconrad@0c3.net>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Matthew Palmer <mpalmer@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: php4: db4 handler for dba doesn't correctly handle 'c' mode
Date: Wed, 19 Nov 2003 12:40:16 +1100
Package: php4
Version: 4:4.3.3-3
Severity: critical
Justification: causes serious data loss

Summary: When passed the 'c' mode, dba_open will truncate the database
arbitrarily, even if the database was previously perfectly all right.

libdb4.1 is 4.1.25-10 on this system.

Test code:

<?php

$h = dba_open('t.db4', 'c', 'db4');
if (!dba_insert('key', 'a value', $h))
{
        die("Insert failed\n");
}

dba_close($h);
unset($h);

$h = dba_open('t.db4', 'w', 'db4');

if (!dba_exists('key', $h))
{
        echo "'key' doesn't exist in the database on open with 'w'\n";
}

dba_close($h);
unset($h);

$h = dba_open('t.db4', 'c', 'db4');

if (!dba_exists('key', $h))
{
        echo "'key' doesn't exist in the database on open with 'c'\n";
}

The last echo statement will be printed, indicating that the database was in
fact truncated on open.

Editing the test code to use db2 and running it on a stable system gives the
expected results - no noise.  So I believe my reading of the documentation
to be correct (http://www.php.net/manual/en/function.dba-open.php) in the
intended action of 'c'.

This is pretty serious, as any code which uses 'c' assuming their data is
safe is going to find themselves diving for the backup tapes.  It's not
exactly excruciating, since I don't think that DBA is exactly the preferred
option these days, but for sure it's not something I want to be entering
stable.

If you want to downgrade this bug a bit, I'm happy with that, since the data
loss isn't serious for every one, but it'll sure surprise the hell out of
anyone who uses db4.  I certainly think it's release critical, though.

- Matt




Information forwarded to debian-bugs-dist@lists.debian.org, Adam Conrad <adconrad@0c3.net>:
Bug#221559; Package php4. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@netexpress.net>:
Extra info received and forwarded to list. Copy sent to Adam Conrad <adconrad@0c3.net>. Full text and rfc822 format available.

Message #10 received at 221559@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@netexpress.net>
To: Matthew Palmer <mpalmer@debian.org>, 221559@bugs.debian.org
Subject: Re: Bug#221559: php4: db4 handler for dba doesn't correctly handle 'c' mode
Date: Tue, 18 Nov 2003 20:18:42 -0600
[Message part 1 (text/plain, inline)]
On Wed, Nov 19, 2003 at 12:40:16PM +1100, Matthew Palmer wrote:
> Package: php4
> Version: 4:4.3.3-3
> Severity: critical
> Justification: causes serious data loss

> Summary: When passed the 'c' mode, dba_open will truncate the database
> arbitrarily, even if the database was previously perfectly all right.

> libdb4.1 is 4.1.25-10 on this system.

> Test code:

> <?php

> $h = dba_open('t.db4', 'c', 'db4');
> if (!dba_insert('key', 'a value', $h))
> {
>         die("Insert failed\n");
> }

> dba_close($h);
> unset($h);

> $h = dba_open('t.db4', 'w', 'db4');

> if (!dba_exists('key', $h))
> {
>         echo "'key' doesn't exist in the database on open with 'w'\n";
> }

> dba_close($h);
> unset($h);

> $h = dba_open('t.db4', 'c', 'db4');

> if (!dba_exists('key', $h))
> {
>         echo "'key' doesn't exist in the database on open with 'c'\n";
> }

> The last echo statement will be printed, indicating that the database was in
> fact truncated on open.

So if I'm reading this correctly, you're creating a new database by
opening with the 'c' option, ensuring that you've started with a clean
db4 database; written a record; closed and reopened, to check if the
record is still there; closed again and reopened with 'c', to find that
the database has been truncated?

Yes, I'd say that's a problem.

I don't know that I'd quite call it 'critical', since serious data loss
would first imply that someone is using PHP's DBA extension for
accessing serious data, and I've never heard of anyone doing that. ;)
Though any data loss is a grave bug, so it hardly matters.

> Editing the test code to use db2 and running it on a stable system gives the
> expected results - no noise.  So I believe my reading of the documentation
> to be correct (http://www.php.net/manual/en/function.dba-open.php) in the
> intended action of 'c'.

What happens if you try to use the db2 handler from the unstable
version?  Same thing, or does libdb4.1 not provide a db2-alike handler?

> This is pretty serious, as any code which uses 'c' assuming their data is
> safe is going to find themselves diving for the backup tapes.  It's not
> exactly excruciating, since I don't think that DBA is exactly the preferred
> option these days, but for sure it's not something I want to be entering
> stable.

Hmm, I don't recall DBA *ever* being the preferred option... <shrug>
That being the case, if no straightforward fix presents itself, I will
probably strip out the DBA support in order to get a viable php4 package
into testing, and then see what can be done to re-enable it prior to
release.

-- 
Steve Langasek
postmodern programmer
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Adam Conrad <adconrad@0c3.net>:
Bug#221559; Package php4. Full text and rfc822 format available.

Acknowledgement sent to Matthew Palmer <mpalmer@debian.org>:
Extra info received and forwarded to list. Copy sent to Adam Conrad <adconrad@0c3.net>. Full text and rfc822 format available.

Message #15 received at 221559@bugs.debian.org (full text, mbox):

From: Matthew Palmer <mpalmer@debian.org>
To: Steve Langasek <vorlon@netexpress.net>
Cc: 221559@bugs.debian.org
Subject: Re: Bug#221559: php4: db4 handler for dba doesn't correctly handle 'c' mode
Date: Wed, 19 Nov 2003 13:26:22 +1100
On Tue, Nov 18, 2003 at 08:18:42PM -0600, Steve Langasek wrote:
> So if I'm reading this correctly, you're creating a new database by
> opening with the 'c' option, ensuring that you've started with a clean
> db4 database; written a record; closed and reopened, to check if the
> record is still there; closed again and reopened with 'c', to find that
> the database has been truncated?

Correct.

> I don't know that I'd quite call it 'critical', since serious data loss
> would first imply that someone is using PHP's DBA extension for
> accessing serious data, and I've never heard of anyone doing that. ;)

<snicker>

PHPWiki uses it so I don't have to deal with creating a 'real' database in
MySQL or PostgreSQL.

> > Editing the test code to use db2 and running it on a stable system gives the
> > expected results - no noise.  So I believe my reading of the documentation
> > to be correct (http://www.php.net/manual/en/function.dba-open.php) in the
> > intended action of 'c'.
> 
> What happens if you try to use the db2 handler from the unstable
> version?  Same thing, or does libdb4.1 not provide a db2-alike handler?

dba_open doesn't accept db2 or db3 as a handler - I don't think it will use
libdb4.1's compatibility mode (assuming it has one, which I would presume it
would).

> That being the case, if no straightforward fix presents itself, I will
> probably strip out the DBA support in order to get a viable php4 package
> into testing, and then see what can be done to re-enable it prior to
> release.

That would suck, because it would leave large numbers of PHPWiki users with
a less-than-pleasant upgrade.  At any rate, I've worked around it in PHPWiki
by using 'w' if the DB exists and 'c' if it doesn't in the call to dba_open. 

I guess I'm about to do my first delving into PHP code, since I really,
really don't want DBA support to go away in PHP4.  It would make my
packaging life just that much more unpleasant.

- Matt



Information forwarded to debian-bugs-dist@lists.debian.org, Adam Conrad <adconrad@0c3.net>:
Bug#221559; Package php4. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@netexpress.net>:
Extra info received and forwarded to list. Copy sent to Adam Conrad <adconrad@0c3.net>. Full text and rfc822 format available.

Message #20 received at 221559@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@netexpress.net>
To: Matthew Palmer <mpalmer@debian.org>
Cc: 221559@bugs.debian.org
Subject: Re: Bug#221559: php4: db4 handler for dba doesn't correctly handle 'c' mode
Date: Tue, 18 Nov 2003 21:32:35 -0600
[Message part 1 (text/plain, inline)]
On Wed, Nov 19, 2003 at 01:26:22PM +1100, Matthew Palmer wrote:

> > I don't know that I'd quite call it 'critical', since serious data loss
> > would first imply that someone is using PHP's DBA extension for
> > accessing serious data, and I've never heard of anyone doing that. ;)

> <snicker>

> PHPWiki uses it so I don't have to deal with creating a 'real' database in
> MySQL or PostgreSQL.

Hmm, alright.

> > > Editing the test code to use db2 and running it on a stable system gives the
> > > expected results - no noise.  So I believe my reading of the documentation
> > > to be correct (http://www.php.net/manual/en/function.dba-open.php) in the
> > > intended action of 'c'.

> > What happens if you try to use the db2 handler from the unstable
> > version?  Same thing, or does libdb4.1 not provide a db2-alike handler?

> dba_open doesn't accept db2 or db3 as a handler - I don't think it will use
> libdb4.1's compatibility mode (assuming it has one, which I would presume it
> would).

Confirmed, 'db4' is the only handler name I can get to work.

> > That being the case, if no straightforward fix presents itself, I will
> > probably strip out the DBA support in order to get a viable php4 package
> > into testing, and then see what can be done to re-enable it prior to
> > release.

> That would suck, because it would leave large numbers of PHPWiki users with
> a less-than-pleasant upgrade.  At any rate, I've worked around it in PHPWiki
> by using 'w' if the DB exists and 'c' if it doesn't in the call to dba_open. 

> I guess I'm about to do my first delving into PHP code, since I really,
> really don't want DBA support to go away in PHP4.  It would make my
> packaging life just that much more unpleasant.

I'm also looking at the code, not having ruled out the possibility of a
quick fix.

For reference, this bug has also already been reported upstream, here:
<http://bugs.php.net/bug.php?id=26304>.

-- 
Steve Langasek
postmodern programmer
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Adam Conrad <adconrad@0c3.net>:
Bug#221559; Package php4. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@netexpress.net>:
Extra info received and forwarded to list. Copy sent to Adam Conrad <adconrad@0c3.net>. Full text and rfc822 format available.

Message #25 received at 221559@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@netexpress.net>
To: Matthew Palmer <mpalmer@debian.org>
Cc: 221559@bugs.debian.org
Subject: Re: Bug#221559: php4: db4 handler for dba doesn't correctly handle 'c' mode
Date: Tue, 18 Nov 2003 22:46:55 -0600
[Message part 1 (text/plain, inline)]
severity 221559 important
thanks

On Wed, Nov 19, 2003 at 01:26:22PM +1100, Matthew Palmer wrote:

> > That being the case, if no straightforward fix presents itself, I will
> > probably strip out the DBA support in order to get a viable php4 package
> > into testing, and then see what can be done to re-enable it prior to
> > release.

> That would suck, because it would leave large numbers of PHPWiki users with
> a less-than-pleasant upgrade.  At any rate, I've worked around it in PHPWiki
> by using 'w' if the DB exists and 'c' if it doesn't in the call to dba_open. 

> I guess I'm about to do my first delving into PHP code, since I really,
> really don't want DBA support to go away in PHP4.  It would make my
> packaging life just that much more unpleasant.

Alternative workaround derived from the code: open with mode 'c-'
instead of 'c'.

		case 'c':
			modenr = DBA_CREAT;
			lock_mode = (lock_flag & DBA_LOCK_CREAT) ? LOCK_EX : 0;
			file_mode = "a+b";
			if (!lock_mode || !lock_dbf) {
				break;
			}
			/* When we lock the db file it will be created before the handler
			 * even tries to open it, hence we must change to truncate mode.
                         */
		case 'n':
			modenr = DBA_TRUNC;

That seems like a rather drug-addled approach if you ask me; but it's
clearly intentional, and there's a straightforward workaround, so I
think the bug should be downgraded.

-- 
Steve Langasek
postmodern programmer
[signature.asc (application/pgp-signature, inline)]

Severity set to `important'. Request was from Steve Langasek <vorlon@netexpress.net> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Adam Conrad <adconrad@0c3.net>:
Bug#221559; Package php4. Full text and rfc822 format available.

Acknowledgement sent to "John Lucas" <john@lojo.net>:
Extra info received and forwarded to list. Copy sent to Adam Conrad <adconrad@0c3.net>. Full text and rfc822 format available.

Message #32 received at 221559@bugs.debian.org (full text, mbox):

From: "John Lucas" <john@lojo.net>
To: "Matthew Palmer" <mpalmer@debian.org>, <221559@bugs.debian.org>, "Steve Langasek" <vorlon@netexpress.net>
Cc: <221559@bugs.debian.org>
Subject: Re: Bug#221559: php4: db4 handler for dba doesn't correctly handle 'c' mode
Date: Wed, 19 Nov 2003 08:47:18 -0500
how do I unsubscribe to this mailing list!?

Thanks....




----- Original Message ----- 
From: "Matthew Palmer" <mpalmer@debian.org>
To: "Steve Langasek" <vorlon@netexpress.net>
Cc: <221559@bugs.debian.org>
Sent: Tuesday, November 18, 2003 9:26 PM
Subject: Bug#221559: php4: db4 handler for dba doesn't correctly handle 'c'
mode


> On Tue, Nov 18, 2003 at 08:18:42PM -0600, Steve Langasek wrote:
> > So if I'm reading this correctly, you're creating a new database by
> > opening with the 'c' option, ensuring that you've started with a clean
> > db4 database; written a record; closed and reopened, to check if the
> > record is still there; closed again and reopened with 'c', to find that
> > the database has been truncated?
>
> Correct.
>
> > I don't know that I'd quite call it 'critical', since serious data loss
> > would first imply that someone is using PHP's DBA extension for
> > accessing serious data, and I've never heard of anyone doing that. ;)
>
> <snicker>
>
> PHPWiki uses it so I don't have to deal with creating a 'real' database in
> MySQL or PostgreSQL.
>
> > > Editing the test code to use db2 and running it on a stable system
gives the
> > > expected results - no noise.  So I believe my reading of the
documentation
> > > to be correct (http://www.php.net/manual/en/function.dba-open.php) in
the
> > > intended action of 'c'.
> >
> > What happens if you try to use the db2 handler from the unstable
> > version?  Same thing, or does libdb4.1 not provide a db2-alike handler?
>
> dba_open doesn't accept db2 or db3 as a handler - I don't think it will
use
> libdb4.1's compatibility mode (assuming it has one, which I would presume
it
> would).
>
> > That being the case, if no straightforward fix presents itself, I will
> > probably strip out the DBA support in order to get a viable php4 package
> > into testing, and then see what can be done to re-enable it prior to
> > release.
>
> That would suck, because it would leave large numbers of PHPWiki users
with
> a less-than-pleasant upgrade.  At any rate, I've worked around it in
PHPWiki
> by using 'w' if the DB exists and 'c' if it doesn't in the call to
dba_open.
>
> I guess I'm about to do my first delving into PHP code, since I really,
> really don't want DBA support to go away in PHP4.  It would make my
> packaging life just that much more unpleasant.
>
> - Matt
>
>




Reply sent to Steve Langasek <vorlon@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Matthew Palmer <mpalmer@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #37 received at 221559-close@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 221559-close@bugs.debian.org
Subject: Bug#221559: fixed in php4 4:4.3.3-4
Date: Thu, 20 Nov 2003 12:02:43 -0500
Source: php4
Source-Version: 4:4.3.3-4

We believe that the bug you reported is fixed in the latest version of
php4, which is due to be installed in the Debian FTP archive:

caudium-php4_4.3.3-4_i386.deb
  to pool/main/p/php4/caudium-php4_4.3.3-4_i386.deb
php4-cgi_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-cgi_4.3.3-4_i386.deb
php4-curl_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-curl_4.3.3-4_i386.deb
php4-dev_4.3.3-4_all.deb
  to pool/main/p/php4/php4-dev_4.3.3-4_all.deb
php4-domxml_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-domxml_4.3.3-4_i386.deb
php4-gd_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-gd_4.3.3-4_i386.deb
php4-imap_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-imap_4.3.3-4_i386.deb
php4-ldap_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-ldap_4.3.3-4_i386.deb
php4-mcal_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-mcal_4.3.3-4_i386.deb
php4-mhash_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-mhash_4.3.3-4_i386.deb
php4-mysql_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-mysql_4.3.3-4_i386.deb
php4-odbc_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-odbc_4.3.3-4_i386.deb
php4-pear_4.3.3-4_all.deb
  to pool/main/p/php4/php4-pear_4.3.3-4_all.deb
php4-recode_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-recode_4.3.3-4_i386.deb
php4-snmp_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-snmp_4.3.3-4_i386.deb
php4-sybase_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-sybase_4.3.3-4_i386.deb
php4-xslt_4.3.3-4_i386.deb
  to pool/main/p/php4/php4-xslt_4.3.3-4_i386.deb
php4_4.3.3-4.diff.gz
  to pool/main/p/php4/php4_4.3.3-4.diff.gz
php4_4.3.3-4.dsc
  to pool/main/p/php4/php4_4.3.3-4.dsc
php4_4.3.3-4_i386.deb
  to pool/main/p/php4/php4_4.3.3-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 221559@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Steve Langasek <vorlon@debian.org> (supplier of updated php4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 21 Oct 2003 16:49:03 -0500
Source: php4
Binary: php4-cgi php4-sybase php4-recode php4-dev php4-snmp php4-odbc php4-xslt php4-mysql php4-domxml php4-gd php4-ldap php4-imap php4-curl php4 php4-mcal php4-pear caudium-php4 php4-mhash
Architecture: source i386 all
Version: 4:4.3.3-4
Distribution: unstable
Urgency: low
Maintainer: Adam Conrad <adconrad@0c3.net>
Changed-By: Steve Langasek <vorlon@debian.org>
Description: 
 caudium-php4 - A server-side, HTML-embedded scripting language
 php4       - A server-side, HTML-embedded scripting language
 php4-cgi   - A server-side, HTML-embedded scripting language
 php4-curl  - CURL module for php4
 php4-dev   - Files for PHP4 module development
 php4-domxml - XMLv2 module for php4
 php4-gd    - GD module for php4
 php4-imap  - IMAP module for php4
 php4-ldap  - LDAP module for php4
 php4-mcal  - MCAL calendar module for php4
 php4-mhash - MHASH module for php4
 php4-mysql - MySQL module for php4
 php4-odbc  - ODBC module for php4
 php4-pear  - PEAR - PHP Extension and Application Repository
 php4-recode - Character recoding module for php4
 php4-snmp  - SNMP module for php4
 php4-sybase - Sybase / MS SQL Server module for php4
 php4-xslt  - XSLT module for php4
Closes: 216889 221439 221559
Changes: 
 php4 (4:4.3.3-4) unstable; urgency=low
 .
   * Fix prerm script to remove mod_php4, *not* mod_perl, from the
     config (Closes: #216889).
   * Use /etc/$i/httpd.conf instead of /etc/$i to decide whether to
     call modules-config.
   * Don't invoke debconf unless we have to in the postinst, to reduce
     the risk of interactions between modules-config and our questions.
   * Add Dutch debconf translation; thanks to Tim Dijkstra
     <tim@famdijkstra.org> (closes: #221439).
   * Sync dba lock handling against upstream CVS HEAD, to fix a bug with
     truncating db4 files when opening with 'c' (create).
     (Closes: #221559).
Files: 
 3f9ccdbbbe950caba76c901a6e24878e 1500 web optional php4_4.3.3-4.dsc
 e7336df78115dec5f338936b34ac3381 562979 web optional php4_4.3.3-4.diff.gz
 0e94466dfc3a51a9dd06a69d3f4eeef9 778292 web optional php4_4.3.3-4_i386.deb
 568d070850366b9b057ef2cae7f01ba8 15828 web optional php4-curl_4.3.3-4_i386.deb
 5b7bf33124fcd7a5480ef9912413a698 35538 web optional php4-domxml_4.3.3-4_i386.deb
 fc8b34267f99bdb63003f9ee6c89925c 27044 web optional php4-gd_4.3.3-4_i386.deb
 3f12a6b28ee0863ce29fcbf698a5e87d 34204 web optional php4-imap_4.3.3-4_i386.deb
 f94b1b2a9ffc16db1bff7aac7aa1c81c 18840 web optional php4-ldap_4.3.3-4_i386.deb
 5fb732947397686331ef2810d1fad55a 16352 web optional php4-mcal_4.3.3-4_i386.deb
 fbbd1f4fe14b87a9fd691f0c4c0bc2f7 6848 web optional php4-mhash_4.3.3-4_i386.deb
 23041020a652e94d9ba931a24f53a421 20328 web optional php4-mysql_4.3.3-4_i386.deb
 8b3892a2959324cdf3b1b887d1ce5100 25764 web optional php4-odbc_4.3.3-4_i386.deb
 c3d81dfb93d1c771013bd98e4fa5b669 6506 web optional php4-recode_4.3.3-4_i386.deb
 935bed730092c516ae7c881a2569a343 15206 web optional php4-xslt_4.3.3-4_i386.deb
 1309af7c1d86fb1379c0f1139e0f5d6c 11600 web optional php4-snmp_4.3.3-4_i386.deb
 5ae177802bccf6611c5d306e312009eb 18578 web optional php4-sybase_4.3.3-4_i386.deb
 c351010e926fa2b998c56be20fcd19f7 1338266 web optional php4-cgi_4.3.3-4_i386.deb
 a2263e06231db436ab6e120cf6ec5dcf 781668 web optional caudium-php4_4.3.3-4_i386.deb
 9811f216c39d7b46f51f6de852a971db 794556 devel optional php4-dev_4.3.3-4_all.deb
 23b00b74851a1925a7f5d7649eec02a3 278374 web optional php4-pear_4.3.3-4_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/vN03KN6ufymYLloRAr81AKDOGGmVH773X/Ffnjz+vZcbOXjZ1ACdFCPi
mPAaA9iS+KFMfS64MLxL4Yc=
=JJJu
-----END PGP SIGNATURE-----




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 14:03:12 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.