[jasspa] Re: Crypto mode?
- Its 'Shoot me' time again. I ripped out the -k option firstly because it was
unclear in its use (does it apply to the first file, the next file or all
files given on the command-line etc) and secondly due to shell history lists
this would be a severe security problem.
I use the crypt mode myself and always use the find-cfile command to load
existing crypted files. To make an uncrypted file crypted simply add the crypt
mode and you will be prompted for the key at save time.
Note that crypt files are incompatible between ME and MicroEMACS (JASSPA's is
> Thomas Hundt wrote:
> > Does crypto mode work? The manpage says one can use Esc-e to do 'set-encryption-key' (which is not true, but maybe I unbound it). It also says one can use '-k' to set the password from the command line.
> I think you must have unbound it. Try doing "M-x describe-bindings"
> this should tell you what is currently bound. M-e is definately bound
> as expected here .
> > The '-k' command-line option yields a complaint when I run the command-line version of me.exe (this is under NT4); using this option with the gui version (me32.exe) doesn't give me anything at all -- it won't even launch the program. (Then again, neither does '-h'.) Now that's what I call cryptic!
> The win32 gui version will not produce anything on stdout because there is no
> concept of
> stdout (sigh *if* only this was UNIX !), where as your X-Windows version would.
> In theory you should get an error message.
> Now where did you get the option -k <key> from ?? The JASSPA distributuion does
> not have one of these, you must have seen this on the other leading brand
> of MicroEmacs. This is obviously a post MicroEmacs 3.8 option !! But wait, I've
> a reference to it in the "set-encryption-key" help. Oops look like this has
> got lost from the command line !! So no support for that one then - do
> you need this fixed or can we delete the -k from the documentation !!
> I'm not sure what -k <key> would do on the command line. I assume that
> it sets the default key for the command line files ??
> Note that when you do "M-x find-cfile" to load an encrypted file it prompts
> for the password. The encryption key is stored on a per-buffer basis so
> you have to specify what it is for each file. There is no concept of a
> global key that is applicable to all encrypted files.
> Having never worked with encrypted files, would it be better to include
> a magic string in the header of the encrypted file to tell ME that this
> is an encrypted file. Then it could automatically turn on encrypted mode
> and prompt for the password when the file is loaded. This should not breach
> security provided that the magic string is not encrypted ??
> > Motivation: I use the Other Leading Brand of MicroEmacs (namely Micro EMACS 4.00 from Daniel Lawrence, who seems to have gone out of the MicroEmacs business) to maintain files containing sensitive info like credit card numbers and names of ex-girlfriends... I was thinking of switching that over to me32 now that I've used it for a while and believe it to be stable. (And, I have to say, it's a much more advanced package.) This is the only thing I still use the old ME for, and sooner or later I'm going to run into the 64k limitation on file size (after which, the old one starts to do unfriendly things).
> > (No, I do not have 64k of ex-girlfriends. I keep notes in the file every time I deal with a credit card company, bank, ISP, etc., and that's what keeps growing.)
> > Hints, advice? What silly thing am I doing wrong, this time?
> Would appriciate it if you could first set your encryption key
> and try reading one of your encrypted files. The algorthm should
> decode it and read it in. Also if you can confim the write back
> from Jasspa and read from the other leading brand of MicroEmacs.
> This has been tested (a very long time ago), but I cannot recall
> anybody using it with vengence. The algorithms should be the same.
> We swapped to the newer uE algorithm about 12-18 months ago for
> I suggest backing up your old file first - just in case anything
> untoward happens !!
> > Thank you,
> > -Th
> > ------------------------------------------------------------------------
> > __________________________________________________________________________
> > This is an unmoderated list. JASSPA is not responsible for the content of
> > any material posted to this list.
> Jon Green - jon@...
> This is an unmoderated list. JASSPA is not responsible for the content of
> any material posted to this list.