unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daiki Ueno <ueno@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: [PATCH] Add GPG compatible symmetric encryption command
Date: Sat, 08 Feb 2014 15:24:54 +0900	[thread overview]
Message-ID: <87ha8a2kax.fsf-ueno@gnu.org> (raw)
In-Reply-To: <87txcbawsi.fsf@lifelogs.com> (Ted Zlatanov's message of "Fri, 07 Feb 2014 08:15:41 -0500")

Ted Zlatanov <tzz@lifelogs.com> writes:

> Meanwhile, would you consider continuing with your patch to the point
> where Lars can use it from Gnus?

I wouldn't take that risk, sorry.  Emacs will soon get CVE numbers
assigned, unless the patch will be carefully reviewed by experts and
actively maintained.  I already found a few flaws that may lead to a
security hole.

However, since it is free software, if your writing of this:

> I wrote similar integration code in my original libnettle patch and am
> sure it could use similar thoroughness.

is true and you _really_ understand the background theory of this
"integration" code, you could perhaps complete the task by yourself?

Let's look at your patch:
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00144.html

Ouch.  Why do you expose IV to Elisp and don't use any salt?  Are you
aware that you are negating security doing secret key operation in
Elisp?  Why do you always allocate new memory for key on heap,
plaintext, cipher, and why don't you clear them.  How do you check if
password is correct or wrong.

It's much worse than I expected.  I'm afraid to say you can't write any
security related code that people can depend on, at this skill level.

I'd suggest to read GNUTLS or GnuPG code to learn how practical
encryption code works.  Perhaps my patch might also give you some
inspiration.

> As I said, I don't think it affects my request for
> GnuTLS/libnettle/libhogweed primitives[1]

Well, didn't we already decide to use FFI for that?  That implies those
primitives won't be part of Emacs by default.  Emacs is not your
playground to try out your pseudo security feature.  I remember Stefan
already suggested you to do that in your ELPA package even after FFI
becomes available.

> [1] you omitted an answer to that question from your reply, so I assume
> you agree.

Of course not.
-- 
Daiki Ueno



  reply	other threads:[~2014-02-08  6:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07  8:36 [PATCH] Add GPG compatible symmetric encryption command Daiki Ueno
2014-02-07 11:09 ` Ted Zlatanov
2014-02-07 12:24   ` Daiki Ueno
2014-02-07 13:15     ` Ted Zlatanov
2014-02-08  6:24       ` Daiki Ueno [this message]
2014-02-08 16:27         ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ha8a2kax.fsf-ueno@gnu.org \
    --to=ueno@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).