This is a fix for Ticket #3564. A key whose primary uid record has an
empty User-ID will result in the user being unable to use the key to
encrypt an email in mutt. This is because the mutt functions for key
selection iterate through the address fields of a key for matching against
and for displa
The previous patch introduced the possibility for addr to be null. Mutt
is surprisingly robust against null strings, but there are a few places
that should be wrapped in NONULL().
gnupgparse.c | 2 +-
pgpkey.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
# HG changeset p
The previous patch introduced the possibility for addr to be null. Mutt
is surprisingly robust against null strings, but there are a few places
that should be wrapped in NONULL().
gnupgparse.c | 2 +-
pgpkey.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
# HG changeset p
This patch series fixes Ticket #3564. Currently a key whose primary uid
has an empty User-ID can not be used for encryption in mutt.
The first patch changes parse_pub_line() to allow an empty User-ID field
for a pub record type. This will allow the key to have an address
record generated, althou
This is a fix for Ticket #3564. A key whose primary uid record has an
empty User-ID will result in the user being unable to use the key to
encrypt an email in mutt. This is because the mutt functions for key
selection iterate through the address fields of a key for matching against
and for displa
#3564: can't choose certain public keys for encryption even when specifying the
keyID
---+--
Reporter: likkk | Owner: mutt-dev
Type: defect| Status: new
Priority: critical | Milestone:
Component: mutt |Version: 1.
On Wed, Apr 10, 2013 at 03:50:10PM +, Michael Elkins wrote:
> On Wed, Apr 10, 2013 at 07:13:13AM -0600, Nicolas Bock wrote:
> >On Tue, Apr 09, 2013 at 04:33:47PM +, Michael Elkins wrote:
> >> On Tue, Apr 09, 2013 at 07:06:32AM -0600, Nicolas Bock wrote:
> >> >When I delete, that is move a m
>> And all of this work would be saved if mutt upstream released new
>> versions more frequently.
>
> That has been a recurring topic on this list, year over year. :-)
> Sometimes such threads, especially w.r.t. 1.6, initiate(d) a hustle to
> define milestones, clean up some tickets, and increase m
>> enough time on maintenance (we're all spread a lot thinner than we
>> used to be, I think, and I don't see that changing in the short
>> term). We know it's a big problem. We need more maintainers (not just
>> patch writers), but we're doing a terrible job of encouraging people
> I think there'
#3564: can't choose certain public keys for encryption even when specifying the
keyID
---+--
Reporter: likkk | Owner: kevin8t8
Type: defect| Status: assigned
Priority: critical | Milestone:
Component: mutt |Version
changeset: 6304:4c5163272b9c
user: Michael Elkins
date: Thu Apr 11 02:17:41 2013 +
link: http://dev.mutt.org/hg/mutt/rev/4c5163272b9c
backout c1371176ea45
diffs (313 lines):
diff -r f99e91980f0f -r 4c5163272b9c browser.c
--- a/browser.c Thu Apr 11 01:59:26 2013 +
+++ b/br
#3298: Mutt's way to get the FQDN is broken
-+--
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mutt|Version: 1.5.20
Resolution: | Keywords:
---
changeset: 6303:f99e91980f0f
user: Michael Elkins
date: Thu Apr 11 01:59:26 2013 +
link: http://dev.mutt.org/hg/mutt/rev/f99e91980f0f
Backed out changeset 1142ed8974fa
diffs (161 lines):
diff -r 1142ed8974fa -r f99e91980f0f getdomain.c
--- a/getdomain.c Wed Apr 10 23:40
[Apologies if this is a dup. It appears the mailing list ate my
previous patchbomb set.]
This patch series fixes Ticket #3564. Currently a key whose primary uid
has an empty User-ID can not be used for encryption in mutt.
The first patch changes parse_pub_line() to allow an empty User-ID field
#3298: Mutt's way to get the FQDN is broken
-+--
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mutt|Version: 1.5.20
Resolution: | Keywords:
---
#3298: Mutt's way to get the FQDN is broken
-+--
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mutt|Version: 1.5.20
Resolution: | Keywords:
---
#3298: Mutt's way to get the FQDN is broken
-+--
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: closed
Priority: major | Milestone:
Component: mutt|Version: 1.5.20
Resolution: fixed | Keywords:
-
changeset: 6302:1142ed8974fa
user: Michael Elkins
date: Wed Apr 10 23:40:18 2013 +
link: http://dev.mutt.org/hg/mutt/rev/1142ed8974fa
use gethostname() to determine the system host name
use getaddrinfo() to look up canonical DNS name, and fall back to hinting from
/etc/resolv
On Wed, Apr 10, 2013 at 03:59:37PM -0500, Derek Martin wrote:
>
> But, if you want to stick with the "odd is devel, even is stable"
> scheme, then I think roughly this is what should happen, essentially
> right now:
>
> - Something like head should be released as 1.6
> - The less "unobtainabl
On Wed, Apr 10, 2013 at 04:27:29PM +0200, Moritz Barsnick wrote:
> That has been a recurring topic on this list, year over year. :-)
> Sometimes such threads, especially w.r.t. 1.6, initiate(d) a hustle to
> define milestones, clean up some tickets, and increase mailing list
> traffic, but we sti
changeset: 6301:c1371176ea45
user: Michael Elkins
date: Wed Apr 10 22:38:47 2013 +
link: http://dev.mutt.org/hg/mutt/rev/c1371176ea45
fix various compiler warnings; most were due to unchecked return values from
system calls.
diffs (313 lines):
diff -r d498f0e91914 -r c137117
On Wed, Apr 10, 2013 at 09:52:03PM +0200, Fredrik Gustafsson wrote:
> I think that with a mature product as mutt is, we should always have a
> stable version, always "be ready to ship".
I more or less agree... the 1.5.x line IMO basically IS the defacto
stable branch now:
- There hasn't been a
On Wed, Apr 10, 2013 at 10:18:55AM -0500, David Champion wrote:
> The catch is that with current mutt, to cut a "release" an quantity of
> work needs to be qualified in some way: stable, or beta-worthy, or at
> least internally consistent. Otherwise a release is no different from
> any other commi
Michael Elkins wrote:
> I'm not familiar with that code, but your comment on the but report
> says that the gpgme driver can cope with it, so it's possible that
> the NULL addr field would be ok. You'd need to check where that
> struct gets used an ensure that the references to ->addr are
> protec
On Wed, Apr 10, 2013 at 12:02:25PM -0500, Derek Martin wrote:
On Tue, Apr 09, 2013 at 08:25:00PM -0700, Kevin J. McCarthy wrote:
So basically the patch would be something like:
case 10: /* name */
{
-if (!pend || !*p)
+if (!(pend && (*p || is_pub)))
On Tue, Apr 09, 2013 at 08:25:00PM -0700, Kevin J. McCarthy wrote:
> So basically the patch would be something like:
>case 10: /* name */
>{
> -if (!pend || !*p)
> +if (!(pend && (*p || is_pub)))
> break;/* empty field or no t
On Tue, Apr 09, 2013 at 08:25:00PM -0700, Kevin J. McCarthy wrote:
I'm working on ticket 3564. The reporter is unable to use a particular
key for encrypting an email. The essence of the problem is that the
key's primary uid record has an empty User-ID field.
The "gpg --list-keys" command retur
On Wed, Apr 10, 2013 at 04:27:29PM +0200, Moritz Barsnick wrote:
On Tue, Apr 09, 2013 at 18:17:28 +0200, Petr Pisar wrote:
And all of this work would be saved if mutt upstream released new
versions more frequently.
That has been a recurring topic on this list, year over year. :-)
Sometimes su
On Wed, Apr 10, 2013 at 07:13:13AM -0600, Nicolas Bock wrote:
On Tue, Apr 09, 2013 at 04:33:47PM +, Michael Elkins wrote:
On Tue, Apr 09, 2013 at 07:06:32AM -0600, Nicolas Bock wrote:
>When I delete, that is move a message to the [Gmail]/Trash folder,
>then sometimes mutt tells me that there
* On 09 Apr 2013, Petr Pisar wrote:
> distribitions have a testing phase where other people get involved. And all of
> this work would be saved if mutt upstream released new versions more
> frequently.
I think the fundamental parameter is not really time frequency but
distance: how much developm
On Tue, Apr 09, 2013 at 18:17:28 +0200, Petr Pisar wrote:
> And all of this work would be saved if mutt upstream released new
> versions more frequently.
That has been a recurring topic on this list, year over year. :-)
Sometimes such threads, especially w.r.t. 1.6, initiate(d) a hustle to
define
#3564: can't choose certain public keys for encryption even when specifying the
keyID
---+--
Reporter: likkk | Owner: mutt-dev
Type: defect| Status: new
Priority: critical | Milestone:
Component: mutt |Version: 1.
32 matches
Mail list logo
