gpg-ring.el/gpg.el?

gpg-ring.el/gpg.el?

[Josh Huber]

A couple questions...

Is there a reason gpg.el isn't included in the main dist yet?  It may
be alpha, but does anyone actually have problems with it? [1]

Is gpg-ring supposed to be functional?  I skimmed over the code, and I
couldn't figure out how to get it to do anything.  Am I being dense?

Footnotes: 
[1]  Signing/encrypting multipart messages should be done
     automatically, IMHO.  I'll try and figure this out -- the problem
     is that if you send someone an encrypted mail with an attachment,
     C-c C-m c p just does one part, encrypting the text before the
     attachment, leaving the attachment in the clear.

-- 
Josh Huber

Re: gpg-ring.el/gpg.el?

[Simon Josefsson]

Josh Huber <huber@alum.wpi.edu> writes:

> Is there a reason gpg.el isn't included in the main dist yet?

FSF doesn't have papers for it.

> [1]  Signing/encrypting multipart messages should be done
>      automatically, IMHO.  I'll try and figure this out -- the problem
>      is that if you send someone an encrypted mail with an attachment,
>      C-c C-m c p just does one part, encrypting the text before the
>      attachment, leaving the attachment in the clear.

C-c C-m c p encrypts the current MIME part.  If you C-c C-m c p on a
multipart part, the entire multipart is encrypted.

Re: gpg-ring.el/gpg.el?

[Josh Huber]

Simon Josefsson <jas@extundo.com> writes:

> FSF doesn't have papers for it.

Bummer, is the author going to do it, or what?

> C-c C-m c p encrypts the current MIME part.  If you C-c C-m c p on a
> multipart part, the entire multipart is encrypted.

Yes, I realize this.  What I'm suggesting is that there should be a
key bound which inserts <$multipart ...> if there are other parts, or
just <$part ...> if there are not.  It would prevent accidental
unencrypted traffic...that's all.

I know, this is a small piece of lisp :)

-- 
Josh Huber

Re: gpg-ring.el/gpg.el?

[Simon Josefsson]

Josh Huber <huber@alum.wpi.edu> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> FSF doesn't have papers for it.
>
> Bummer, is the author going to do it, or what?

I think lawyers are involved.

>> C-c C-m c p encrypts the current MIME part.  If you C-c C-m c p on a
>> multipart part, the entire multipart is encrypted.
>
> Yes, I realize this.  What I'm suggesting is that there should be a
> key bound which inserts <$multipart ...> if there are other parts, or
> just <$part ...> if there are not.  It would prevent accidental
> unencrypted traffic...that's all.
>
> I know, this is a small piece of lisp :)

The default commands should probably do what you suggest, instead of
the current less intuitive thing.

Re: gpg-ring.el/gpg.el?

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> Josh Huber <huber@alum.wpi.edu> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> FSF doesn't have papers for it.
>>
>> Bummer, is the author going to do it, or what?
>
> I think lawyers are involved.

I don't know, the FSF never told the copyright holder what they were
doing internally.  There are some rumors.  Currently, we (University
of Stuttgart) hope to assign copyright (well, the non-exclusive
usufruct of a copyright) to FSF Europe, German branch, but before this
can happen, FSF U.S. and FSF Europe have to agree on the modus
operandi.

If you want to have gpg.el in the GNU Emacs or GNU Privacy Guard
distribution, and you are familiar with the internal structure of the
FSF U.S., you might want to ask the right person there to continue
negotiations.  After proposing a draft contract and convincing RMS
that German copyright law is substantially different from U.S. law,
the negotiations stopped, and we have never heard anything back from
the FSF U.S.

(As an additional benefit, I'm able to work again on gpg.el and
gpg-ring.el, a security audit of the Gnus RFC 3156 support is planned,
you'll get a few security fixes for GNU Emacs on HP-UX and AIX, and
perhaps a few GnuPG changes, although the latter are probably OBE
now.)

Re: gpg-ring.el/gpg.el?

[Simon Josefsson]

Florian Weimer <fw@deneb.enyo.de> writes:

> I don't know, the FSF never told the copyright holder what they were
> doing internally.  There are some rumors.  Currently, we (University
> of Stuttgart) hope to assign copyright (well, the non-exclusive
> usufruct of a copyright) to FSF Europe, German branch, but before this
> can happen, FSF U.S. and FSF Europe have to agree on the modus
> operandi.
>
> If you want to have gpg.el in the GNU Emacs or GNU Privacy Guard
> distribution, and you are familiar with the internal structure of the
> FSF U.S., you might want to ask the right person there to continue
> negotiations.  After proposing a draft contract and convincing RMS
> that German copyright law is substantially different from U.S. law,
> the negotiations stopped, and we have never heard anything back from
> the FSF U.S.

:-(   I hope things will work out.

> (As an additional benefit, I'm able to work again on gpg.el and
> gpg-ring.el, a security audit of the Gnus RFC 3156 support is planned,
> you'll get a few security fixes for GNU Emacs on HP-UX and AIX, and
> perhaps a few GnuPG changes, although the latter are probably OBE
> now.)

Cool.

Re: gpg-ring.el/gpg.el?

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

>> (As an additional benefit, I'm able to work again on gpg.el and
>> gpg-ring.el, a security audit of the Gnus RFC 3156 support is planned,
>> you'll get a few security fixes for GNU Emacs on HP-UX and AIX, and
>> perhaps a few GnuPG changes, although the latter are probably OBE
>> now.)
>
> Cool.

I should have used subjunctive mood, so let me stress it: These things
will happen only if the copyright assignment is executed successfully.

Re: gpg-ring.el/gpg.el?

[Werner Koch]

On Sat, 17 Nov 2001 12:10:42 +0100, Florian Weimer said:

> negotiations.  After proposing a draft contract and convincing RMS
> that German copyright law is substantially different from U.S. law,
> the negotiations stopped, and we have never heard anything back from
> the FSF U.S.

Eben Moglen and our European lawyers are definitely working on it and
there is "just" some fine tuning left to do.  I am really after it to
get Florian's support for GnuPG ;-)

Ciao,

  Werner

Re: gpg-ring.el/gpg.el?

[Matt Armstrong]

Simon Josefsson <jas@extundo.com> writes:

> Josh Huber <huber@alum.wpi.edu> writes:
>
>> [1]  Signing/encrypting multipart messages should be done
>>      automatically, IMHO.  I'll try and figure this out -- the problem
>>      is that if you send someone an encrypted mail with an attachment,
>>      C-c C-m c p just does one part, encrypting the text before the
>>      attachment, leaving the attachment in the clear.
>
> C-c C-m c p encrypts the current MIME part.  If you C-c C-m c p on a
> multipart part, the entire multipart is encrypted.

I agree with Josh that it should be hard to encrypt anything but the
entire message.

If I do C-c RET c p, it puts some MML stuff way at the top of the
message.  Then I M-> and C-c C-a to attach a file, and some MML stuff
is stuck at the end.  I was quite surprised to find the attachment
sent in the clear.

-- 
matt

  Piki, you handsome cat, rest in peace  http://www.lickey.com/piki/

Re: gpg-ring.el/gpg.el?

[Josh Huber]

"Matt Armstrong" <matt+dated+1008538695.410e00@lickey.com> writes:

> If I do C-c RET c p, it puts some MML stuff way at the top of the
> message.  Then I M-> and C-c C-a to attach a file, and some MML
> stuff is stuck at the end.  I was quite surprised to find the
> attachment sent in the clear.

hmm, so just checking to see if there is another part to the message
won't do the trick.  I hadn't thought of that.  The problem is that
the message can be modified after C-c C-m c p, in which case it
wouldn't do the right thing. (even if it checked the message content
before choosing <$part ...> or <$multipart ...>)

I think we need some kind of flag to instruct MML to do the right
thing, at sending time.  Perhaps a new MML tag?

<$secure type=(sign|encrypt|encryptsign) mode=(pgp1991|pgp2015|smime)>

...
message body
...


Then, the right thing could be done at sending time (or whenever MML
is parsed)

what do you think?

-- 
Josh Huber

Re: gpg-ring.el/gpg.el?

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> I think we need some kind of flag to instruct MML to do the right
> thing, at sending time.  Perhaps a new MML tag?
>
> <$secure type=(sign|encrypt|encryptsign) mode=(pgp1991|pgp2015|smime)>

I like the idea of a meta-tag that has global effect for all mml tags
in the message (perhaps with the caveat that if the tag already has a
sign attribute, it is left alone).

It could be done during a pre-processing run -- if a $secure tag is
found anywhere in the message, delete it and set the "sign" attribute
on all mml tags in the message as appropriate, wrapping the message in
an explicit multipart/mixed tag first if appropriate.

-- 
matt

Re: gpg-ring.el/gpg.el?

[Josh Huber]

"Matt Armstrong" <matt+dated+1008789496.23e4db@lickey.com> writes:

> It could be done during a pre-processing run -- if a $secure tag is
> found anywhere in the message, delete it and set the "sign"
> attribute on all mml tags in the message as appropriate, wrapping
> the message in an explicit multipart/mixed tag first if appropriate.

Right, but I think you wouldn't need to do explicitly sign each part.
Personally, the behavior I'd be looking for would be the automatic
wrapping of the whole message with a multipart/mixed part, and then
signing that part.

I believe this is what mutt does...personally I think the
signing/encrypting in mutt is implemented pretty well, so following
what they do is a good thing.

ttyl,

-- 
Josh Huber

Re: gpg-ring.el/gpg.el?

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> "Matt Armstrong" <matt+dated+1008789496.23e4db@lickey.com> writes:
>
>> It could be done during a pre-processing run -- if a $secure tag is
>> <snip>
>
> Right, but I think you wouldn't need to do explicitly sign each
> part.  Personally, the behavior I'd be looking for would be the
> automatic wrapping of the whole message with a multipart/mixed part,
> and then signing that part.

Yes, I agree completely.  The current per-part signing and encryption
controls should still be available for the power users.  But most
folks think of signing and encryption as an attribute of the whole
message, so a global flag is a better default.

-- 
matt

Re: gpg-ring.el/gpg.el?

[Jack Twilley]

>>>>> "Josh" == Josh Huber <huber@alum.wpi.edu> writes:

Josh> I think we need some kind of flag to instruct MML to do the
Josh> right thing, at sending time.  Perhaps a new MML tag?

Josh> <$secure type=(sign|encrypt|encryptsign)
Josh> mode=(pgp1991|pgp2015|smime)>

Josh> ...  message body ...

Josh> Then, the right thing could be done at sending time (or whenever
Josh> MML is parsed)

Josh> what do you think?

What about adding in another key/value pair?

<$secure type=[] mode=[] key=[]>

Where type and mode are as above, and key is the key ID(s) for which
the message should be encrypted or signed.

Josh> -- Josh Huber

Jack.
-- 
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash

Re: gpg-ring.el/gpg.el?

[Josh Huber]

Jack Twilley <jmt+usenet@twilley.org> writes:

> What about adding in another key/value pair?
>
> <$secure type=[] mode=[] key=[]>
>
> Where type and mode are as above, and key is the key ID(s) for which
> the message should be encrypted or signed.

Personally, I don't think this is a good idea, since I'd rather look
for the recipients at message send time, not whenever the user chose
to add the secure tag.

My idea for the secure tag was it would be replaced with the
appropriate <$(multi)?part (sign=|encrypt=)> when the mml is
processed, and at that time the key could be chosen.

I don't use S/MIME, but it looks like there is support for specifying
the keys that you use?  Is that true?

ttyl,

-- 
Josh Huber