Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1151933[details]
screenshot of the (IMHO) correct connection in Firefox
Description of problem:
When connecting with emacs to https://melpa.org/packages/ (most common repository of Emacs third-party packages) I get the error message:
gnutls.c: [1] Note that the security level of the Diffie-Hellman key
exchange has been lowered to 256 bits and this may allow decryption
of the session data
That sounds like a very bad idea to me.
Version-Release number of selected component (if applicable):
emacs-24.3-18.el7.x86_64
gnutls-3.3.22-1.el7.x86_64
How reproducible:
100% (2 out of 2)
Steps to Reproduce:
1. Follow http://melpa.org/#/getting-started and to ~/.emacs
(require 'package)
(add-to-list 'package-archives
'("melpa" . "https://melpa.org/packages/"))
(package-initialize)
2. Restart Emacs
3. Meta-[X]package-list-packages[ENTER]
Actual results:
Error log shows the above shown error message, however, then Emacs
connects and the list of packages shows up.
Expected results:
Firefox on the same URL is pretty happy with the connection settings
shown in the attached screenshot and it seems to be happy.
Additional info:
Melpa seems to advertise DH keys with more than 256 (Emacs default) prime number bits. The following makes the connection work without warnings:
(setq gnutls-min-prime-bits 1024)
I'm not sure if this is something to "fix", though. Even with the latest Emacs (25.0.93), the option is still set to 256 by default. I would suggest putting the workaround above into a KB article and close this bug.
Comment 2Nikos Mavrogiannopoulos
2016-05-10 07:55:48 UTC
This is not about getting rid of a warning. A low value such as 256 bits by default puts users at risk. We are in the process of harmonizing the crypto rules across the distribution and having each software apply its own (and in that case also insecure) default settings is against that effort.
As Nikos said there is no point in Emacs changing the value from the default at all. Or at least it should not change it without explicit configuration modification by user.
@Jan Synacek: I think Tomáš is talking about https://fedoraproject.org/wiki/Changes/CryptoPolicy ... the point is that applications should not deal with the crypto policy at all, but rather should use (hopefully sensible) system defaults.