#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by lespocky):
I looked around a bit to find hints to solve this problem. First is
RFC3156 saying the following:
The "micalg" parameter for the "application/pgp-signature" protocol
MUST contain exactly one hash-symbol of
On Thursday, May 24, 2007 at 15:45:44 +0200, Rado Smiljanic wrote:
[The Comma]
> let's make it "official reservation"
Users are free to use this or any other binding scheme, at will:
I don't think that making this one official or even only preferred in
user docs makes much sense. Putting
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Changes (by MrTux):
* status: new => closed
* resolution: => fixed
Comment:
The following patch solves the problem:
{{{
Index: crypt-gpgme.c
===
RCS file: /home/r
On Tue, Jun 05, 2007 at 03:38:45PM -, Mutt wrote:
> + for (i = 4; buf[i] && i < sizeof buf; i++)
> + buf[i] = tolower(buf[i]);
If I've understood it right, if sizeof(buf) < 4 that loop will dereference
off the end of the array before checking the boundary condition. Maybe
switch
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by MrTux):
Replying to [comment:4 Paul Walker]:
> If I've understood it right, if sizeof(buf) < 4 that loop will
dereference
> off the end of the array before checking the boundary condition. Maybe
> switch the checks around?
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by Paul Walker):
{{{
On Tue, Jun 05, 2007 at 04:00:56PM -, Mutt wrote:
> But, in this case, I do not consider it critical; to create the
situation
> you refer to, the source code must be altered in an unlikely way.
Hav
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by Brendan Cully):
{{{
On Tuesday, 05 June 2007 at 15:38, Mutt wrote:
> #2901: wrong parameter micalg with mutt 1.5.15 and gpgme
>
> Changes (by MrTux):
>
> * status: new => closed
> * resolution: => fixed
You proba
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Changes (by MrTux):
* status: closed => reopened
* resolution: fixed =>
Comment:
Replying to [comment:7 Brendan Cully]:
> You probably don't want to close the bug until the patch has actually
> been applied. Otherwise there's a g
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by Sertaç Ö. Yıldız):
{{{
[05.Haz.07 15:38 -] Mutt:
> The following patch solves the problem:
[…]
> + if (!get_micalg (ctx, buf+4, sizeof buf - 4))
> +{
> + /*
> + * Convert result according to RFC3156
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by MrTux):
Replying to [comment:9 Sertaç Ö. Yıldız]:
> tolower() is not locale safe so this might not give what you intend to
> get on some (Turkish) locales. ascii_tolower() might be more
> appropriate.
Thanks for the sugges
#2901: wrong parameter micalg with mutt 1.5.15 and gpgme
Comment (by LeSpocky):
Replying to [comment:10 MrTux]:
> Thanks for the suggestion. I am not that familar with mutt, so I did not
know about function.
>
> Patch version 4 (second attachment) uses ascii_tolower and follows the
hint giv
On Tuesday, 22 May 2007 at 11:03, Christoph Berg wrote:
> # HG changeset patch
> # User Christoph Berg <[EMAIL PROTECTED]>
> # Date 1179405607 -7200
> # Node ID b8cc07db598c4302b14f27f972c1efb7e977d651
> # Parent 33af2883d52b99ece0a935818a91293b502603aa
> Temporarily set pipe_decode in the \cb url
#2515: Sorting by from or to in index is sometimes incorrect
Old description:
> {{{
> When a mailbox contains entries with "To" addresses that consist solely
> of the email address, then sorting in the index by "To" is sometimes
> inconsistent. An operation like "sort by to, sort by date, sort b
#2515: Sorting by from or to in index is sometimes incorrect
Changes (by [EMAIL PROTECTED]):
* status: new => closed
* resolution: => fixed
Comment:
(In [9e90789518ad]) Make sort by "To" stable (closes #2515).
compare_to() calls mutt_get_name(), which may return a static pointer
if it
14 matches
Mail list logo
