Hi,
Using Ubuntu 18, i have a segfault after update and recompilation of notmuch at
commit 73cebe6e7233f59ba26d9f7c05265b7776795818 (HEAD -> master, origin/master,
origin/HEAD)
Running : notmuch new
(process:29765): GLib-GObject-WARNING **: 10:33:54.858: cannot register existing
type 'GMimeStream
Daniel Kahn Gillmor writes:
> ---
> NEWS | 7 +++
> 1 file changed, 7 insertions(+)
pushed both to master. I had to resolve conflicts so you might check
that I didn't mangle things too badly.
d
___
notmuch mailing list
notmuch@notmuchmail.org
htt
Daniel Kahn Gillmor writes:
> On Mon 2019-05-27 07:46:55 -0300, David Bremner wrote:
>> +Dependencies
>> +
>> +
>> +Support for GMime 2.6 is removed.
>> +
>
> I'd add here:
>
> The minimum supported version of GMime is now 3.0.3. GMime also needs
> to have been compiled with cryptogr
rey-coyrehourcq writes:
> Hi,
> Using Ubuntu 18, i have a segfault after update and recompilation of notmuch
> at
> commit 73cebe6e7233f59ba26d9f7c05265b7776795818 (HEAD -> master,
> origin/master,
> origin/HEAD)
Are you running 18.04 or 18.10? Travis is currently successfuly running
the no
Daniel Kahn Gillmor writes:
> decrypted?: {
>status: msgdecstatus,
> + # map encrypted headers that differed from the outside
> headers.
> + # the value of each item in the map is what that field
> showed externally
> +
Hi,
I use 18.4.2 LTS.
I install the dependencies, compile and run the test which are all successfulls
(expect the three expected failures).
I have the same error when run notmuch new, the backtrace is :
(gdb) backtrace
#0 0x76969410 in g_mime_stream_construct () at
/usr/lib/x86_64-l
sebastien rey-coyrehourcq
writes:
> (gdb) backtrace
> #0 0x76969410 in g_mime_stream_construct () at
> /usr/lib/x86_64-linux-gnu/libgmime-3.0.so.0
> #1 0x7696d124 in g_mime_stream_fs_new_with_bounds () at
> /usr/lib/x86_64-linux-gnu/libgmime-3.0.so.0
> #2 0x77bc6f3f i
Finally found my problem,
I install notmuch into custom dir, and the declared PATH point to an old binary
in the wrong /bin folder.
I works now.
Sorry for that, and thanks David for your help.
Le mardi 28 mai 2019 à 09:59 -0300, David Bremner a écrit :
> sebastien rey-coyrehourcq writes:
> (gdb)
When showing a message that has been mangled in transit by an MTA in
the "Mixed up" way, "notmuch show" should instead show the repaired
form of the message.
Tracking the repaired GMimeObject for the lifetime of the mime_node so
that it is cleaned up properly is probably the trickiest part of this
This patch implements a functional identification and repair process
for "Mixed Up" MIME messages as described in
https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling-00#section-4.1
The detection test is not entirely complete, in that it does not
verify the contents of the latter
On Tue 2019-05-28 08:10:35 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>> decrypted?: {
>>status: msgdecstatus,
>> + # map encrypted headers that differed from the outside
>> headers.
>> + # the value of each item in the map
I've documented an unfortunate MTA habit over in
https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling-00#section-4.1
which i've named "Mixed Up" mangling. In particular, popular versions
of Microsoft Exchange take a multipart/encrypted e-mail and transform
it unaccountably to mul
Some MTAs mangle e-mail messages in transit in ways that are
repairable.
Microsoft Exchange (in particular, the version running today on
Office365's mailservers) appears to mangle multipart/encrypted
messages in a way that makes them undecryptable by the recipient.
I've documented this in section
When encountering a message that has been mangled in the "mixed up"
way by an intermediate MTA, notmuch should instead repair it and index
the repaired form.
When it does this, it also associates the index.repaired=mixedup
property with the message. If a problem is found with this repair
process,
On Tue 2019-05-28 18:54:48 -0400, Daniel Kahn Gillmor wrote:
> The test case included in this series should be sufficient to show the
> problem specifically
I forgot to mention: this test case makes use of the test_json_nodes
functionality introduced in 03/17 of the protected header series.
So pl
15 matches
Mail list logo