Bug#316241: /var/cache/bind permissions
Yo!
I can't really see how this can happen at all - bind9's postinst will
"always" ("$1" == "configure" and "$uid" == 0 which should always be the
case in the post-installation script - why is the latter check there at
all?) set /var/cache/bind to root:bind and g+rw.
Can you (Martin Strauss) reproduce this?
cheers
-- vbi
--
Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro)
pgplqrGn4s3Rv.pgp
Description: PGP signature
Bug#304749: Fwd: Bug#304749: postgrey: remotely exploitable DoS vulnerability
On Friday 15 April 2005 14.03, martin f krafft wrote: > wenn ich bis morgen nichts von dir hÃre, dann kÃmmere ich mich drum. I'll package that tomorrow, ETA 14.00 +0100. Martin, I'd be happy if you could upload for me once more as this is urgent and I haven't read the dput/dupload/... docs yet. Do you care to stay in Uploaders: in the future, too? Thanks & HAND -- vbi -- featured product: vim - http://vim.org pgpmMpFfsKEXg.pgp Description: PGP signature
Bug#340709: Don't let rapple into testing
Package: rapple Version: 0.99cvs20051120-1 Severity: grave Justification: hold-rapple-in-unstable marker bug This package is based off a cvs snapshot, testing migration should wait until an official release is out. -- vbi -- He's dead, Jim. pgpm12CddV3qU.pgp Description: PGP signature
Bug#309257: Bug #309257: libpano12: patent problems
On Wednesday 22 June 2005 03.25, Florent Bayle wrote: [libpano12] > http://www.virtualproperties.com/noipix/patents.html suggests that there > is clear prior art in this case. I have taken this link from previous > discution on debian-legal. But Robert Jordens thinks that : > "The prior art argument is pretty much irrelevant in our question as long > as the legal status quo is different and the patent has not been > challanged." Wouldn't this be a case where pubpat could be asked to review the patent and try to challenge it? Debian is, after all, quite well-known, and if this patent really - has prior art and thus should be available, and - is enforced aggressively enough that some developers have been scared away, I think pubpat might be interested. (The two items above were hinted at in this discussion - I'm not familiar with the case, just jumping in.) cheers -- vbi -- Compatible: Gracefully accepts erroneous data from any source. pgpPoR5iZZIbg.pgp Description: PGP signature
Bug#340709: rapple - status extremely unclear
found 340709 1.0-1+b1 thanks (let's hope this works on such an old bug...) Yo! After some initial activity, I've not heard anything from upstream for many months now, and the project is still very young. So I'm not certain that it's a good idea to release rapple with a Debian release. cheers -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 pgpAOWyFf4tq1.pgp Description: PGP signature
Bug#380079: postgrey: postgrey on sarge AMD64 stops working in the moment the first contact on the Socket is made.
severity 380079 grave thanks On Thursday 27 July 2006 13:59, Christian Schlettig wrote: > File: postgrey > Justification: breaks unrelated software Which unrelated software does it break? Adjusting to grave, though personally I even think 'important' would be sufficient. > Version: 1.21-1sarge1 Did the security upgrade introduce this problem, i.e. it worked before? Can you reproduce it with the version from testing? > without knowing i think its kind of a compilation problem.. postgrey is a perl script, so I doubt ... ;-) But I agree, but probably the bug is in Net::Server or in perl. > Jul 27 11:18:26 mail kernel: postgrey[6026] general protection > rip:2a9687fd2c rsp:7fb640 error:0 Or, seeing this, in the kernel, perhaps? I'll try to have the AMD64 and/or Net::Server folks have a look at this. Thanks for the bug report. cheers -- vbi -- Alle schaffen hart für Knete, nur nicht Otto, der spielt Lotto. pgpjto9NxX9vM.pgp Description: PGP signature
Bug#380079: socket related problem in AMD64?
Yo! See #380079 for reference Christian Schletig reported the postgrey package not working on AMD64. Looking at the log message: > Jul 27 11:18:26 mail kernel: postgrey[6026] general protection rip:2a9687fd2c > rsp:7fb640 error:0 According to Christian the message occurs at the moment when postfix connects on the socket. I suspect it's not postgrey's problem (especially since postgrey is a perl script and should thus be platform independent. The protocol on the socket is text, so no word size/endianness issue on that front either.) Net::Server, perl or kernel? thanks for looking into it, if you have time. Please reassign to the correct place if you find I am correct. Or, of course, flame me if postgrey is at fault. Quoting from the bug report: -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.8-11-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages postgrey depends on: ii debconf1.4.30.13 Debian configuration management sy ii libberkeleydb-perl 0.26-3use Berkeley DB 4 databases from P ii libnet-dns-perl0.48-1Perform DNS queries from a Perl sc ii libnet-server-perl 0.87-3sarge1 An extensible, general perl server ii perl 5.8.4-8sarge3 Larry Wall's Practical Extraction ii ucf1.17 Update Configuration File: preserv cheers -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder <[EMAIL PROTECTED]> Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 pgpDWhDFoW1Jb.pgp Description: PGP signature
Bug#441152: libdb4.4: 4.4.20-8 -> 4.4.20-9 breaks txn_begin
Package: libdb4.4 Version: 4.4.20-9 Severity: grave Justification: totally breaks postgrey (don't hesitate to shoot back if it turns out that postgrey or libberkeleydb-perl is using libdb4.4 the wrong way :-) See #441069: txn_begin seems to fail with 4.4.20-9. Downgrading to 4.4.20-8 makes the problem go away (doesn't matter which version the database was created with.) cheers -- vbi P.S.: I didn't reassign the bug because I want to keep it open against postgrey as documentation for "my" users. -- Penetration testing ... [is] expensive, and you'll get a thick report when the testing is done. [...] Probably the safest thing you can do with the report, after you read it, is shred it. -- Bruce Schneier http://www.schneier.com/blog/archives/2007/05/is_penetration.html signature.asc Description: This is a digitally signed message part.
Bug#433351: postgrey: Hangs after changing of server's IP address
severity 433351 important thanks On Monday 16 July 2007 16.27:27 Plamen Tonev wrote: > Severity: grave > Justification: renders package unusable This is certainly not grave. Yes, it's important. I'll have to check this. But note that there will not be an update for sarge or even etch for this bug, since it's not security related. greetings Adrian von Bidder -- If you live to the age of a hundred you have it made because very few people die past the age of a hundred. -- George Burns signature.asc Description: This is a digitally signed message part.
Bug#386287: default install doesn't work with apache2: syntax error in apache config file
Package: egroupware
Version: 1.2-104.dfsg-1
Severity: grave
Justification: default installation causes apache to not start up anymore
Yo!
On a minimal etch installation (installed with beta3 installer just now), I
basically did "aptitude install egroupware egroupware-ldap postgresql-7.4
php4-{auth-pam,mcrypt,mhash}". Trying to connect to egroupware/setup/, I
noticed that apache wasn't running.
+++
opitegw:~# apache2ctl configtest
Syntax error on line 42 of /etc/apache2/conf.d/egroupware:
Invalid command 'Script', perhaps mis-spelled or defined by a module not
included in the server configuration
+++
turns out that mod_actions was not activated - is probabyl a one-line fix in
postinst.
cheers
-- vbi
--
According to my calculations the problem doesn't exist.
pgpPDyn5lX6bk.pgp
Description: PGP signature
