Hi all,
So we could do a lintian check that does something like
---
for file in /lib/security/pam_*.so; do
nm -D $file --defined-only | grep -v pam_
done
---
and fails on any results?
For the record:
---
/lib/security/pam_cap.so
00201660 A __bss_start
00201660 A _edata
00
On 8 March 2010 14:38, Erich Schubert wrote:
>
> * Use pam-auth-update together with the new setup file
> /usr/share/pam-configs/silent-ssh-single-sign-on to automatically
> enable the traditional functionality.
>
> My best guess is just that this new configuration setup caused the
> module t
On Mon, 2010-03-08 at 14:38 +0100, Erich Schubert wrote:
> I wonder whether there is a way to check for such errors automatically
> with lintian; they are bound to arise now and then, aren't they?
Symbol conflict errors happen somewhat often, and it's sometimes
difficult to detect them. I've had
Hi Rhonsa, Timo,
For me the bug just surfaced sometime in February 2010 on unstable.
So I'd assume it only surfaced for me with the 1.92-10 release.
But I never _configured_ libpam-ssh, and given that the changelog reads:
* Use pam-auth-update together with the new setup file
/usr/share/pam-c
tag 572266 + squeeze sid
thanks
* Timo Sirainen [2010-03-08 11:50:33 CET]:
> On 8.3.2010, at 12.03, Gerfried Fuchs wrote:
> >> Either rename buffer_free() on libpam-ssh's side, or mark it in some way
> >> internal to the shared library (I don't know how to do the latter, but I
> >> think it's pos
On 8.3.2010, at 12.03, Gerfried Fuchs wrote:
>> Either rename buffer_free() on libpam-ssh's side, or mark it in some way
>> internal to the shared library (I don't know how to do the latter, but I
>> think it's possible).
>
> As this bug has been reassigned without a version number the BTS
> con
Hi!
* Timo Sirainen [2010-03-05 21:07:30 CET]:
> On Fri, 2010-03-05 at 20:58 +0100, Jens Peter Secher wrote:
> > Timo Sirainen wrote:
> > >
> > > And the problem is specifically that Dovecot also has
> > > buffer_free() function.
> >
> > Can you elaborate on this?
>
> I mean both Dovec
On Fri, 2010-03-05 at 20:58 +0100, Jens Peter Secher wrote:
> Timo Sirainen wrote:
> >
> > And the problem is specifically that Dovecot also has buffer_free()
> > function.
>
> Can you elaborate on this?
I mean both Dovecot and libpam-ssh have an exported function called
buffer_free(). libpam-s
Timo Sirainen wrote:
>
> And the problem is specifically that Dovecot also has buffer_free() function.
Can you elaborate on this?
Cheers,
--
Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBS
On 5.3.2010, at 19.46, Erich Schubert wrote:
> Thank you - I should've come up with the gdb approach myself.
> As expected it is the fault of a PAM plugin, namely libpam-ssh:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08074f4e in buffer_free ()
And the problem is specifically t
reassign 572266 libpam-ssh
severity 572266 grave
affects 572266 dovecot-common
thanks
Reason for grave: breaks unrelated software.
(Not sure if the 'affects' syntax is right above, feel free to re-do
that. It makes sense to keep the bug listed as "affects" to avoid
resubmissions and help other dov
On Tue, 2010-03-02 at 19:49 +0100, Erich Schubert wrote:
> Mar 2 09:35:48 hepcat dovecot: auth(default):
> worker-server(erich,127.0.0.1): Aborted: Worker process died unexpectedly
> Mar 2 09:35:48 hepcat dovecot: dovecot: child 4865 (auth-worker) killed with
> signal 11 (core not dumped)
If
On Wed,03.Mar.10, 23:12:39, Marco Nenciarini wrote:
> Could you try to obtain a core after you have amended your configuration
> with the attached patch?
Still the same (no core dumps), but I got this:
# /etc/init.d/dovecot restart
Restarting IMAP/POP3 mail server: dovecotWarning: Corrected per
Andrei Popescu ha scritto:
> On Wed,03.Mar.10, 13:26:19, Marco Nenciarini wrote:
>
>> To obtain a core dump you should enable them in /etc/defaults/dovecot
>> and then restart the daemon with /etc/init.d/dovecot restart
>
> $ grep CORE /etc/default/dovecot
> ALLOW_COREDUMPS=1
>
>> You'll find
Hi Marco,
I'll do so tonight, when I'm at my home laptop again.
> > To obtain a core dump you should enable them in /etc/defaults/dovecot
> > and then restart the daemon with /etc/init.d/dovecot restart
I did that ...
> In syslog I still have "(core not dumped)".
... and had exactly this effect
On Wed,03.Mar.10, 13:26:19, Marco Nenciarini wrote:
> To obtain a core dump you should enable them in /etc/defaults/dovecot
> and then restart the daemon with /etc/init.d/dovecot restart
$ grep CORE /etc/default/dovecot
ALLOW_COREDUMPS=1
> You'll find the resulting core file as /var/run/dovec
Erich Schubert ha scritto:
> Package: dovecot-common
> Version: 1:1.2.10-1
> Severity: important
>
> On unstable with some bits (unrelated to dovecot) from Debian, dovecot-auth
> crashes during password authentication (using local evolution as client):
>
> Mar 2 09:35:48 hepcat dovecot: auth(def
Package: dovecot-common
Version: 1:1.2.10-1
Severity: important
On unstable with some bits (unrelated to dovecot) from Debian, dovecot-auth
crashes during password authentication (using local evolution as client):
Mar 2 09:35:48 hepcat dovecot: auth(default): worker-server(erich,127.0.0.1):
Abo
18 matches
Mail list logo
