From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/28829 Path: main.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.gnus.general Subject: Re: MML, message-send-hook and automatically GnuPG-signing messages. Date: 18 Jan 2000 20:12:16 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: <87bt6j6vov.fsf@deneb.cygnus.argh.org> References: <87d7r25t6t.fsf@deneb.cygnus.argh.org> <87aem49cht.fsf@deneb.cygnus.argh.org> <87n1q38v8f.fsf@deneb.cygnus.argh.org> <87ya9n7al2.fsf@deneb.cygnus.argh.org> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035165607 31865 80.91.224.250 (21 Oct 2002 02:00:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:00:07 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by mailhost.sclp.com (Postfix) with ESMTP id 23BDCD051E for ; Tue, 18 Jan 2000 14:41:27 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id NAB03548; Tue, 18 Jan 2000 13:40:26 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 18 Jan 2000 13:39:48 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id NAA21833 for ; Tue, 18 Jan 2000 13:39:35 -0600 (CST) Original-Received: from mail.cid.net (cephyr.cid.net [212.172.21.2]) by mailhost.sclp.com (Postfix) with ESMTP id C5CF2D051E for ; Tue, 18 Jan 2000 14:39:25 -0500 (EST) Original-Received: from uucp by mail.cid.net (Exim 3.11) with local-bsmtp id 12AeTe-00045v-01; Tue, 18 Jan 2000 20:39:42 +0100 Original-Received: from deneb.cygnus.argh.org ([192.168.1.2] ident=exim) by cygnus.argh.org with esmtp (Exim 3.12 #1) id 12Ae61-00006m-00 for ding@gnus.org; Tue, 18 Jan 2000 20:15:17 +0100 Original-Received: from fw by deneb.cygnus.argh.org with local (Exim 3.12 #1) id 12Ae36-0005C5-00 for ding@gnus.org; Tue, 18 Jan 2000 20:12:16 +0100 Original-To: ding@gnus.org In-Reply-To: Jonas Steverud's message of "18 Jan 2000 17:00:33 +0100" Original-Lines: 47 User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.4 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:28829 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:28829 Jonas Steverud writes: > > Yes, that's the idea. You probably want to add extra information to the > > `<#encrypted>' tag, for example the recpients' key ID. > > Could you please explain what you ment with that? I have spend almost > half the day hacking on this so if you have some idea on how to make > my life more easy I am most happy to listen. By private mail, I'll send you all my code and some discussion which has taken place on this list over a year ago. > The probelm with the code > you presented was that mc/gnupg did not find any information regarding > whom to send to. Well, it was a crude hack to see which interfaces are necessary. > I have made a hack for that (an additional argument to > rfc2015-generate-enclosed-parts-and-funcall) but you maybe have come > accross a better solution. No, that's the correct solution, I think. Perhaps you should pass the intitial value of the `cont' parameter, IIRC it contains all the necessary information. > (A "feature" I see now: > To: a@b.c, e@b.c, q@p.c > #multipart type=encrypted recpients="a@b.c"> > Secret text to a. > #/multipart> Yes, that's the idea. Ideally, the user wouldn't write MML on his own, but invoke a command which displays a suitable subset of the public key ring, lets the user mark the keys he wants to use, and Emacs generates the appropriate MML directives. > > > There where possibilities to intercept my passphrase but the work > > > and luck that was needed was too great. You needed to be root to > > > begin with (which is a bit hard on a well administred system). > > > > In fact, this is not necessary, and that's the problem. :( > > Can you develop that? Let us presume a system where we can trust the > sysadmin to be competent. I'm sorry, the fix isn't ready yet, so I won't elaborate it in public.