lisp/url/url-https.el

lisp/url/url-https.el

[Simon Josefsson]

The file lisp/url/url-https.el doesn't do anything useful, it seems,
if ssl.el isn't installed (or if OpenSSL isn't installed).  Does
anyone here know how to test HTTPS using the URL package?  If so,
please tell, and perhaps I can help make URL use lisp/net/tls.el
instead of ssl.el.  Ideally it should be as simple as replacing
(require 'ssl) with (require 'tls) and replacing open-ssl-stream with
open-tls-stream, but I don't know how to test those changes.

Generally, I think it would be nice if we got users to change to
tls.el (which is included in Emacs) and GNUTLS instead of ssl.el
(which isn't included) and OpenSSL.  ssl.el is still a common source
of frustration.

Re: lisp/url/url-https.el

[Richard Stallman]

    The file lisp/url/url-https.el doesn't do anything useful, it seems,
    if ssl.el isn't installed (or if OpenSSL isn't installed).

We have to delete that file, I think, since it is crypto code.
(It should not have been on savannah at all.)
tls.el has to be deleted too, I'm sad to say.

There are files in Gnus that also have to go.

Exporting crypto code from the US is no longer forbidden,
but the US government claims to impose restrictions on people
who obtain copies overseas and then redistribute them to certain
places.  For this reason, all GNU crypto code should be developed
and released from outside the US, still.

Re: lisp/url/url-https.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The file lisp/url/url-https.el doesn't do anything useful, it
>     seems, if ssl.el isn't installed (or if OpenSSL isn't
>     installed).
> 
> We have to delete that file, I think, since it is crypto code.

I would not call it "crypto code" since it does not do encryption.
Not as far as I can see.  It is just an interface to such code.  As
long as the code itself is not distributed with Emacs, I don't think
that Emacs should be affected legally.

> (It should not have been on savannah at all.)  tls.el has to be
> deleted too, I'm sad to say.
> 
> There are files in Gnus that also have to go.
> 
> Exporting crypto code from the US is no longer forbidden, but the US
> government claims to impose restrictions on people who obtain copies
> overseas and then redistribute them to certain places.  For this
> reason, all GNU crypto code should be developed and released from
> outside the US, still.

But the code in question does not do encryption, I think.  Are you
really sure that it would fall under such terms?  Perhaps one should
check with a lawyer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: lisp/url/url-https.el

[Richard Stallman]

    I would not call it "crypto code" since it does not do encryption.
    Not as far as I can see.  It is just an interface to such code.

According to export control rules, code specifically designed to call
encryption routines is treated just like code that does encryption.

Re: lisp/url/url-https.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I would not call it "crypto code" since it does not do encryption.
>     Not as far as I can see.  It is just an interface to such code.
> 
> According to export control rules, code specifically designed to
> call encryption routines is treated just like code that does
> encryption.

I sometimes find it appalling just how much the U.S. sometimes fries
freedom.

Sigh.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: lisp/url/url-https.el

[Miles Bader]

On Sat, Apr 10, 2004 at 01:03:19AM +0200, David Kastrup wrote:
> I sometimes find it appalling just how much the U.S. sometimes fries
> freedom.
> 
> Sigh.

Yes.  I'm honestly very proud to be an American, but there always seem to be
some people trying realllly hard to change that...

Get your freedom fries here.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: lisp/url/url-https.el

[Stefan Monnier]

>     I would not call it "crypto code" since it does not do encryption.
>     Not as far as I can see.  It is just an interface to such code.
> According to export control rules, code specifically designed to call
> encryption routines is treated just like code that does encryption.

Are url-https.el and ssl.el really specifically designed to call
encryption routines?  I thought they only run some external communication
program which happens to use encryption.  Much like Tramp.  There's a fair
amount of code between ssh.el or url-https.el and the actual
encryption routines AFAIK.


        Stefan

Re: lisp/url/url-https.el

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >     I would not call it "crypto code" since it does not do encryption.
> >     Not as far as I can see.  It is just an interface to such code.
> > According to export control rules, code specifically designed to call
> > encryption routines is treated just like code that does encryption.
> 
> Are url-https.el and ssl.el really specifically designed to call
> encryption routines?  I thought they only run some external communication
> program which happens to use encryption.  Much like Tramp.  There's a fair
> amount of code between ssh.el or url-https.el and the actual
> encryption routines AFAIK.


If you set ESHELL=ssh, you can use M-x shell (and comint) run a
crypto-enabled application?

So do we also have to remove shell.el and comint.el ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: lisp/url/url-https.el

[Richard Stallman]

    Yes.  I'm honestly very proud to be an American, but there always seem to be
    some people trying realllly hard to change that...

I try to uphold the ideals that I was taught to value as an American,
but every year I get less and less help from the United States.

Re: lisp/url/url-https.el

[Richard Stallman]

    Are url-https.el and ssl.el really specifically designed to call
    encryption routines?  I thought they only run some external communication
    program which happens to use encryption.

I am not sure whether this makes a difference.  I had better get legal
advice about this.  Could someone describe for me the overall
structure of the situation, so I can ask about it?

      Much like Tramp.

I don't know this case and the Tramp case are similar in the way
that matters legally.

Re: lisp/url/url-https.el

[Richard Stallman]

    If you set ESHELL=ssh, you can use M-x shell (and comint) run a
    crypto-enabled application?

    So do we also have to remove shell.el and comint.el ?

Proposing absurd extremes is a distraction.
It could be fun.  Unfortunately I don't have time to
indulge that pleasure.

Re: lisp/url/url-https.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Are url-https.el and ssl.el really specifically designed to call
>     encryption routines?  I thought they only run some external communication
>     program which happens to use encryption.
> 
> I am not sure whether this makes a difference.  I had better get legal
> advice about this.  Could someone describe for me the overall
> structure of the situation, so I can ask about it?
> 
>       Much like Tramp.
> 
> I don't know this case and the Tramp case are similar in the way
> that matters legally.

tramp can call ssh, but ssh can also connect using plain unencrypted
rsh.  So it would depend on the configuration of ssh whether a
connection is encrypted or not.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: lisp/url/url-https.el

[Stefan Monnier]

>> Are url-https.el and ssl.el really specifically designed to call
>> encryption routines?  I thought they only run some external communication
>> program which happens to use encryption.
>> 
>> I am not sure whether this makes a difference.  I had better get legal
>> advice about this.  Could someone describe for me the overall
>> structure of the situation, so I can ask about it?
>> 
>> Much like Tramp.
>> 
>> I don't know this case and the Tramp case are similar in the way
>> that matters legally.

> tramp can call ssh, but ssh can also connect using plain unencrypted
> rsh.  So it would depend on the configuration of ssh whether a
> connection is encrypted or not.

Every case is unique, of course, but AFAIK, Tramp weas mostly written to
use SSH rather than FTP because SSH is secure thanks to authentication
and encryption.  Yes, you can use it with rsh, with su, etc, which do not
use encryption, but RMS's poiint was that ssl.el was written specifically
for encryption and I thought Tramp was pretty close in that respect.

The way I see it ssl.el does not fall under the law because its purpose has
nothing to do with encryption.  It is just designed to connect to some hosts
using some particular protocol (not because this protocol is encrypted but
because some hosts require this protocol for some of their operations) by
running some external program which does all the socket-setup, protocol
negotiation, etc... the encryption is actually pretty minor in this respect.


        Stefan

Re: lisp/url/url-https.el

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     Are url-https.el and ssl.el really specifically designed to call
>     encryption routines?  I thought they only run some external communication
>     program which happens to use encryption.
>
> I am not sure whether this makes a difference.  I had better get legal
> advice about this.  Could someone describe for me the overall
> structure of the situation, so I can ask about it?

The general idea is that URL (and other elisp packages, such as Gnus,
W3 and maybe others) need SSL/TLS functionality in order to connect to
HTTP or IMAP servers (for browing the web, or reading mail) that uses
SSL/TLS.  OpenSSL or GNUTLS provides that, via a command line
interface (I wrote patches to make an elisp API for them, via the
shared libraries, but they were never adopted).  Since having each and
every elisp application write its own OpenSSL/GNUTLS handling, ssl.el
was presumably written, mimicking the open-network-stream API, only
that it open the stream over a SSL/TLS connection via the command line
application.  The point of SSL/TLS is to provide authentication,
integrity and/or encryption (all optional, and can be configured in
very high detail, although this configuration is probably not possible
via a command line application, but would have been one of the
features of my direct elisp API to the libraries).  The default
behaviour of both OpenSSL and GNUTLS is to negotiate the most secure,
mutually implemented, algorithms, though.

I wrote tls.el that uses GNUTLS, instead of OpenSSL which ssl.el uses.
Gnus and smtpmail.el uses tls.el, and if possible I think url-https.el
should as well.  I'm not sure we need ssl.el in Emacs, it might be
better to make users use GNUTLS instead of OpenSSL.

Re: lisp/url/url-https.el

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Every case is unique, of course, but AFAIK, Tramp weas mostly
> written to use SSH rather than FTP because SSH is secure thanks to
> authentication and encryption.  Yes, you can use it with rsh, with
> su, etc, which do not use encryption, but RMS's poiint was that
> ssl.el was written specifically for encryption and I thought Tramp
> was pretty close in that respect.

I use tramp actually most often with the su protocol, not ssh.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: lisp/url/url-https.el

[Mario Lang]

Richard Stallman <rms@gnu.org> writes:

>     If you set ESHELL=ssh, you can use M-x shell (and comint) run a
>     crypto-enabled application?
>
>     So do we also have to remove shell.el and comint.el ?
>
> Proposing absurd extremes is a distraction.
> It could be fun.  Unfortunately I don't have time to
> indulge that pleasure.

I don't see the absurdity of the OP's message.  After all, ssh
is indeed a program for performing encryption (among other things), and
Emacs does support its use through externally invoking the binary.

The same thing applies to gnutls/openssl.  I think if we are already
discussiong legal implications, we should think about this
case too.

I think Kim was actually trying to emphasis the absurdity
of removing ssl support code from Emacs in the first place, since that
does not do any encryption at all, directly.
The same thing applies to Tramp and comint.el.  They allow for
external programs to be used to encrypt network traffic, but they
do not do any encryption at all by themselves.

-- 
CYa,
  Mario | Debian Developer <URL:http://debian.org/>
        | Get my public key via finger mlang@db.debian.org
        | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

Re: lisp/url/url-https.el

[Richard Stallman]

I asked our lawyers about this situation.

Re: lisp/url/url-https.el

[Richard Stallman]

    I think Kim was actually trying to emphasis the absurdity
    of removing ssl support code from Emacs in the first place, 

I agree that these restrictions are absurd.  However, that is
not relevant to the issue of what we need to remove from
distribution in the US.

Re: lisp/url/url-https.el

[Ted Zlatanov]

On Wed, 14 Apr 2004, rms@gnu.org wrote:

>     I think Kim was actually trying to emphasis the absurdity
>     of removing ssl support code from Emacs in the first place, 
> 
> I agree that these restrictions are absurd.  However, that is
> not relevant to the issue of what we need to remove from
> distribution in the US.

Richard,

I need to mention that my own attempts at writing encryption support
for Gnus, which is to be included with Emacs, were frustrated by these
restrictions.  Specifically in the case of Gnus, the file ~/.authinfo
(AKA ~/.netrc) can hold user passwords, and encrypting it is very
desirable.  The restrictions have delayed production-ready encryption
code I've already written that wraps around GPG, and I am confused as
to how much of the code I have to throw out.

I am willing to work with any standards Emacs has, but there has to be
some way to allow a willing user to plug in encryption code easily
into Gnus, once that code is downloaded.  As it is, and according to
what you have told Lars Magne Ingebrigtsen and he has relayed to the
Gnus developers, not even empty wrapper functions that could be used
for encryption are allowed.  That makes my life much harder.

The alternate way is to develop two branches of Gnus, one for
inclusion with Emacs and one for regular use.  That can be very
counterproductive.

Can you suggest any way out of this situation?  Have I misunderstood
anything?

Thanks
Ted

Re: lisp/url/url-https.el

[Stefan Monnier]

> I am willing to work with any standards Emacs has, but there has to be
> some way to allow a willing user to plug in encryption code easily
> into Gnus, once that code is downloaded.  As it is, and according to
> what you have told Lars Magne Ingebrigtsen and he has relayed to the
> Gnus developers, not even empty wrapper functions that could be used
> for encryption are allowed.  That makes my life much harder.

My understanding is that the problems only show up for code that's meant
specifically for encryption.
So you should be able to provide hooks as long as they are not specifically
for encryption.

I know nothing about your specific problem so I'm probably talking
non-sense, but why should .authinfo and Gnus be so special?

Can't we write a generic "auto-decrypt-mode" which works similarly to
auto-compress-mode (or maybe even a patch to auto-compress-mode which
allows "compression using gpg") ?
This package wouldn't be distributable with Emacs but it doesn't have
anything specific to do with Gnus and can distributed separately
(e.g. from a non-US location).

Or maybe we can even make the patch to jka-compr.el generic enough (allow
"(de)compression with a program that requires interactive user input")
to make it acceptable for inclusion in Emacs.

Wait isn't something like that already available?

And then somehow make sure Gnus can be customized to use .authinfo.gz (or
.authinfo.gpg).


        Stefan

Re: lisp/url/url-https.el

[Simon Josefsson]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I am willing to work with any standards Emacs has, but there has to be
>> some way to allow a willing user to plug in encryption code easily
>> into Gnus, once that code is downloaded.  As it is, and according to
>> what you have told Lars Magne Ingebrigtsen and he has relayed to the
>> Gnus developers, not even empty wrapper functions that could be used
>> for encryption are allowed.  That makes my life much harder.
>
> My understanding is that the problems only show up for code that's meant
> specifically for encryption.
> So you should be able to provide hooks as long as they are not specifically
> for encryption.
>
> I know nothing about your specific problem so I'm probably talking
> non-sense, but why should .authinfo and Gnus be so special?
>
> Can't we write a generic "auto-decrypt-mode" which works similarly to
> auto-compress-mode (or maybe even a patch to auto-compress-mode which
> allows "compression using gpg") ?
> This package wouldn't be distributable with Emacs but it doesn't have
> anything specific to do with Gnus and can distributed separately
> (e.g. from a non-US location).
>
> Or maybe we can even make the patch to jka-compr.el generic enough (allow
> "(de)compression with a program that requires interactive user input")
> to make it acceptable for inclusion in Emacs.
>
> Wait isn't something like that already available?

There is crypt++, but when it was discussed in the context of Gnus, I
think it was decided it was not really good enough, the programmatic
elisp API insufficient, and that we could never get copyright papers
for it anyway.  I believe it was suggested to make a generic package
for this.  This same problem does indeed occur in many situations.  I
thought, but perhaps I have just been secretly wishing it, that Ted
was working on something like that.

Re: lisp/url/url-https.el

[Stefan Monnier]

> There is crypt++, but when it was discussed in the context of Gnus, I
> think it was decided it was not really good enough, the programmatic
> elisp API insufficient, and that we could never get copyright papers
> for it anyway.  I believe it was suggested to make a generic package
> for this.  This same problem does indeed occur in many situations.  I
> thought, but perhaps I have just been secretly wishing it, that Ted
> was working on something like that.

Maybe I didn't express myself clearly enough: I was talking about writing
a generic package (like crypt++) such that Gnus does not need to know about
encryption at all (i.e. the package uses generic hooks so Gnus does not need
to call it explicitly.  At most Gnus would just need a way to specify
a different file name than ~/.authinfo, which is probably already the case).


        Stefan

Re: lisp/url/url-https.el

[Ted Zlatanov]

On 15 Apr 2004, monnier@iro.umontreal.ca wrote:

>> There is crypt++, but when it was discussed in the context of Gnus,
>> I think it was decided it was not really good enough, the
>> programmatic elisp API insufficient, and that we could never get
>> copyright papers for it anyway.  I believe it was suggested to make
>> a generic package for this.  This same problem does indeed occur in
>> many situations.  I thought, but perhaps I have just been secretly
>> wishing it, that Ted was working on something like that.
> 
> Maybe I didn't express myself clearly enough: I was talking about
> writing a generic package (like crypt++) such that Gnus does not
> need to know about encryption at all (i.e. the package uses generic
> hooks so Gnus does not need to call it explicitly.  At most Gnus
> would just need a way to specify a different file name than
> ~/.authinfo, which is probably already the case).

My aim was to write such a package, based on crypt++ but without all
the bells and whistles (to be called gencrypt.el).  I was doing it
specifically for Gnus, because that's where I need the encryption, but
it was supposed to be general use.  I got started on it and get pretty
far before I found out (wrongly, it's apparent now) it wouldn't
integrate with Gnus due to the crypto restrictions.

I'll resume work on gnus-encrypt.el, which will contain empty hooks
for encryption, and gencrypt.el, which will use those hooks.

Thanks
Ted

Re: lisp/url/url-https.el

[Ted Zlatanov]

On 14 Apr 2004, monnier@iro.umontreal.ca wrote:

> My understanding is that the problems only show up for code that's
> meant specifically for encryption.  So you should be able to provide
> hooks as long as they are not specifically for encryption.

So is gnus-encrypt.el, which will contain empty hooks that the
rest of Gnus uses, a problem?  Or do I have to call it
gnus-file-handlers.el to pretend it's not what it is?

> I know nothing about your specific problem so I'm probably talking
> non-sense, but why should .authinfo and Gnus be so special?
> 
> Can't we write a generic "auto-decrypt-mode" which works similarly
> to auto-compress-mode (or maybe even a patch to auto-compress-mode
> which allows "compression using gpg") ?  This package wouldn't be
> distributable with Emacs but it doesn't have anything specific to do
> with Gnus and can distributed separately (e.g. from a non-US
> location).

crypt++.el does that.  I find it intrusive, not to mention that it
doesn't play nice with many packages (noted as bugs in the comments of
crypt++.el).  I discussed with Karl Berry, who maintains crypt++.el,
and my decision was to write a new package (gencrypt.el) which would
provide what crypt++.el provides, but as functions to be used by other
packages, rather than as a transparent layer on top of all Emacs file
I/O.  I feel that, because of the complexity and variety of
encryption programs and ciphers, a file encryption API is better than
the crypt++.el approach.

> Or maybe we can even make the patch to jka-compr.el generic enough
> (allow "(de)compression with a program that requires interactive
> user input") to make it acceptable for inclusion in Emacs.

Encryption, unfortunately, is not easy to implement correctly.  This
sort of shell pipe could present security risks, for instance, if
done without care.  gencrypt.el will do it properly.

gencrypt.el aims to provide a few pure-Lisp ciphers, as well.  That
would make it useful for those who don't install external encryption
software.

> And then somehow make sure Gnus can be customized to use
> .authinfo.gz (or .authinfo.gpg).

That's the easy part :)

Ted

Re: lisp/url/url-https.el

[Simon Josefsson]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There is crypt++, but when it was discussed in the context of Gnus, I
>> think it was decided it was not really good enough, the programmatic
>> elisp API insufficient, and that we could never get copyright papers
>> for it anyway.  I believe it was suggested to make a generic package
>> for this.  This same problem does indeed occur in many situations.  I
>> thought, but perhaps I have just been secretly wishing it, that Ted
>> was working on something like that.
>
> Maybe I didn't express myself clearly enough: I was talking about writing
> a generic package (like crypt++) such that Gnus does not need to know about
> encryption at all (i.e. the package uses generic hooks so Gnus does not need
> to call it explicitly.  At most Gnus would just need a way to specify
> a different file name than ~/.authinfo, which is probably already the case).

That's exactly what I had in mind.  Such a package would be useful,
and looks rather simple to implement (if one can assume e.g. GnuPG).

Re: lisp/url/url-https.el

[Richard Stallman]

It is best for encryption software to be written and released
outside the US, by people who are not US citizens.  This is the only
way to avoid the post-release restrictions that the US still tries
to apply to people in other countries who might subsequently
redistribute it.

Re: lisp/url/url-https.el

[Richard Stallman]

    So is gnus-encrypt.el, which will contain empty hooks that the
    rest of Gnus uses, a problem?

It would be pretty stupid to have such a file name.
We would need to have a bona-fide hook for bona-fide
general purposes and do it in a bona-fide way.

Re: lisp/url/url-https.el

[Ted Zlatanov]

On Fri, 16 Apr 2004, rms@gnu.org wrote:
>     So is gnus-encrypt.el, which will contain empty hooks that the
>     rest of Gnus uses, a problem?
> 
> It would be pretty stupid to have such a file name.
> We would need to have a bona-fide hook for bona-fide
> general purposes and do it in a bona-fide way.

I understand.  I'll use gnus-file-handlers.el.

Thanks
Ted

Re: lisp/url/url-https.el

[Ted Zlatanov]

On Fri, 16 Apr 2004, rms@gnu.org wrote:
> It is best for encryption software to be written and released
> outside the US, by people who are not US citizens.  This is the only
> way to avoid the post-release restrictions that the US still tries
> to apply to people in other countries who might subsequently
> redistribute it.

If there is a non-US resident interested in developing gencrypt.el or
something similar, I'm perfectly willing to let them do it.  I don't
think Karl Berry, the crypt++.el maintained, would mind it either.

crypt++.el and my own work with Gnus are decent starting points - the
only thing I ask is that the developer try to develop an API, not a
file I/O layer like crypt++.el, even though the file I/O layer can be
optional.

Thanks
Ted

Re: lisp/url/url-https.el

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On 14 Apr 2004, monnier@iro.umontreal.ca wrote:
>
>> Can't we write a generic "auto-decrypt-mode" which works similarly
>> to auto-compress-mode (or maybe even a patch to auto-compress-mode
>> which allows "compression using gpg") ?  This package wouldn't be
>> distributable with Emacs but it doesn't have anything specific to do
>> with Gnus and can distributed separately (e.g. from a non-US
>> location).
>
> crypt++.el does that.  I find it intrusive, not to mention that it
> doesn't play nice with many packages (noted as bugs in the comments of
> crypt++.el).

Maybe it works to write a file handler?  Ange-FTP and Tramp show that
file handlers which require user input (someone else mentioned this as
a potential issue in this thread) are no problem, and I don't believe
that you'll see coding system trouble if you do it that way.

Kai

Re: lisp/url/url-https.el

[Stefan Monnier]

>> Can't we write a generic "auto-decrypt-mode" which works similarly
>> to auto-compress-mode (or maybe even a patch to auto-compress-mode
>> which allows "compression using gpg") ?  This package wouldn't be
>> distributable with Emacs but it doesn't have anything specific to do
>> with Gnus and can distributed separately (e.g. from a non-US
>> location).

> crypt++.el does that.

No, it doesn't.  auto-compress-mode uses file-name-handler-alist, whereas
crypt++ uses things like find-file-hooks.

> I find it intrusive, not to mention that it doesn't play nice with many
> packages (noted as bugs in the comments of crypt++.el).

Using file-name-handler-alist would make it much less intrusive and much
more reliable (but would require crypted files to have an easily
recognizable name).

> I feel that, because of the complexity and variety of encryption programs
> and ciphers, a file encryption API is better than the crypt++.el approach.

I agree that the implementation technique used by crypt++ is inappropriate
(seems to be inherited from way back, probably a time when
file-name-handlers-alist wasn't available).

But could you explain what a file encryption API would provide that can't
be obtained directly from file-name-handlers?

>> Or maybe we can even make the patch to jka-compr.el generic enough
>> (allow "(de)compression with a program that requires interactive
>> user input") to make it acceptable for inclusion in Emacs.

> Encryption, unfortunately, is not easy to implement correctly.  This
> sort of shell pipe could present security risks, for instance, if
> done without care.  gencrypt.el will do it properly.

I don't understand why jka-compr would be restricted to "a shell pipe" in
a way that gencrypt.el wouldn't.  Could you explain with some
concrete examples?

Admittedly, I'm of the people would don't believe in overwriting files and
data (e.g. I don't see the point of the new clear-string function), so maybe
I disagree more than I fail to understand.

>> And then somehow make sure Gnus can be customized to use
>> .authinfo.gz (or .authinfo.gpg).

> That's the easy part :)

And the only hook needed to get file-name-handlers in the game.


        Stefan

Re: lisp/url/url-https.el

[Ted Zlatanov]

On Fri, 16 Apr 2004, kai@emptydomain.de wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> crypt++.el does that.  I find it intrusive, not to mention that it
>> doesn't play nice with many packages (noted as bugs in the comments
>> of crypt++.el).
> 
> Maybe it works to write a file handler?  Ange-FTP and Tramp show
> that file handlers which require user input (someone else mentioned
> this as a potential issue in this thread) are no problem, and I
> don't believe that you'll see coding system trouble if you do it
> that way.

How hard would it be to integrate the support with Tramp?  Does Tramp
have any facility to add more handlers without modifying its source?
Since it comes with Emacs, I'd rather plug into Tramp.

Ted

Re: lisp/url/url-https.el

[Ted Zlatanov]

On 16 Apr 2004, monnier@iro.umontreal.ca wrote:

>>> Can't we write a generic "auto-decrypt-mode" which works similarly
>>> to auto-compress-mode (or maybe even a patch to auto-compress-mode
>>> which allows "compression using gpg") ?  This package wouldn't be
>>> distributable with Emacs but it doesn't have anything specific to
>>> do with Gnus and can distributed separately (e.g. from a non-US
>>> location).
> 
>> crypt++.el does that.
> 
> No, it doesn't.  auto-compress-mode uses file-name-handler-alist,
> whereas crypt++ uses things like find-file-hooks.

Sorry, I didn't know.

>> I find it intrusive, not to mention that it doesn't play nice with
>> many packages (noted as bugs in the comments of crypt++.el).
> 
> Using file-name-handler-alist would make it much less intrusive and
> much more reliable (but would require crypted files to have an
> easily recognizable name).

I think piggybacking on top of Tramp would be best, since it does so
much of the work already.

>> I feel that, because of the complexity and variety of encryption
>> programs and ciphers, a file encryption API is better than the
>> crypt++.el approach.
> 
> I agree that the implementation technique used by crypt++ is
> inappropriate (seems to be inherited from way back, probably a time
> when file-name-handlers-alist wasn't available).
> 
> But could you explain what a file encryption API would provide that
> can't be obtained directly from file-name-handlers?

Well, a file encryption API can always provide the file handlers.  The
file handlers can't provide the API as easily.  An API lets a
programmer control every aspect of our operation; file handlers are a
semi-automatic layer that's just not as useful to developers.

Ted

Re: lisp/url/url-https.el

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 16 Apr 2004 15:15:22 -0400
> 
> I'll use gnus-file-handlers.el.

May I suggest something shorter?  gnus-file-handlers.el exceeds the
14-character limits present on some old Unix systems, which I think
Emacs still tries to avoid.

Re: lisp/url/url-https.el

[Stefan Monnier]

> How hard would it be to integrate the support with Tramp?  Does Tramp
> have any facility to add more handlers without modifying its source?
> Since it comes with Emacs, I'd rather plug into Tramp.

Please check out the Emacs Lisp Manual to see how file-name-handlers work.
If you then look at the Tramp source, you'll quickly see that using Tramp
in place of using file-name-handlers-alist directly is being masochistic.


        Stefan

Re: lisp/url/url-https.el

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think piggybacking on top of Tramp would be best, since it does so
> much of the work already.

As always, there are two sides of the coin.

The negative side:

Tramp doesn't really do much of what you might need.  The bulk of it
is concerned with sending shell commands to a remote host.  But the
file encryption thingy wouldn't send shell commands to a remote host,
presumably ;-)

One thing that you _might_ be able to leverage is the filename parsing
functions.  But is that really worth it?

The positive side:

Unified filename syntax might be useful.  So GPG'd files could be
called /gpg:/some/file.  Users might like this regular filename
syntax.

Tramp provides an interface to foreign handlers, which makes
integration of a handler almost the same work as putting an entry in
file-name-handler-alist.  In file-name-handler-alist you put a regexp
and a handler function, but in tramp-foreign-file-name-handler-alist
you put a predicate and a handler function.  Writing a predicate that
does regexp matching on the filename is a two-liner.

In tramp-ftp.el you can see what is required to use the Tramp foreign
handler interface to integrate Ange-FTP.  This is a worst-case
scenario IMHO since Ange-FTP was not written with Tramp in mind at
all.  For your handler, you should be able to do MUCH better.

Much kudos to Michael for designing the foreign handler interface.

Kai

Re: lisp/url/url-https.el

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Please check out the Emacs Lisp Manual to see how file-name-handlers work.
> If you then look at the Tramp source, you'll quickly see that using Tramp
> in place of using file-name-handlers-alist directly is being masochistic.

It's not /that/ bad.  See variable tramp-foreign-file-name-handler-alist.
Of course, plugging into Tramp is not necessary, just an option.

But I think tramp-foreign-file-name-handler-alist is not the best
option in this case, directly using file-name-handler-alist is better.

Kai

Re: lisp/url/url-https.el

[Kai Grossjohann]

Kai Grossjohann <kai@emptydomain.de> writes:

> Unified filename syntax might be useful.  So GPG'd files could be
> called /gpg:/some/file.  Users might like this regular filename
> syntax.

The previous message implies that unified filename syntax is only
possible through tramp-foreign-file-name-handler-alist.  This is of
course bogus.  I apologize for this misinformation.

Just add an entry for "\\`/gpg:" to file-name-handler-alist and Bob's
your uncle.

Kai

Re: lisp/url/url-https.el

[Richard Stallman]

    How hard would it be to integrate the support with Tramp?  Does Tramp
    have any facility to add more handlers without modifying its source?
    Since it comes with Emacs, I'd rather plug into Tramp.

It is much better to use a documented interface such as the
file handler interface.

Re: lisp/url/url-https.el

[Stefan Monnier]

> So GPG'd files could be called /gpg:/some/file.

That's the masochistic part.
Using any other name than the real filename is being masochistic.
It means you have to implement file-attributes, file-exists-p, ....


        Stefan

Re: lisp/url/url-https.el

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So GPG'd files could be called /gpg:/some/file.
>
> That's the masochistic part.
> Using any other name than the real filename is being masochistic.
> It means you have to implement file-attributes, file-exists-p, ....

Write a single function that parses the filename.  Then it looks up
the operation in an alist.  If there is a special handler, then call
it, else invoke the "normal" handler on the real filename.

Sounds reasonable to me.  The only problem is to know which of the
args is the filename we're talking about, but Tramp has a function for
this.

Kai

Re: lisp/url/url-https.el

[Stefan Monnier]

>>> So GPG'd files could be called /gpg:/some/file.
>> That's the masochistic part.
>> Using any other name than the real filename is being masochistic.
>> It means you have to implement file-attributes, file-exists-p, ....

> Write a single function that parses the filename.  Then it looks up
> the operation in an alist.  If there is a special handler, then call
> it, else invoke the "normal" handler on the real filename.

Sure, so you need to list all the possible file operations, joy!

> Sounds reasonable to me.  The only problem is to know which of the
> args is the filename we're talking about, but Tramp has a function for
> this.

Right: using normal filenames (like jka-compr does) saves you from all
this trouble.  Is that masochism or not?


        Stefan

Re: lisp/url/url-https.el

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> So GPG'd files could be called /gpg:/some/file.
>>> That's the masochistic part.
>>> Using any other name than the real filename is being masochistic.
>>> It means you have to implement file-attributes, file-exists-p, ....
>
>> Write a single function that parses the filename.  Then it looks up
>> the operation in an alist.  If there is a special handler, then call
>> it, else invoke the "normal" handler on the real filename.
>
> Sure, so you need to list all the possible file operations, joy!

No, only the ones that aren't forwarded.  And since you have to write
a function for the handled (not forwareded) ones anyway, listing them
once again in an alist is not too much trouble, methinks.

>> Sounds reasonable to me.  The only problem is to know which of the
>> args is the filename we're talking about, but Tramp has a function for
>> this.
>
> Right: using normal filenames (like jka-compr does) saves you from all
> this trouble.  Is that masochism or not?

I don't want to say that /gpg:foo is the best convention there is, but
one advantage of having the explicit "GPG" indicator is that the
filename is arbitrary.

Or is it true for all encryption mechanisms that the filename
indicates which one was used?  In that case, of course, my point is
moot.

Kai

Re: lisp/url/url-https.el

[Stefan Monnier]

>>>>> So GPG'd files could be called /gpg:/some/file.
>>>> That's the masochistic part.
>>>> Using any other name than the real filename is being masochistic.
>>>> It means you have to implement file-attributes, file-exists-p, ....
>> 
>>> Write a single function that parses the filename.  Then it looks up
>>> the operation in an alist.  If there is a special handler, then call
>>> it, else invoke the "normal" handler on the real filename.
>> 
>> Sure, so you need to list all the possible file operations, joy!

> No, only the ones that aren't forwarded.  And since you have to write
> a function for the handled (not forwareded) ones anyway, listing them
> once again in an alist is not too much trouble, methinks.

It seems to me that for each and every possible file-op, you need to figure
out which is the FILE argument so you can rewrite it, so you need to list
them all somehow.
If you look at jka-compr, you'll see that most file operations aren't ever
mentioned in any way in the code because the file names it uses are valid
real file names.



        Stefan

Re: lisp/url/url-https.el

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It seems to me that for each and every possible file-op, you need to figure
> out which is the FILE argument so you can rewrite it, so you need to list
> them all somehow.

Whoops.  I thought that the Tramp function didn't need to do that, but
in fact, tramp-file-name-for-operation does list all operations.

Sorry.

Kai

Checkout a branch in cvs-tree

[Masatake YAMATO]

Hi,

I wrote a patch to check out a branch under the point in cvs-tree
buffer by hitting `>' to track the current emacs development:-P I
found this function is useful. However patch is not clean enough. So
I'd like to get your advice.

The question is how to set the cvs root for `cvs-checkout'
command. I'm using CVSROOT environment variable. It may 
be wrong way.

Regards,
Masatake YAMATO

Index: lisp/cvs-status.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cvs-status.el,v
retrieving revision 1.16
diff -u -r1.16 cvs-status.el
--- lisp/cvs-status.el	26 Mar 2004 15:20:20 -0000	1.16
+++ lisp/cvs-status.el	20 Apr 2004 08:06:43 -0000
@@ -442,6 +442,22 @@
 	    ;;(sit-for 0)
 	    ))))))
 
+(easy-mmode-defmap cvs-status-tag-map
+  `((">" . cvs-tree-checkout))
+  "The keymap only used on a tag of cvs tree.")
+
+(defun cvs-tree-checkout (dir)
+  (interactive "DDirectory: ")
+  (let ((modules (list (cvs-get-module)))
+	(flags (cons "-r" (cons (get-text-property (point) 'tag-name)
+				(cvs-flags-query 'cvs-checkout-flags))))
+	(env (getenv "CVSROOT")))
+    (unwind-protect
+	(progn
+	  (setenv "CVSROOT" (cvs-get-cvsroot))
+	  (cvs-checkout modules dir flags))
+      (setenv "CVSROOT" env))))
+
 (defun cvs-tree-tags-insert (tags prev)
   (when tags
     (let* ((tag (car tags))
@@ -462,11 +478,20 @@
 	    (ps prev (cdr ps))
 	    (as after (cdr as)))
 	  ((and (null as) (null vs) (null ps))
-	   (let ((revname (cvs-status-vl-to-str vlist)))
+	   (let ((revname (cvs-status-vl-to-str vlist))
+		 (tname (cvs-tag->name tag)))
+	     (setq tname (if tname 
+			     (propertize tname 
+					 'help-echo (substitute-command-keys "\{cvs-status-tag-map}")
+					 'mouse-face 'highlight
+					 'keymap cvs-status-tag-map
+					 'tag-name tname
+					 )
+			   ""))
 	     (if (cvs-every 'identity (cvs-map 'equal prev vlist))
 		 (insert (make-string (+ 4 (length revname)) ? )
-			 (or (cvs-tag->name tag) ""))
-	       (insert "  " revname ": " (or (cvs-tag->name tag) "")))))
+			 tname)
+	       (insert "  " revname ": " tname))))
 	(let* ((eq (and pe (equal (car ps) (car vs))))
 	       (next-eq (equal (cadr ps) (cadr vs))))
 	  (let* ((na+char

Re: lisp/url/url-https.el

[Michael Albinus]

Kai Grossjohann <kai@emptydomain.de> writes:

> I don't want to say that /gpg:foo is the best convention there is, but
> one advantage of having the explicit "GPG" indicator is that the
> filename is arbitrary.

A disadvantage with this approach is that you cannot handle remote
files via Tramp. Or you need to extend multi-hop syntax by the gpg:
virtual method, which would lead into confusion I guess.

> Kai

Best regeads, Michael.

Re: lisp/url/url-https.el

[Kai Grossjohann]

Michael Albinus <Michael.Albinus@alcatel.de> writes:

> Kai Grossjohann <kai@emptydomain.de> writes:
>
>> I don't want to say that /gpg:foo is the best convention there is, but
>> one advantage of having the explicit "GPG" indicator is that the
>> filename is arbitrary.
>
> A disadvantage with this approach is that you cannot handle remote
> files via Tramp. Or you need to extend multi-hop syntax by the gpg:
> virtual method, which would lead into confusion I guess.

Tramp could exclude the foreign method only instead of excluding
itself, when invoking the real handler.

Kai

Re: lisp/url/url-https.el

[Ted Zlatanov]

On 17 Apr 2004, monnier@iro.umontreal.ca wrote:

>> How hard would it be to integrate the support with Tramp?  Does
>> Tramp have any facility to add more handlers without modifying its
>> source?  Since it comes with Emacs, I'd rather plug into Tramp.
> 
> Please check out the Emacs Lisp Manual to see how file-name-handlers
> work.  If you then look at the Tramp source, you'll quickly see that
> using Tramp in place of using file-name-handlers-alist directly is
> being masochistic.

My problem is that I don't want to use file-name-handlers at all - I
think that they are icing on the cake, but not essential to what I
need.  I want to provide an API that others can use to provide a file
I/O layer.  I was hoping that Tramp would make this easier, but it
apparently doesn't, so I'll do the file-name-handlers eventually.
Right now my priority is to get the API working.  I hope that's OK
with everyone.

Ted

Re: lisp/url/url-https.el

[Ted Zlatanov]

On Sat, 17 Apr 2004, eliz@gnu.org wrote:

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 16 Apr 2004 15:15:22 -0400
>> 
>> I'll use gnus-file-handlers.el.
> 
> May I suggest something shorter?  gnus-file-handlers.el exceeds the
> 14-character limits present on some old Unix systems, which I think
> Emacs still tries to avoid.

Sure.  I'll figure it out with the Gnus developers.  Thanks!

Ted

Re: Checkout a branch in cvs-tree

[Stefan Monnier]

> The question is how to set the cvs root for `cvs-checkout'
> command. I'm using CVSROOT environment variable.  It may be wrong way.

It's probably easier to let-bind `cvs-cvsroot'.

> +	(env (getenv "CVSROOT")))
> +    (unwind-protect
> +	(progn
> +	  (setenv "CVSROOT" (cvs-get-cvsroot))
> +	  (cvs-checkout modules dir flags))
> +      (setenv "CVSROOT" env))))

A better way then unwind-protect/getenv/setenv is probably:

   (let ((process-environment
          (cons (concat "CVSROOT=" (cvs-get-cvsroot)) process-environment)))

or else

   (let ((process-environment process-environment))
     (setenv "CVSROOT" (cvs-get-cvsroot))
     ...)

but as said

   (let ((cvs-cvsroot (cvs-get-cvsroot)))
     ...)

should work just as well.


        Stefan

Re: Checkout a branch in cvs-tree

[Masatake YAMATO]

> > The question is how to set the cvs root for `cvs-checkout'
> > command. I'm using CVSROOT environment variable.  It may be wrong way.
> 
> It's probably easier to let-bind `cvs-cvsroot'.

Thank you for your advice.
Base on the advice, I have rewritten the patch.

I explained the patch in the old mail:
    I wrote a patch to check out a branch under the point in cvs-tree
    buffer by hitting `>' to track the current emacs development:-P I
    found this function is useful. However patch is not clean enough. So
    I'd like to get your advice.

With the new patch, you can do the same on cvs-status buffer.

BTW, With gnuarch, finally I get what I wanted during writing 
the draft version of cvs-tree.el. I think you have interest:

    http://www.gyve.org/~jet/xtla/xtla-browse.png

Regards,
Masatake YAMATO

2004-08-21  Masatake YAMATO  <jet@gyve.org>

	* cvs-status.el (cvs-status-checkout): New function.
	(cvs-status-mode-map): Add a key definition for `cvs-status-checkout'.

Index: lisp/cvs-status.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/cvs-status.el,v
retrieving revision 1.18
diff -u -r1.18 cvs-status.el
--- lisp/cvs-status.el	28 May 2004 19:07:57 -0000	1.18
+++ lisp/cvs-status.el	21 Aug 2004 11:33:24 -0000
@@ -48,7 +48,8 @@
     ("\M-n"	. cvs-status-next)
     ("\M-p"	. cvs-status-prev)
     ("t"	. cvs-status-cvstrees)
-    ("T"	. cvs-status-trees))
+    ("T"	. cvs-status-trees)
+    (">"        . cvs-status-checkout))
   "CVS-Status' keymap."
   :group 'cvs-status
   :inherit 'cvs-mode-map)
@@ -464,6 +465,26 @@
 	    ;;(sit-for 0)
 	    ))))))
 
+(defun-cvs-mode (cvs-status-checkout . NOARGS) (dir)
+  "Run cvs-checkout against the tag under the point.
+The files are stored to DIR.
+With prefix argument, prompt for cvs flags."
+  (interactive 
+   (let* ((module (cvs-get-module))
+	  (branch (cvs-prefix-get 'cvs-branch-prefix))
+	  (prompt (format "CVS Checkout Directory for `%s%s': " 
+			 module
+			 (if branch (format "(branch: %s)" branch)
+			   ""))))
+     (list
+      (read-directory-name prompt
+			   nil default-directory nil))))
+  (let ((modules (cvs-string->strings (cvs-get-module)))
+	(flags (cvs-add-branch-prefix
+		(cvs-flags-query 'cvs-checkout-flags "cvs checkout flags")))
+	(cvs-cvsroot (cvs-get-cvsroot)))
+    (cvs-checkout modules dir flags)))
+
 (defun cvs-tree-tags-insert (tags prev)
   (when tags
     (let* ((tag (car tags))

Re: Checkout a branch in cvs-tree

[Stefan Monnier]

> Thank you for your advice.
> Base on the advice, I have rewritten the patch.

Feel free to commit it if you think it's in a good enough state.
I don't have time to look at it right now, but I'll trust you.


        Stefan