From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 81F916DE0F22 for ; Fri, 24 May 2019 18:34:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=-0.039, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqX9cSUAhCgL for ; Fri, 24 May 2019 18:34:40 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 3476C6DE0F21 for ; Fri, 24 May 2019 18:34:40 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1hULa0-0007yv-KN; Fri, 24 May 2019 21:34:36 -0400 Received: (nullmailer pid 31852 invoked by uid 1000); Sat, 25 May 2019 01:34:43 -0000 From: David Bremner To: Daniel Kahn Gillmor , Notmuch Mail Subject: Re: [PATCH v2 1/4] util/crypto: _notmuch_message_crypto: tracks message-wide crypto state In-Reply-To: <87blzr5zbi.fsf@fifthhorseman.net> References: <20190520032228.27420-1-dkg@fifthhorseman.net> <20190520032228.27420-2-dkg@fifthhorseman.net> <87zhnesmvm.fsf@tethera.net> <87blzr5zbi.fsf@fifthhorseman.net> Date: Fri, 24 May 2019 22:34:43 -0300 Message-ID: <87d0k7nwp8.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2019 01:34:41 -0000 Daniel Kahn Gillmor writes: > On Wed 2019-05-22 09:18:53 -0300, David Bremner wrote: >> Daniel Kahn Gillmor writes: >> >>> +static int >>> +_notmuch_message_crypto_cleanup (_notmuch_message_crypto_t *msg_crypto) >>> +{ >>> + if (!msg_crypto) >>> + return 0; >>> + if (msg_crypto->sig_list) >>> + g_object_unref (msg_crypto->sig_list); >>> + return 0; >>> +} >> >> we currently call destructors >> >> - *_destroy >> - *_destructor (the most popular option) >> - *_free >> >> Is there a good reason to introduce a fourth option? > > nope. I'm happy to stick with _destructor if you prefer it. Sounds good. >> >> It might be worth a comment here to explain the interaction between >> talloc and glib, i.e. why this is needed. > > OK, it'll be something like: > > / * This signature list needs to persist as long as the _n_m_crypto > * object survives. Increasing its reference counter prevents > * garbage-collection until after _n_m_crypto_destructor is called. */ Yep, sounds good. I only suggest it because I had to learn this stuff the hard way. > do you think i should move this explanation into the .c file instead of > the header? I think it's more important that it be visible to someone > saying "what are these statuses?" I could copy the text into the .c > file as well, but then i worry about keeping it in sync. Maybe just a > reference is sufficient? A reference is fine. > > Yes, PGP/MIME encrypted messages and signed from enigmail well-formed in > this sense. However, some mail transport agents (including mailman!) > mangle them in ways that may change the well-formedness. (see > https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling > for more discussion on the topic of mangled messages; i plan to submit > some patches to notmuch related to that work soon) > > My approach thus far around building the corpus of > cryptographically-protected e-mail has been to keep the examples > deliberately minimalist, so that they can be understood by someone > taking them apart and inspecting by hand. > > If someone wants a trove of real-world messy e-mails i certainly > wouldn't object to that (indeed, i'd be happy to help!), but i don't > think it should be a blocker to land this series. OK.