GNU bug report logs -
#23759
25.1.50; open-tls-stream creates malformed gnutls-cli command if trusted cert files don't exist
Previous Next
Reported by: flitterio <at> gmail.com (Francis Litterio)
Date: Sun, 12 Jun 2016 21:35:02 UTC
Severity: normal
Tags: security, wontfix
Found in version 25.1.50
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 23759 in the body.
You can then email your comments to 23759 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Sun, 12 Jun 2016 21:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
flitterio <at> gmail.com (Francis Litterio):
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 12 Jun 2016 21:35:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Using Emacs built from the latest mainline source on Windows 7 (with all updates applied),
I see this problem:
1. Launch Emacs using: emacs.exe -Q
2. Evaluate this form in buffer *scratch*:
(progn
(require 'tls)
(open-tls-stream "foo" nil "irc.oftc.net" 6697))
After the connection is established, buffer *Messages* shows two failed connection
attempts using gnutls-cli, followed by a successful connection using openssl:
Opening TLS connection to ‘irc.oftc.net’...
Opening TLS connection with ‘gnutls-cli --x509cafile nil -p 6697 irc.oftc.net’...failed
Opening TLS connection with ‘gnutls-cli --x509cafile nil -p 6697 irc.oftc.net --protocols ssl3’...failed
Opening TLS connection with ‘openssl s_client -connect irc.oftc.net:6697 -no_ssl2 -ign_eof’...done
Opening TLS connection to ‘irc.oftc.net’...done
Notice switch "--x509cafile nil" passed to gnutls-cli, which cause it to fail both times.
The root cause has to do with variable tls-program, which has this value:
("gnutls-cli --x509cafile %t -p %p %h"
"gnutls-cli --x509cafile %t -p %p %h --protocols ssl3"
"openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
The docstring for tls-program says that %t is replaced "with a file name containing
trusted certificates". The names of trusted certificate files come from variable
gnutls-trustfiles, which has this value:
("/etc/ssl/certs/ca-certificates.crt"
"/etc/pki/tls/certs/ca-bundle.crt"
"/etc/ssl/ca-bundle.pem"
"/usr/ssl/certs/ca-bundle.crt"
"/usr/local/share/certs/ca-root-nss.crt")
The docstring for gnutlsw-trustfiles says:
The files may not exist, in which case they will be ignored.
These files do not exist on my Windows system, but the %t in the strings listed in
variable tls-program is replaced by "nil", which creates a malformed gnutls-cli command.
I can work around the problem by setting variable tls-program to this list, which is the
above list without the "--x509cafile %t" in the gnutls-cli commands:
("gnutls-cli -p %p %h"
"gnutls-cli -p %p %h --protocols ssl3"
"openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
If the no trusted cert file is available, the gnutls-cli command needs to be constructed
more intelligently, so as not to create a malformed command. This problem seems to be
localized in this code in function open-tls-stream in lisp/net/tls.el:
(with-current-buffer buffer
(message "Opening TLS connection to `%s'..." host)
(while (and (not done) (setq cmd (pop cmds)))
(let ((process-connection-type tls-process-connection-type)
(formatted-cmd
(format-spec
cmd
(format-spec-make
?t (car (gnutls-trustfiles))
?h host
?p (if (integerp port)
(int-to-string port)
port)))))
(message "Opening TLS connection with `%s'..." formatted-cmd)
(setq process (start-process
name buffer shell-file-name shell-command-switch
formatted-cmd))
--
Fran Litterio
In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
of 2016-05-28 built on PUPPY
Repository revision: 549470fdf234acb4da7941e3bb9b28ed63a51876
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Recent messages:
Saving file c:/franl/zzz-emacs-bug-open-tls-stream.el...
Wrote c:/franl/zzz-emacs-bug-open-tls-stream.el
Saving file c:/franl/zzz-emacs-bug-open-tls-stream.el...
Wrote c:/franl/zzz-emacs-bug-open-tls-stream.el
Saving file c:/franl/zzz-emacs-bug-open-tls-stream.el...
Wrote c:/franl/zzz-emacs-bug-open-tls-stream.el
Mark set
Mark saved where search started
Mark set [2 times]
Type "q" to delete help window.
Configured using:
'configure --prefix=/c/apps/emacs --without-x --without-xpm
--without-png --without-jpeg --without-tiff --without-gif'
Configured features:
SOUND NOTIFY ACL TOOLKIT_SCROLL_BARS
Important settings:
value of $LANG: C.ISO-8859-1
locale-coding-system: cp1252
Major mode: Emacs-Lisp
Minor modes in effect:
erc-list-mode: t
erc-menu-mode: t
erc-ring-mode: t
erc-networks-mode: t
erc-pcomplete-mode: t
erc-track-mode: t
erc-track-minor-mode: t
erc-match-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-netsplit-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
diff-auto-refine-mode: t
show-paren-mode: t
save-place-mode: t
icomplete-mode: t
savehist-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Load-path shadows:
None found.
Features:
(shadow mail-extr emacsbug skeleton gud mm-archive url-http url-gw
url-cache url-auth url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util jka-compr face-remap tabify
imenu edmacro kmacro eieio-opt speedbar sb-image ezimage dframe
find-func help-fns rect vc-git misearch multi-isearch server sort
gnus-draft gnus-agent gnus-srvr nnvirtual nndraft nnmh gnus-msg
gnus-cite canlock gnus-async gnus-score score-mode gnus-art mm-uu
mml2015 mm-view mml-smime smime dig mailcap gnus-cache gnus-sum fpl-moo
fpl-react cl erc-sasl erc-notify erc-truncate erc-log erc-dcc erc-list
erc-menu erc-join erc-ring erc-networks erc-pcomplete erc-track
erc-match erc-button erc-fill erc-stamp erc-netsplit erc-goodies erc
erc-backend erc-compat thingatpt source-safe ediff-merg ediff-wind
ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff grep
sh-script smie executable python tramp-sh json map ielm pp sgml-mode
csharp-mode cc-langs smtpmail sendmail nntp gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc parse-time
gnus-spec gnus-int gnus-range message rfc822 mml mml-sec epa derived epg
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader gnus-win nnoo gnus nnheader subr-x gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util mail-prsvr
wid-edit etags vc vc-dispatcher dired-aux hexl smerge-mode diff-mode
easy-mmode paren man info compile apropos tramp tramp-compat
tramp-loaddefs trampver ucs-normalize format-spec advice saveplace
icomplete xref project savehist browse-url shell pcomplete warnings
arc-mode archive-mode ange-ftp socks network-stream puny nsm starttls
tls gnutls dired dired-loaddefs cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs comint ansi-color
ring calc-ext calc calc-loaddefs calc-macs time-stamp finder-inf package
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)
Memory information:
((conses 8 524945 95746)
(symbols 32 46666 0)
(miscs 32 274 2594)
(strings 16 105202 34595)
(string-bytes 1 3339203)
(vectors 8 72445)
(vector-slots 4 1840040 248756)
(floats 8 547 954)
(intervals 28 15501 2890)
(buffers 528 53))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 Jun 2016 03:42:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 23759 <at> debbugs.gnu.org (full text, mbox):
> From: flitterio <at> gmail.com (Francis Litterio)
> Date: Sun, 12 Jun 2016 17:32:56 -0400
>
> Using Emacs built from the latest mainline source on Windows 7 (with all updates applied),
> I see this problem:
>
> 1. Launch Emacs using: emacs.exe -Q
>
> 2. Evaluate this form in buffer *scratch*:
>
> (progn
> (require 'tls)
> (open-tls-stream "foo" nil "irc.oftc.net" 6697))
>
> After the connection is established, buffer *Messages* shows two failed connection
> attempts using gnutls-cli, followed by a successful connection using openssl:
TLS connections on MS-Windows are supported via the GnuTLS library.
External TLS programs will never work correctly on Windows, since they
use signals to communicate with Emacs. So there's little sense in
fixing this issue, because the result will not work anyway.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 Jun 2016 10:19:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 23759 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> TLS connections on MS-Windows are supported via the GnuTLS library.
> External TLS programs will never work correctly on Windows, since they
> use signals to communicate with Emacs. So there's little sense in
> fixing this issue, because the result will not work anyway.
Perhaps it would make sense to just have `open-tls-stream' signal an
error on Windows to avoid confusing people? I think this is at least
the fourth bug report where people have spent significant time trying to
debug something that will never work.
It could just say (error "Use an Emacs built with TLS support (and with
installed gnutls libraries)").
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 Jun 2016 11:35:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
If Cygwin is installed, open-tls-stream works, because gnutls-cli and
openssl are available. It has worked for some time. I routinely use this
feature to enable ERC to connect to servers using TLS using function
erc-tls.
This bug report is about an Elisp logic error that can happen on any
platform if the certificate trust files do not exist, leading to a
malformed gnutls-cli command line. Those files are outside the control of
Emacs. They may not exist.
Please don't disable functionality that some of us have used for years.
Thanks.
--
Fran Litterio
On Jun 13, 2016 6:18 AM, "Lars Ingebrigtsen" <larsi <at> gnus.org> wrote:
Eli Zaretskii <eliz <at> gnu.org> writes:
> TLS connections on MS-Windows are supported via the GnuTLS library.
> External TLS programs will never work correctly on Windows, since they
> use signals to communicate with Emacs. So there's little sense in
> fixing this issue, because the result will not work anyway.
Perhaps it would make sense to just have `open-tls-stream' signal an
error on Windows to avoid confusing people? I think this is at least
the fourth bug report where people have spent significant time trying to
debug something that will never work.
It could just say (error "Use an Emacs built with TLS support (and with
installed gnutls libraries)").
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 Jun 2016 11:41:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 23759 <at> debbugs.gnu.org (full text, mbox):
Fran <flitterio <at> gmail.com> writes:
> If Cygwin is installed, open-tls-stream works, because gnutls-cli and openssl
> are available. It has worked for some time. I routinely use this feature to
> enable ERC to connect to servers using TLS using function erc-tls.
At some point, tls.el will be deprecated. Why aren't you just using
Emacs with the built-in TLS support?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 Jun 2016 11:50:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Jun 13, 2016 7:40 AM, "Lars Ingebrigtsen" <larsi <at> gnus.org> wrote:
> At some point, tls.el will be deprecated. Why aren't you just using
> Emacs with the built-in TLS support?
I didn't know of the plan to deprecate tls.el. And this way has always
worked on Windows. I'll certainly try to get "make configure" to enable
built-in TLS support on Windows when building with MinGW. If I can get that
to work, I'll send a patch so we can hasten the deprecation of tls.el.
--
Fran
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 Jun 2016 14:03:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 23759 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: flitterio <at> gmail.com (Francis Litterio), 23759 <at> debbugs.gnu.org
> Date: Mon, 13 Jun 2016 12:18:15 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > TLS connections on MS-Windows are supported via the GnuTLS library.
> > External TLS programs will never work correctly on Windows, since they
> > use signals to communicate with Emacs. So there's little sense in
> > fixing this issue, because the result will not work anyway.
>
> Perhaps it would make sense to just have `open-tls-stream' signal an
> error on Windows to avoid confusing people? I think this is at least
> the fourth bug report where people have spent significant time trying to
> debug something that will never work.
>
> It could just say (error "Use an Emacs built with TLS support (and with
> installed gnutls libraries)").
At least a warning sounds like a good idea. Not so sure about
erroring out, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Sat, 02 Jul 2016 00:23:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
I am using emacs on OSX 10.12 from https://emacsformacosx.com/builds:
(emacs-version)
"GNU Emacs 25.1.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version
10.9.5 (Build 13F1603))
of 2016-05-30"
And experience the same problem when running emacs -Q. Furthermore, I
diagnosed the cause to be incorrect building of formatted-cmd in
open-tls-stream from the given arguments. Attached is a patch that fixes
the problem on my end. To make the patch smaller, I did not reindent the
whole function - I hope this is alright.
Finally, I'd like to reply to:
> Fran <flitterio <at> gmail.com> writes:
> If Cygwin is installed, open-tls-stream works, because gnutls-cli and
> openssl
> > are available. It has worked for some time. I routinely use this feature
> to
> > enable ERC to connect to servers using TLS using function erc-tls.
> At some point, tls.el will be deprecated. Why aren't you just using
> Emacs with the built-in TLS support?
In my honest opinion, a feature is either deprecated or not, and while it
is not yet deprecated, bugs should not be ignored. I hope you would agree
at least to the point of testing the patch and incorporating it if it works
well :-)
Fuller description of the problem and the fix:
The problem: `open-tls-stream' replaces %t with exactly one element, which
is nil if none of gnutls-trustfiles is readable, and the first element of
gnutls-trustfiles is more than one is readable.
The Solution: In the patch I make the test iterate on all the trustfiles as
a user might have more than one relevant. In addition, I made the default
setting for tls-program have entries that do not explicitly specify the
trustfile.
One thing to note here perhaps, is that if (gnutls-trustfiles) returns an
empty list and one has the %t substitution in one of the tls-program
entries, then that entry will not be run at all. I feel that this is
reasonable since by setting --x509cafile nil one makes gnutls-cli fail
anyway.
Finally, I'm experiencing the above behavior, as far as I can tell, by
default in e.g. erc-tls. What is the proper way to move to the built in
TLS? Is it likely to be something in my config or in the implementation of
ERC?
Thanks,
Kosta
--
Konstantin Kliakhandler
http://slumpy.org
)°) )°( (°(
[Message part 2 (text/html, inline)]
[0001-tls-Make-open-tls-stream-try-all-gnutls-trustfiles-a.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Sat, 02 Jul 2016 16:56:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
First, I apologize for the double posting - I realize that I sent the
previous message with a messed up subject and this caused it not to be
grouped with the rest of the messages in this bug, and to not appear in the
tracker. I hope this second one will work now.
I am using emacs on OSX 10.12 from https://emacsformacosx.com/builds:
(emacs-version)
"GNU Emacs 25.1.50.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version
10.9.5 (Build 13F1603))
of 2016-05-30"
And experience the same problem when running emacs -Q. Furthermore, I
diagnosed the cause to be incorrect building of formatted-cmd in
open-tls-stream from the given arguments. Attached is a patch that fixes
the problem on my end. To make the patch smaller, I did not reindent the
whole function - I hope this is alright.
Finally, I'd like to reply to:
> Fran <flitterio <at> gmail.com> writes:
> If Cygwin is installed, open-tls-stream works, because gnutls-cli and
> openssl
> > are available. It has worked for some time. I routinely use this feature
> to
> > enable ERC to connect to servers using TLS using function erc-tls.
> At some point, tls.el will be deprecated. Why aren't you just using
> Emacs with the built-in TLS support?
In my honest opinion, a feature is either deprecated or not, and while it
is not yet deprecated, bugs should not be ignored. I hope you would agree
at least to the point of testing the patch and incorporating it if it works
well :-)
Fuller description of the problem and the fix:
The problem: `open-tls-stream' replaces %t with exactly one element, which
is nil if none of gnutls-trustfiles is readable, and the first element of
gnutls-trustfiles is more than one is readable.
The Solution: In the patch I make the test iterate on all the trustfiles as
a user might have more than one relevant. In addition, I made the default
setting for tls-program have entries that do not explicitly specify the
trustfile.
One thing to note here perhaps, is that if (gnutls-trustfiles) returns an
empty list and one has the %t substitution in one of the tls-program
entries, then that entry will not be run at all. I feel that this is
reasonable since by setting --x509cafile nil one makes gnutls-cli fail
anyway.
Finally, I'm experiencing the above behavior, as far as I can tell, by
default in e.g. erc-tls. What is the proper way to move to the built in
TLS? Is it likely to be something in my config or in the implementation of
ERC?
Thanks,
Kosta
[Message part 2 (text/html, inline)]
[0001-tls-Make-open-tls-stream-try-all-gnutls-trustfiles-a.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Tue, 05 Jul 2016 14:37:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 23759 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2 Jul 2016 10:09:50 +0300 Konstantin Kliakhandler <kosta <at> slumpy.org> wrote:
KK> The problem: `open-tls-stream' replaces %t with exactly one element, which
KK> is nil if none of gnutls-trustfiles is readable, and the first element of
KK> gnutls-trustfiles is more than one is readable.
KK> The Solution: In the patch I make the test iterate on all the trustfiles as
KK> a user might have more than one relevant. In addition, I made the default
KK> setting for tls-program have entries that do not explicitly specify the
KK> trustfile.
KK> One thing to note here perhaps, is that if (gnutls-trustfiles) returns an
KK> empty list and one has the %t substitution in one of the tls-program
KK> entries, then that entry will not be run at all. I feel that this is
KK> reasonable since by setting --x509cafile nil one makes gnutls-cli fail
KK> anyway.
As you said, one of the key points of your patch is this:
- '("gnutls-cli --x509cafile %t -p %p %h"
+ '("gnutls-cli -p %p %h"
+ "gnutls-cli --x509cafile %t -p %p %h"
Which replaces the specific call with a generic call (no CA file
specified). This is probably less secure because it will use the system
CA trustfiles regardless of the user's preferred `gnutls-trustfiles', so
I'd rather not make it the first thing attempted.
KK> Finally, I'm experiencing the above behavior, as far as I can tell, by
KK> default in e.g. erc-tls. What is the proper way to move to the built in
KK> TLS? Is it likely to be something in my config or in the implementation of
KK> ERC?
On Mac OS X, you can use Homebrew to build it with all the nice
libraries, or use one of the pre-built binary packages.
brew update && brew reinstall emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick
On W32, you need the right DLLs installed.
Once the libraries are installed, you're all set, they'll be used
automatically.
Ted
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Tue, 05 Jul 2016 14:50:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 23759 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 5, 2016 at 10:36 AM, Ted Zlatanov <tzz <at> lifelogs.com> wrote:
>
> KK> Finally, I'm experiencing the above behavior, as far as I can tell, by
> KK> default in e.g. erc-tls. What is the proper way to move to the built in
> KK> TLS? Is it likely to be something in my config or in the implementation of
> KK> ERC?
>
> On Mac OS X, you can use Homebrew to build it with all the nice
> libraries, or use one of the pre-built binary packages.
>
> brew update && brew reinstall emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick
I think gnutls is broken on master for OSX currently, see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23503
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Tue, 05 Jul 2016 16:56:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
On 5 July 2016 at 17:49, Noam Postavsky <npostavs <at> users.sourceforge.net>
wrote:
>
> I think gnutls is broken on master for OSX currently, see
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23503
>
When I do this, with my patch enabled, I get a buffer with:
Cache-Control: max-age=0
> Expires: Tue, 05 Jul 2016 14:58:42 GMT
> Content-Length: 3104
> Keep-Alive: timeout=3, max=100
> Connection: Keep-Alive
> Content-Type: text/html
> Content-Language: en
> ...
Of course, it would have worked even before the patch since currently
tls.el by default attempts two connections via gnutls-tls and then tries
via openssl s_client, which always worked for me (at least for ERC).
On 5 July 2016 at 17:36, Ted Zlatanov <tzz <at> lifelogs.com> wrote:
>
>
> As you said, one of the key points of your patch is this:
>
> - '("gnutls-cli --x509cafile %t -p %p %h"
> + '("gnutls-cli -p %p %h"
> + "gnutls-cli --x509cafile %t -p %p %h"
>
I wouldn't characterize it as "one of the key points" of my patch, and the
patch would work just as well if instead the line without --x509cafile was
at the bottom of the list. Well, it would work worse for some users, but
the key word is that it would work - except that now now it would take
several more attempts to connect on my computer and on OPs (instead of just
not connecting at all for OP).
Which replaces the specific call with a generic call (no CA file
> specified). This is probably less secure because it will use the system
> CA trustfiles regardless of the user's preferred `gnutls-trustfiles', so
> I'd rather not make it the first thing attempted.
Personally, I also think that the default as defined in my current patch is
preferable, since anyone who messes around with the certificates would edit
this variable e.g. to set there --strict-tofu or the like (I did. It is a
bit more annoying to use, but since I rarely open a new domain in emacs,
it's not a big deal). For everyone else, they trust their system CAs all
the time when they go online. Especially considering that the previous
default for this variable had "--insecure" in the arguments, I thought that
the priorities for the new setting was 1>2>3 "1. It is secure by default.
2. It works by default. 3. It is secure in edge cases", rather than 1>3>2.
Anyway, I do concede that the second version is more secure. Attached is a
patch that I hope is more to your liking. I put the the call that do not
use an explicit certificate at the bottom of the list, even below the call
to openssl s_client. I'm not sure what are the implications, as I don't
know the relative merits of openssl s_client vs gnutls-cli. If you are
inclined to educate me, please do as a short googling did not reveal the
answers.
> Once the libraries are installed, you're all set, they'll be used
> automatically.
>
From what both of you said, I still am not sure what is meant by "native
support". However, for various reasons I don't like the version provided in
homebrew. I prefer the version from https://emacsformacosx.com. Noam, is
this *"one of the pre-built binary packages"* you were referring to, or did
you mean something else? How will I know that the libraries are being used?
Finally, is there a way to test them explicitly? Anyway, it seems that the
version I got from the site above does not have built in gnutls:
system-configuration-features is a variable defined in ‘C source code’.
Its value is "NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS"
system-configuration-options is a variable defined in ‘C source code’.
Its value is
"--with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp'
I'll build one myself and see if the results I get are any different.
Thanks for your time,
Kosta
[Message part 2 (text/html, inline)]
[0001-tls-Make-open-tls-stream-try-all-gnutls-trustfiles-a.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Tue, 05 Jul 2016 18:00:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 23759 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 5, 2016 at 12:54 PM, Konstantin Kliakhandler
<kosta <at> slumpy.org> wrote:
> From what both of you said, I still am not sure what is meant by "native
> support". However, for various reasons I don't like the version provided in
> homebrew. I prefer the version from https://emacsformacosx.com. Noam, is
> this "one of the pre-built binary packages" you were referring to, or did
> you mean something else? How will I know that the libraries are being used?
> Finally, is there a way to test them explicitly?
If evaluating (gnutls-available-p) returns t, then you are using the
gnutls library (if the function is undefined then your Emacs is not
compiled with libgnutls support). And if you hit bug 22929/23225/23503
then you might notice by seeing that https doesn't work :(
I don't run OSX (Ted was the one mentioning "pre-built binary
packages"), so I can't say much more than that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Tue, 05 Jul 2016 21:18:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 23759 <at> debbugs.gnu.org (full text, mbox):
On Tue, 5 Jul 2016 10:49:38 -0400 Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
NP> I think gnutls is broken on master for OSX currently, see
NP> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23503
Unfortunately I don't have access to Mac OS X anymore (I did until
recently) so I can't verify or fix that issue.
On Tue, 5 Jul 2016 19:54:53 +0300 Konstantin Kliakhandler <kosta <at> slumpy.org> wrote:
KK> On 5 July 2016 at 17:36, Ted Zlatanov <tzz <at> lifelogs.com> wrote:
>> [Kosta's patch] replaces the specific call with a generic call (no CA file
>> specified). This is probably less secure because it will use the system
>> CA trustfiles regardless of the user's preferred `gnutls-trustfiles', so
>> I'd rather not make it the first thing attempted.
KK> the patch would work just as well if instead the line without --x509cafile was
KK> at the bottom of the list. Well, it would work worse for some users, but
KK> the key word is that it would work - except that now now it would take
KK> several more attempts to connect on my computer and on OPs (instead of just
KK> not connecting at all for OP).
Unfortunately it's less secure in the default case. I agree that it's
faster and more convenient. Perhaps there can be a way to say "if this
%t is empty, remove the preceding --argument as well" in the format
string? That would simplify the whole thing, like so:
"gnutls-cli --x509cafile %T -p %p %h"
...becomes "gnutls-cli -p PORT HOST" when the %T parameter is nil. Just
an idea...
KK> Personally, I also think that the default as defined in my current patch is
KK> preferable, since anyone who messes around with the certificates would edit
KK> this variable e.g. to set there --strict-tofu or the like (I did. It is a
KK> bit more annoying to use, but since I rarely open a new domain in emacs,
KK> it's not a big deal).
Many users don't know about these settings, and many don't have the
right GnuTLS libraries installed but think they do (so they are using
this library accidentally). I think it's good to be cautious here and
provide safe defaults.
The TOFU stuff is an interesting use case. The Emacs NSM (see
`network-security-level' and friends) tries to address this area to some
degree, but there's lots of work to be done.
KK> Anyway, I do concede that the second version is more secure. Attached is a
KK> patch that I hope is more to your liking. I put the the call that do not
KK> use an explicit certificate at the bottom of the list, even below the call
KK> to openssl s_client. I'm not sure what are the implications, as I don't
KK> know the relative merits of openssl s_client vs gnutls-cli. If you are
KK> inclined to educate me, please do as a short googling did not reveal the
KK> answers.
I'd group all the gnutls-cli calls together so it's more predictable and
easier to read. Otherwise it's fine IMHO. I know we have many security
experts here, perhaps they'll comment.
I am also concerned that SSLv3 is explicitly in the defaults. See
http://disablessl3.com/ etc.--I think that should be removed if
possible. I'll bring it up on emacs-devel.
>> Once the libraries are installed, you're all set, they'll be used
>> automatically.
KK> From what both of you said, I still am not sure what is meant by "native
KK> support". However, for various reasons I don't like the version provided in
KK> homebrew. I prefer the version from https://emacsformacosx.com.
OK, talk to the people that build that version :) Homebrew is what I
used when I had access to Mac OS X, and it worked well for me.
As Noam said, if `gnutls-available-p' returns t, you've got the native C
bindings to GnuTLS working. IMHO after the 25.1 release, opening a
secure network connection without `gnutls-available-p' should be an
annoying warning. I'll bring it up on emacs-devel.
Ted
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Wed, 06 Jul 2016 22:26:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Unfortunately I don't have access to Mac OS X anymore (I did until
> recently) so I can't verify or fix that issue.
I hope this means you're now using a free operating system!
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Thu, 07 Jul 2016 03:33:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 23759 <at> debbugs.gnu.org (full text, mbox):
On Wed, 06 Jul 2016 18:24:47 -0400 Richard Stallman <rms <at> gnu.org> wrote:
>> Unfortunately I don't have access to Mac OS X anymore (I did until
>> recently) so I can't verify or fix that issue.
RS> I hope this means you're now using a free operating system!
I have not stopped since 1996 or so :)
Ted
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Thu, 07 Jul 2016 06:12:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
What about free hardware? ;-)
--
)°))°((°(
Konstantin Kliakhandler
Sent on the go.
On Jul 7, 2016 06:31, "Ted Zlatanov" <tzz <at> lifelogs.com> wrote:
> On Wed, 06 Jul 2016 18:24:47 -0400 Richard Stallman <rms <at> gnu.org> wrote:
>
> >> Unfortunately I don't have access to Mac OS X anymore (I did until
> >> recently) so I can't verify or fix that issue.
>
> RS> I hope this means you're now using a free operating system!
>
> I have not stopped since 1996 or so :)
>
> Ted
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Thu, 07 Jul 2016 17:11:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 23759 <at> debbugs.gnu.org (full text, mbox):
Kosta: ping, I noted some minor needed improvements in my last message,
maybe you missed it... Thanks!
Ted
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Thu, 07 Jul 2016 22:03:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
If you are concerned about "free hardware", see
See http://gnu.org/philosophy/free-hardware-designs.html
That is out-of-topic for this list, though.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Thu, 07 Jul 2016 22:41:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 23759 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Ted,
Sorry, I saw the message but didn't get a chance to act on it. Writing a
joking remark on a mobile phone takes much less time and effort...
Anyway,
T> Perhaps there can be a way to say
T> "if this %t is empty, remove the preceding --argument as well"
T> in the format string? That would simplify the whole thing, like so:
T> "gnutls-cli --x509cafile %T -p %p %h"
T> ...becomes "gnutls-cli -p PORT HOST"
T> when the %T parameter is nil. Just an idea...
I toyed with this idea, and even implemented something of the sort, but
from a bit different different direction - I added another replacement
variable - %c - and made the list tls-program now contain pairs with
(string . value-of-c), e.g. ("gnutls-cli %c %T -p %p %h" . "--x509cafile")
have both %c and %T replaced (together) as appropriate.
The problem with this approach is, what about people who customized this
setting? So, I made it backward compatible with the old standard.
Eventually however, it turned into a an ugly big mess due to the backward
compatability and I decided against submitting.
There is a similar problem of backward compatibility in your approach -
what if someone customized it in such a way that wasn't expecting an
argument to be removed, and it would create a vulnerability in their setup?
I also don't see a simple way to do it nicely, but have no objections on
those grounds, of course.
Finally, I would do the patch but am uncertain whether it would be better
to wait for your results from emacs-devel and remove the ssl3 bit as well
(or just go ahead and do it). Let me know and I'll send the appropriate
patch.
Best,
Kosta
--
Konstantin Kliakhandler
http://slumpy.org
)°) )°( (°(
On Thu, 7 Jul 2016 at 20:10 Ted Zlatanov <tzz <at> lifelogs.com> wrote:
> Kosta: ping, I noted some minor needed improvements in my last message,
> maybe you missed it... Thanks!
>
> Ted
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Fri, 08 Jul 2016 13:44:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 23759 <at> debbugs.gnu.org (full text, mbox):
On Fri, 8 Jul 2016 01:40:13 +0300 Konstantin Kliakhandler <kosta <at> slumpy.org> wrote:
T> Perhaps there can be a way to say
T> "if this %t is empty, remove the preceding --argument as well"
T> in the format string? That would simplify the whole thing, like so:
T> "gnutls-cli --x509cafile %T -p %p %h"
T> ...becomes "gnutls-cli -p PORT HOST"
T> when the %T parameter is nil. Just an idea...
KK> I toyed with this idea, and even implemented something of the sort, but
KK> from a bit different different direction - I added another replacement
KK> variable - %c - and made the list tls-program now contain pairs with
KK> (string . value-of-c), e.g. ("gnutls-cli %c %T -p %p %h" . "--x509cafile")
KK> have both %c and %T replaced (together) as appropriate.
KK> The problem with this approach is, what about people who customized this
KK> setting? So, I made it backward compatible with the old standard.
KK> Eventually however, it turned into a an ugly big mess due to the backward
KK> compatability and I decided against submitting.
KK> There is a similar problem of backward compatibility in your approach -
KK> what if someone customized it in such a way that wasn't expecting an
KK> argument to be removed, and it would create a vulnerability in their setup?
KK> I also don't see a simple way to do it nicely, but have no objections on
KK> those grounds, of course.
Hmm, right, yeah... well %t is always preceded by an argument, right? So
maybe the backwards-compatible solution is that if %t is nil, delete the
preceding option?
Another option is to throw an error when %t is nil, explaining what
happened and how to fix it. That's not a terrible inconvenience for the
user, compared to running an insecure connection unknowingly. I slightly
prefer this.
KK> Finally, I would do the patch but am uncertain whether it would be better
KK> to wait for your results from emacs-devel and remove the ssl3 bit as well
KK> (or just go ahead and do it). Let me know and I'll send the appropriate
KK> patch.
Go ahead and remove it, we have agreement that it's a Bad Thing. Thank you!
Ted
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23759; Package
emacs.
(Mon, 13 May 2019 19:43:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 23759 <at> debbugs.gnu.org (full text, mbox):
flitterio <at> gmail.com (Francis Litterio) writes:
> 2. Evaluate this form in buffer *scratch*:
>
> (progn
> (require 'tls)
> (open-tls-stream "foo" nil "irc.oftc.net" 6697))
tls.el has been deprecated in Emacs 27.1 (Emacs uses built-in TLS
instead), so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 13 May 2019 19:44:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
23759 <at> debbugs.gnu.org and flitterio <at> gmail.com (Francis Litterio)
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 13 May 2019 19:44: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.
(Tue, 11 Jun 2019 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 341 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.