Hi there,
I found some problems with gnutls-1.4.5-2.fc7. One of them has caused an Emacs package Gnus to fail to retrieve emails via pop. I don't know if the bug has been fixed in latest GNUTLS 2.0 but version 1.4.5 is so old and many bugs have been fixed. Is there a reason to stick to an old GNUTLS? Any plan to fix the bug?
---- " trace of POP session to pop.gmail.com" ----
Resolving 'pop.gmail.com'... Connecting to '72.14.205.109:995'... - Certificate type: X.509 - Got a certificate list of 1 certificates.
- Certificate[0] info: # The hostname in the certificate matches 'pop.gmail.com'. # valid since: Tue Nov 15 21:22:44 GMT 2005 # expires at: Fri Nov 16 21:22:44 GMT 2007 # fingerprint: 59:51:61:89:CD:DD:B2:35:94:BB:44:97:A0:39:D5:B4 # Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc.,CN=pop.gmail.com # Issuer's DN: C=US,O=Equifax,OU=Equifax Secure Certificate Authority
- Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: RSA - Cipher: 3DES 168 CBC - MAC: SHA - Compression: NULL - Handshake was completed
- Simple Client Mode:
+OK Gpop ready for requests from 131.111.223.122 e10pf2134124qbe *** Fatal error: A TLS packet with unexpected length was received. *** Server has terminated the connection abnormally.
Process POP finished ---- end ----
Best wishes,
"L" == Leo writes:
L> Hi there, I found some problems with gnutls-1.4.5-2.fc7. One of L> them has caused an Emacs package Gnus to fail to retrieve emails L> via pop. I don't know if the bug has been fixed in latest GNUTLS L> 2.0 but version 1.4.5 is so old and many bugs have been fixed. Is L> there a reason to stick to an old GNUTLS? Any plan to fix the bug?
Leo,
I don't know why it hasn't been updated, probably the maintainer hasn't gotten around to it yet, but there has been a bug filed about it:
http://bugzilla.redhat.com/218184
For the reasons you state, I agree it would be bad to have to wait around until F9 to get gnutls updated. I have been having problems with gnutls-1.4.5, not with POP, but with outgoing SMTP traffic to my university's SMTP server with Emacs/Gnus.
Alex
"L" == Leo writes:
L> Hi there, I found some problems with gnutls-1.4.5-2.fc7. One of L> them has caused an Emacs package Gnus to fail to retrieve emails L> via pop. I don't know if the bug has been fixed in latest GNUTLS L> 2.0 but version 1.4.5 is so old and many bugs have been fixed. Is L> there a reason to stick to an old GNUTLS? Any plan to fix the bug?
[...]
"AL" == Alex Lancaster writes:
AL> http://bugzilla.redhat.com/218184
AL> For the reasons you state, I agree it would be bad to have to wait AL> around until F9 to get gnutls updated. I have been having AL> problems with gnutls-1.4.5, not with POP, but with outgoing SMTP AL> traffic to my university's SMTP server with Emacs/Gnus.
Hmm, I notice that gnutls is used as a shared library in many applications that it might be non-trivial to update if the .so version is bumped because it will require a lot of rebuilds.
$ rpm -q gnutls --provides libgnutls-extra.so.13 libgnutls-extra.so.13(GNUTLS_1_2) libgnutls-openssl.so.13 libgnutls.so.13 libgnutls.so.13(GNUTLS_1_3) gnutls = 1.4.5-2.fc7
$ rpm -q --whatrequires libgnutls.so.13 gnutls-devel-1.4.5-2.fc7 bug-buddy-2.18.0-2.fc7 loudmouth-1.2.2-3.fc7 gnutls-1.4.5-2.fc7 wireshark-0.99.6-1.fc7 libsoup-2.2.100-1.fc7 evolution-webcal-2.10.0-1.fc7 gnutls-utils-1.4.5-2.fc7 libtranslate-0.99-9.fc6 mutt-1.5.14-4.fc7 wireshark-gnome-0.99.6-1.fc7 ntfsprogs-1.13.1-6.fc7 liferea-1.2.19-3.fc7 evolution-data-server-1.10.3.1-2.fc7 gtk-gnutella-0.96.4-1.fc7 seahorse-1.0.1-6.fc7 cups-libs-1.2.12-4.fc7 cups-1.2.12-4.fc7 vlc-0.8.6c-4.lvn7 evolution-2.10.3-4.fc7
I wonder what .so version gnutls will provide and if it is source-compatible with applications that have been compiled in the past with gnutls <= 1.4.5.
Alex
On 2007-09-16 13:37 +0100, Alex Lancaster wrote:
Hmm, I notice that gnutls is used as a shared library in many applications that it might be non-trivial to update if the .so version is bumped because it will require a lot of rebuilds.
That's why it is difficult for users to upgrade this package. I try to remove Gnutls and that will remove 299 packages that depend on it as well.
Leo wrote:
On 2007-09-16 13:37 +0100, Alex Lancaster wrote:
Hmm, I notice that gnutls is used as a shared library in many applications that it might be non-trivial to update if the .so version is bumped because it will require a lot of rebuilds.
That's why it is difficult for users to upgrade this package. I try to remove Gnutls and that will remove 299 packages that depend on it as well.
Does anyone know if this new GnuTLS is API and/or ABI compatible? I know that they broke a load of API functions between 1.0 and 1.4, which required a source patches and retesting for libvirt.
Rich.
On Mon, 2007-09-17 at 12:19 +0100, Richard W.M. Jones wrote:
Leo wrote:
On 2007-09-16 13:37 +0100, Alex Lancaster wrote:
Hmm, I notice that gnutls is used as a shared library in many applications that it might be non-trivial to update if the .so version is bumped because it will require a lot of rebuilds.
That's why it is difficult for users to upgrade this package. I try to remove Gnutls and that will remove 299 packages that depend on it as well.
Does anyone know if this new GnuTLS is API and/or ABI compatible? I know that they broke a load of API functions between 1.0 and 1.4, which required a source patches and retesting for libvirt.
Are there any plans to feature GnuTLS in the crypto consolidation. I like (sort of...) the crypto consolidation idea, but for example Samba4 uses GnuTLS, as it's callback functions fits our IO modal well.
This might also avoid issues with trying to keep one more crypto package up to date.
Andrew Bartlett
2007/9/17, Richard W.M. Jones rjones@redhat.com:
Leo wrote:
On 2007-09-16 13:37 +0100, Alex Lancaster wrote:
Hmm, I notice that gnutls is used as a shared library in many applications that it might be non-trivial to update if the .so version is bumped because it will require a lot of rebuilds.
That's why it is difficult for users to upgrade this package. I try to remove Gnutls and that will remove 299 packages that depend on it as well.
Does anyone know if this new GnuTLS is API and/or ABI compatible? I know that they broke a load of API functions between 1.0 and 1.4, which required a source patches and retesting for libvirt.
I don't know about gnutls 2.0 case, but updating from 1.4.1 to 1.6.3 is safe, meaning that there is no SONAME bump . So there isn't any "need" to rebuild... (as far as i know). That might be interesting to have it.
Updating gnutls-devel >= 1.5.4 will allow filezilla 3.0.0 (final) to be available to the F-7 branch. So now, gntls 1.6.3 is only within the devel branch. But it just has been commited for the F-7 branch. I will request F-7 branch for filezilla and build for F-7 if released...
Someone know if gnutls 2.0.0 is already BuildRequired by some apps ? Anyway Might be interesting to rebuild packages in devel now instead of having it updated later...(if possible)
Nicolas (kwizart )
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list