Hello,
I found a security vulnerability in the APOP authentication. It is
related to recent collision attacks by Wang and al. against MD5. The
basic idea is to craft a pair of message-ids that will collide in the
APOP hash if the password begins in a specified way. So the attacker
would imperso
On Wed, Mar 14, 2007 at 11:15:27PM -0700, Brendan Cully wrote:
> On Thursday, 01 March 2007 at 16:23, Miroslav Lichvar wrote:
> > Ok, here is a patch that removes buffy_size completely and adds the
> > check_box_size option.
>
> Looks nice, thanks. But...
Thanks for looking into this.
> > Index:
Hi,
* Brendan Cully [07-03-14 13:21:51 -0700] wrote:
I've applied this, but I followed up with a patch that _always_ uses
realpath if stat succeeds, and doesn't do any other cleanup. The
remote URL users should be providing clean paths already.
After reading your patch I think the trailing sl
Hi,
* Gaëtan LEURENT [07-03-14 15:53:36 +0100] wrote:
This attack is really a practical one: it needs about an hour of
computation and a few hundred authentications from the client, and can
recover three password characters. I tested it against mutt, and
it does work.
Well, this is a difficu
Synopsis: Bug#413144: decrypt-save, -copy not documented
State-Changed-From-To: open->closed
State-Changed-By: cb
State-Changed-When: Thu, 15 Mar 2007 14:14:00 +0100
State-Changed-Why:
Fixed by auto-generating this manual part:
http://dev.mutt.org/hg/mutt/rev/dd5db5eba4fe
Comment added by
Rocco Rutte wrote on 15 Mar 2007 11:33:49 +0100:
> Well, this is a difficult issue. First, using hash algorithms always
> leaves us with the risk of collisions if it's only a theoretical one.
Sure, but a single collision is not a security threat... the problem
arises when you can construct coll
This patch is more or less copy'n'paste work to "sync" the manual
documentation on pattern groups with muttrc(5).
And while I'm at it, add some lines to muttrc(5) saying what these
groups are useful for. And while I'm at it, fix some style issues.
As reviewing the updated muttrc(5) revealed, ther
# HG changeset patch
# User Christoph Berg <[EMAIL PROTECTED]>
# Date 1173971448 -3600
# Node ID 2befb5b028d73cf7045b426f513d6b6c1c6a7681
# Parent fa6128cf9cba43cf25fc353d7d79377982a25a54
Remove reldate.h from EXTRADIST to fix out-of-tree builds from tarballs (and
remove some stray tabs).
diff -r
# HG changeset patch
# User Christoph Berg <[EMAIL PROTECTED]>
# Date 1173975665 -3600
# Node ID 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c
# Parent 2befb5b028d73cf7045b426f513d6b6c1c6a7681
Pull release date directly from Changelog.
diff -r 2befb5b028d7 -r 5c2f2072a4db doc/Makefile.am
--- a/doc/Mak
# HG changeset patch
# User Christoph Berg <[EMAIL PROTECTED]>
# Date 1173976786 -3600
# Node ID 50bc0121e4a8b1c638fa56451d477a7cf3b1cbce
# Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c
Remove absolute paths.
diff -r 5c2f2072a4db -r 50bc0121e4a8 contrib/gpg.rc
--- a/contrib/gpg.rcThu Mar 15
On Thu, 15 Mar 2007, Christoph Berg wrote:
# HG changeset patch
# User Christoph Berg <[EMAIL PROTECTED]>
# Date 1173976786 -3600
# Node ID 50bc0121e4a8b1c638fa56451d477a7cf3b1cbce
# Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c
Remove absolute paths.
The reason for the absolute paths is ve
On Mar 15, Thomas Dickey <[EMAIL PROTECTED]> wrote:
> The reason for the absolute paths is very likely to ensure that it
> does not pick up some random program named "gpg". (Making it configurable
> from a single point is probably a better way to go).
How many random programs named "gpg" are ther
Re: Thomas Dickey 2007-03-15 <[EMAIL PROTECTED]>
> The reason for the absolute paths is very likely to ensure that it
> does not pick up some random program named "gpg". (Making it configurable
> from a single point is probably a better way to go).
The proper way to deal with that is not to have
On Thu, 15 Mar 2007, Marco d'Itri wrote:
On Mar 15, Thomas Dickey <[EMAIL PROTECTED]> wrote:
The reason for the absolute paths is very likely to ensure that it
does not pick up some random program named "gpg". (Making it configurable
from a single point is probably a better way to go).
How m
On Thu, Mar 15, 2007 at 05:40:52PM +0100, Christoph Berg wrote:
> # Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c
> Remove absolute paths.
For what it's worth, I don't think this is a good change. The absolute path
will be correct for most systems, and does guard against rogue gpg's in the
pat
On Friday, 16 March 2007 at 00:07, Paul Walker wrote:
> On Thu, Mar 15, 2007 at 05:40:52PM +0100, Christoph Berg wrote:
>
> > # Parent 5c2f2072a4dbfa69f2db7a93ae52b984f65e165c
> > Remove absolute paths.
>
> For what it's worth, I don't think this is a good change. The absolute path
> will be cor
Re: Brendan Cully 2007-03-16 <[EMAIL PROTECTED]>
> I'd like to hear some more concrete examples of the dangers of looking
> up gpg in the path...
Ack. Just because gpg is a 'security' application doesn't make running
"ls" instead of "/bin/ls" less dangerous. Adding /usr/bin merely adds
clutter.
C
Synopsis: mime_forward does not work for text/rfc822-headers attachments
State-Changed-From-To: open->closed
State-Changed-By: cb
State-Changed-When: Fri, 16 Mar 2007 01:22:53 +0100
State-Changed-Why:
Report was mostly pebcak.
Comment added by cb on Fri, 16 Mar 2007 01:22:53 +0100
On Thu, Mar 15, 2007 at 05:15:26PM -0700, Brendan Cully wrote:
> On my OS X system, gpg lives in /sw/bin. Many others probably have it in
> /opt or /usr/local. I don't think /usr/bin is a particularly foolproof
Personally, I would still argue that /usr/bin is far and away the most
common. Most pe
* On 2007.03.15, in <[EMAIL PROTECTED]>,
* "Paul Walker" <[EMAIL PROTECTED]> wrote:
>
> Personally, I would still argue that /usr/bin is far and away the most
> common. Most people are running with gnupg supplied by their distro, and
I don't know if I agree with that. There are still a lo
* David Champion <[EMAIL PROTECTED]> [03-15-07 21:28]:
[...]
> I can think of two compromises:
> * as Thomas Dickey suggested, detect gpg at compile time and insert
> the correct path into the installed muttrc files;
this might be a problem for those using an rpm or dep install and/or
those who
On Thu, Mar 15, 2007 at 12:51:55PM -0400, Jean-Rene David wrote:
> * Derek Martin [2007.03.14 19:30]:
> > I consider this to be utterly and completely
> > broken, and I'm considering reporting it as a
> > bug, but I'm waiting to see what other people
> > think.
>
> From my limited understanding,
6 new changesets in mutt:
http://dev.mutt.org/hg/mutt/rev/4ade0c9660d5
changeset: 5004:4ade0c9660d5
tag: tip
user:Brendan Cully <[EMAIL PROTECTED]>
date:Thu Mar 15 16:29:42 2007 -0700
summary: Add reldate.h to BUILT_SOURCES
http://dev.mutt.org/hg/mutt/rev/ed804d94676
23 matches
Mail list logo
