Bug#470758: Does not reset current recursion level on new MAIL FROM

[Marcin Owsiany]

Package: libspf0
Version: 0.999-1.0.0-p3-3

Please have a look at #464029 for an example of the problem this causes.

Attached is a patch which fixes this within libspf (by resetting the
level in SPF_smtp_from()). I've tested it (together with the patch for
#392927) and it fixes the issue for me.

I am not simply reassigning the bug to libspf, because the library
maintainer/author might not think that changing its code is the correct
thing to do (and decide that the variable should be explicitly reset by
the library client). I have not been able to find any API documentation
which would support either view.

Also, it would be really nice if you could upload a fix for this and
#392927 to etch-proposed-updates...

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
--- libspf-0.999-1.0.0-p3.orig/src/libspf/main.c
+++ libspf-0.999-1.0.0-p3/src/libspf/main.c
@@ -1830,6 +1831,11 @@
   xvprintf("local-part: [%s]; domain: [%s]; sender: [%s]\n",
 p->local_part, p->current_domain, p->from);
 
+  /*
+   * We need to reset this, otherwise we'll hit the recursion limit after N rejected MAIL FROMs.
+   */
+  p->spf_rlevel = 0;
+
   return(SPF_TRUE);
 }
 

Bug#511342: does not check for file creation errors

[Marcin Owsiany]

Package: devtodo
Version: 0.1.19-3
Severity: grave
Justification: causes data loss

Here's how to reproduce:

| mowsi...@beczulka:/$ strace -t -o /tmp/tda-write-fail.log tda
| Enter text for the item you are adding.
| text> foo
| 1. veryhigh   2. high   3. medium   4. low   5. verylow   
| Enter a priority from those listed above.
| priority> medium
| Index of new item is 1
| todo: warning, created database (.todo) has group or world permissions
| mowsi...@beczulka:/$ echo $?
| 0
| mowsi...@beczulka:/$ ls -l .todo
| ls: .todo: No such file or directory
| mowsi...@beczulka:/$ 

Here's the relevant snippet from the strace log:

| 18:44:52 write(1, "\33[0m\33[32mIndex of new item is 1\33"..., 36) = 36
| 18:44:52 open(".todo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 
EACCES (Permission denied)
| 18:44:52 stat64(".todo", 0xbfe0b304)= -1 ENOENT (No such file or 
directory)
| 18:44:52 write(2, "todo: warning, created database "..., 33) = 33
| 18:44:52 write(2, ".todo", 5)   = 5
| 18:44:52 write(2, ") has group or world permissions", 32) = 32
| 18:44:52 write(2, "\n", 1)  = 1
| 18:44:52 exit_group(0)  = ?

Clearly the exit status nor the message do not reflect the fact that creating
the file failed, though apparently the program does pay attention to the fact
that open() failed, as there is no write() call visible.

Apart from the above, it would be good to check if the program correctly
detects write(), flush() and close() failures (e.g. when filesystem runs out of
space).

-- 
Marcin Owsiany  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#886907: libgadu: ftbfs due to -Werror and gnutls_compression_get_name deprecated

[Marcin Owsiany]

Apparently TLS compression is no longer available. The fix would be to
remove the call and the corresponding format in the gg_debug_session call
which uses it.