GNU bug report logs -
#8474
23.2; smime feature requests
Previous Next
Reported by: Arik Mitschang <arik.mitschang <at> gmail.com>
Date: Mon, 11 Apr 2011 02:56:01 UTC
Severity: wishlist
Tags: patch
Found in version 23.2
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8474 in the body.
You can then email your comments to 8474 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#8474
; Package
emacs
.
(Mon, 11 Apr 2011 02:56:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Arik Mitschang <arik.mitschang <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 11 Apr 2011 02:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I have two feature requests for the smime package included in gnus
shipped with emacs. The first is trivial and simply adds the AES
encryption standard to that which is supported by emacs smime (openssl
supports these, if there are many versions which don't perhaps adding a
note the the doc string to check before changing would be appropriate in
addition to the change). This change is implemented in the first
attached patch.
The second is somewhat less trivial, some folks will have there RSA
private key not encrypted for whatever reason and it can be fairly
annoying to have to enter a password for such keys each time (and in
cases where it would not be appropriate to change the password cache
time, one would have to). Since I found no real easy way to determine if
a key is encrypted other than to open the file and check every time, I
added another bit to the smime-keys variable allowing the user to
specify if that key is clear or not, and added optional args to the
signing and decryption functions along with a helper function that will
determine if the key (by email) needs a password or not. This is
implemented in the second attached patch.
Thanks,
-Arik
[smime-new-sym.diff (text/x-patch, attachment)]
[smime-with-clearky.diff (text/x-patch, attachment)]
Added tag(s) patch.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Tue, 21 Jan 2020 00:46:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8474
; Package
emacs
.
(Tue, 04 Aug 2020 18:40:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 8474 <at> debbugs.gnu.org (full text, mbox):
(This nine year old bug report has had no attention -- sorry about
that.)
Arik Mitschang <arik.mitschang <at> gmail.com> writes:
> I have two feature requests for the smime package included in gnus
> shipped with emacs. The first is trivial and simply adds the AES
> encryption standard to that which is supported by emacs smime (openssl
> supports these, if there are many versions which don't perhaps adding a
> note the the doc string to check before changing would be appropriate in
> addition to the change). This change is implemented in the first
> attached patch.
I've now applied this to Emacs 28.
> The second is somewhat less trivial, some folks will have there RSA
> private key not encrypted for whatever reason and it can be fairly
> annoying to have to enter a password for such keys each time (and in
> cases where it would not be appropriate to change the password cache
> time, one would have to). Since I found no real easy way to determine if
> a key is encrypted other than to open the file and check every time, I
> added another bit to the smime-keys variable allowing the user to
> specify if that key is clear or not, and added optional args to the
> signing and decryption functions along with a helper function that will
> determine if the key (by email) needs a password or not. This is
> implemented in the second attached patch.
It's been so long since you sent the patch, so I don't know if you're
interested in following up on this or not. If not -- I totally
understand.
But I'm not quite sure I understand the use case. Does the patch
auto-decrypt if your private key is without a passphrase? If so, that
does indeed seem useful. On the other hand, these days I think
everybody uses a gpg agent, so it's less important whether there's a
passphrase or not these days, and people chose
always-decrypt/ask-before-decrypt independent of whether the private key
has a passphrase or not.
But I may be misinterpreting you here...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#8474
; Package
emacs
.
(Wed, 19 Aug 2020 14:05:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 8474 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> But I'm not quite sure I understand the use case. Does the patch
> auto-decrypt if your private key is without a passphrase?
There was no response in two weeks, so I'm closing this bug report. If
this is something that still needs work, respond to the debbugs address,
and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
8474 <at> debbugs.gnu.org and Arik Mitschang <arik.mitschang <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 19 Aug 2020 14:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 17 Sep 2020 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 214 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.