From simon at josefsson.org Thu Feb 1 09:05:25 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 01 Feb 2007 09:05:25 +0100 Subject: [gnutls-dev] [PATCH] Fix slow startup under Windows In-Reply-To: <45C0DD79.9000206@wireshark.org> (Gerald Combs's message of "Wed\, 31 Jan 2007 10\:18\:33 -0800") References: <45C0DD79.9000206@wireshark.org> Message-ID: <87r6ta716i.fsf@latte.josefsson.org> Gerald Combs writes: > Attached is a modified version of the patch at > http://www.securitypunk.com/libgcrypt/ which addresses the slow startup > problems with libgcrypt under Windows. The patch includes following > changes: Thanks. Ultimately, the patch will have to be reviewed and installed by the libgcrypt people, but I took a quick look. I may end up installing a patch for gnutls4win before it has been applied to libgcrypt, but only if I think it looks good. I'd wish that you could get Werner to look at and approve your patch, though. > +static int > +wincrypt_gatherer( void (*add)(const void*, size_t, int), int requester ) > +{ > + > + /* The buffer to store the random bytes in. For extra safety, this is > + * memset()'ed to NULL after each use. */ > + static unsigned char rand_bytes[ 32 ]; > + > + if (!hCryptProvider) > + return 0; > + > + /* Now that we have a crypto context, we request a block of > + * cryptographically random bytes, and call the add function with it. */ > + if( CryptGenRandom( hCryptProvider, sizeof( rand_bytes ), rand_bytes ) ) { > + (*add) ( rand_bytes, sizeof( rand_bytes ), requester ); > + } else { > + if ( debug_me ) > + log_debug( "CryptGenRandom failed: %d", GetLastError() ); > + return 0; > + } > + > + /* These random bytes might be used as key material, so we want to clear > + * them now. */ > + memset(rand_bytes, 0, sizeof(rand_bytes)); > + return 1; > +} You only ever read 32 bytes of randomness, that is not sufficient. Take a look at _gcry_rndw32_gather_random(), it receives a length parameter. That is how many bytes you should be reading. Compare with how rndlinux.c is looping until it has read that many random bytes. Generally, rndlinux.c seem to be doing things in the (relatively) best way, so it is worth looking at. > +BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved ) { Is it necessary to use a DllMain function for this? What if the library is linked statically? /Simon From wk at gnupg.org Thu Feb 1 09:27:08 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2007 09:27:08 +0100 Subject: [gnutls-dev] [PATCH] Fix slow startup under Windows In-Reply-To: <87r6ta716i.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu\, 01 Feb 2007 09\:05\:25 +0100") References: <45C0DD79.9000206@wireshark.org> <87r6ta716i.fsf@latte.josefsson.org> Message-ID: <87ejpa471f.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2007 09:05, simon at josefsson.org said: > Thanks. Ultimately, the patch will have to be reviewed and installed > by the libgcrypt people, but I took a quick look. I may end up > installing a patch for gnutls4win before it has been applied to > libgcrypt, but only if I think it looks good. I'd wish that you could > get Werner to look at and approve your patch, though. The problem with this patch is that it uses the W32 crypto API. We have never made efforts to use and thus I would need to have a look at it. What we should do is to compare rndw32.c with the latest version of Peter Gutmann's cryptlib. rndw32.c is heavily based upon it. >> + /* These random bytes might be used as key material, so we want to clear >> + * them now. */ >> + memset(rand_bytes, 0, sizeof(rand_bytes)); That is pointless. We are using the same code for many years in GnuPG for Windows and we never got any complaints about a slow startup. In fact the Windows entropy ghatherer is much faster than the Unix one and that actually scares me a little bit. I guess it is more a problem on how you use libgcrypt. For example, if you are not running a long living process, you should save the current state of libgcrypt's random pool so that at the next startup it does not need to refill completey with fresh entropy. Salam-Shalom, Werner From simon at josefsson.org Thu Feb 1 11:43:24 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 01 Feb 2007 11:43:24 +0100 Subject: [gnutls-dev] OpenCDK 0.5.13 Message-ID: <87abzy6tv7.fsf@latte.josefsson.org> The OpenCDK library implement basic parts of the OpenPGP message format. The aim of the library is *not* to replace any available OpenPGP version. There will be no support for key management (sign, revoke, alter preferences, ...) and some other parts are only rudimentary available. The main purpose is to handle and understand OpenPGP packets and to use basic operations. For example, encrypt/decrypt, sign/verify and packet parsing routines. The library is used by GnuTLS for OpenPGP support. Noteworthy changes in version 0.5.13 (2007-02-01) ------------------------------------------------ * Fixed shared library for newly added APIs in last release. * Add -no-undefined to LDFLAGS, to make opencdk build under mingw32. * Add AC_LIBTOOL_WIN32_DLL to configure.ac, which is required for * libtool to behave correctly for cross-compiles to mingw32. * Use gnulib for mingw32 support. Noteworthy changes in version 0.5.12 (2007-02-01) ------------------------------------------------ * Add new API to extract public/secret OpenPGP key to S-expr. The functions are cdk_pubkey_to_sexp and cdk_seckey_to_sexp. Patch by Mario Lenz . * Autoconf 2.60 and automake 1.10 are now required. * Doc fixes. Commercial support contracts for OpenCDK are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding OpenCDK maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use OpenCDK, or want to help others, you are invited to join our help-gnutls mailing list, see: . Here are the compressed sources (588KB): http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.13.tar.gz ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.13.tar.gz Here are GPG detached signatures using key 0xB565716F: http://josefsson.org/gnutls/releases/opencdk/opencdk-0.5.13.tar.gz.sig ftp://ftp.gnutls.org/pub/gnutls/opencdk/opencdk-0.5.13.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2007-02-15] uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15] sub 1024R/09CC4670 2006-03-18 [expires: 2007-04-22] sub 1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22] sub 1024R/A14C401A 2006-03-18 [expires: 2007-04-22] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: bff9daabfe8f20824e4d167a9dc11e0908f11370 opencdk-0.5.13.tar.gz 83f37a0551027849ec9905262334525cccb201cf opencdk-0.5.13.tar.gz.sig 2a790fc3175f6c6fe1e7d4616eef1ca3f8cb7966eeffba4c12fdad94 opencdk-0.5.13.tar.gz 7ac5ac3583f7fd88b65cc42a18cc2736dca6d08a0438fa839e06f0e4 opencdk-0.5.13.tar.gz.sig Enjoy, Timo, Nikos, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Thu Feb 1 16:42:25 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 01 Feb 2007 16:42:25 +0100 Subject: [gnutls-dev] GnuTLS 1.7.3 Message-ID: <871wl97ula.fsf@latte.josefsson.org> This is mostly to get support for Proxy Certificates (RFC 3820) released. Remember, the GnuTLS 1.7.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. * Version 1.7.3 (released 2007-02-01) ** New option to certtool: --generate-proxy. This will generate a Proxy Certificate from an end entity certificate. Proxy Certificates are documented in RFC 3820. You will need to specify the proxy certificate's private key with --load-privkey, the user certificate with --load-certificate and the private key used to sign the new proxy certificate with --load-ca-privkey. Certtool will query for proxy path length and the policy language OID. Currently only OIDs that have an empty policy are supported (which includes the two OIDs defined by RFC 3820). ** Certtool --certificate-info now prints information for Proxy Certificates. Before the proxy extension was just printed as DER encoded data. ** New APIs to set proxy subject names and get/set proxy cert extension. ** Fix parsing of pathLenConstraints in BasicConstraints with missing cA. ** Added self-test to test for regressions of pathLenConstraint bug. Incidentally, this also test (some) other regressions or changes in the output from certtool --certificate-info. ** When certtool generates CA certificates, pressing enter on the path ** length constraint query will now remove the field. Before it set the path length constraint to 0, which is a rather poor default. ** Certtool now print times in UTC when printing certificate/CRL info. ** Add better fix to work around C++ compiler bug on Mac OS X. Reported and tiny patch provided by Matthias Scheler . ** Fix import of ASCII armored OpenPGP keys. Patch by ludovic.courtes at laas.fr (Ludovic Court?s). ** API and ABI modifications: gnutls_x509_crt_set_proxy_dn: ADD. gnutls_x509_crt_set_proxy: ADD. gnutls_x509_crt_get_proxy: ADD. Here are the compressed sources (4.1MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.3.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.3.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.3.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.3.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: c16cd860fb07d2c431bf9d160fe71c3afb18d46a gnutls-1.7.3.tar.bz2 82e2ee965d6add0daab99ce895d18a697999ce5a gnutls-1.7.3.tar.bz2.sig c2d8b2fa000d0f108a63ad8bbe060f960002d22387d6c72da5cc681a gnutls-1.7.3.tar.bz2 1645e5fefef93102c5e13a7c5e2a2e58c37a9dab489124875a2d35c7 gnutls-1.7.3.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Thu Feb 1 16:55:39 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 01 Feb 2007 16:55:39 +0100 Subject: [gnutls-dev] GnuTLS 1.7.3 for Windows Message-ID: <87wt316fes.fsf@latte.josefsson.org> I built a Windows installer for GnuTLS 1.7.3, you can find it at: http://josefsson.org/gnutls4win/ There has been some changes in the installer: It includes a standalone OpenCDK library too. It names the registry keys as "GnuTLS-$version" (instead of "GnuTLS"), so you can have multiple GnuTLS releases (e.g., 1.6.1 and 1.7.3) installed at the same time, and have Add/Remove program be able to remove both versions correctly. Before the registry keys would be overwritten by every new release, so 'Remove program' only removed the last installed version. /Simon From rks at mur.at Thu Feb 1 18:55:51 2007 From: rks at mur.at (Rupert Kittinger-Sereinig) Date: Thu, 01 Feb 2007 18:55:51 +0100 Subject: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd) In-Reply-To: <8764an77ui.fsf@latte.josefsson.org> References: <20070125071725.GB2880@colwyn.zhadum.org.uk> <87y7nrv4al.fsf@latte.josefsson.org> <87ps93v3uy.fsf@latte.josefsson.org> <45BA6DCD.8090907@mur.at> <8764an77ui.fsf@latte.josefsson.org> Message-ID: <45C229A7.3050700@mur.at> >> I looked up the mail that reported the error, and it seems that the >> compiler fails to create an instance of the set_ptr() member function >> in the object file. In this case, I would try to uninline set_ptr(). >> This can hardly be a performance problem and should fix the linker error :-) > > I'd really appreciate your help here. What would your recommendation > be, more specifically? The old code is the one which is used when the > newly added #if's are not chosen. I've seen other bug reports too, > such as this failure: > >>> verify-elf: ERROR: ./usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: >>> _ZN6gnutls11credentials7set_ptrEPv > > But that may actually be the same, I don't know... > > /Simon Hi Simon, to make sense of the above error message, you need to feed it through c++filt, so we get /usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: gnutls::credentials::set_ptr(void*) So, gnutls::credentials::set_ptr(void*) is missing from the library. The reason is almost certainly that the functions was declared inline. (Note that all functions defined in a class declaration are implicitely inline...). Now if some client code calls this function, but the compiler fails to inline the function, the linker will complain. I have seen this happen with some older version of g++ (but I do not remember which...) if optimization is not turned on. To have everything inlined, at least -O0 had to be present. Also, there is a g++ option -fkeep-inline-functions that should probably be enabled whenever compiling a library. I have no access to a Mac, so I cannot check my conclusions, but if they are correct, I see two ways to fix this: 1) use compiler options. Will probably lead to a maintainance nightmare sooner or later. 2) do not use inline functions in the library API. This is what C++ gurus recommend anyway ("never use inline functions unless profiling shows that it is actually useful"). In the case of gnutls, the cost of a few functions calls is probably irrelevant compared with the cost of the cryptographic algoritms, so this probably the better solution. I will try to provide a patch, but this will take some time. Also, some Mac users will need to test it for me. Rupert -- Rupert Kittinger-Sereinig Krenngasse 32 A-8010 Graz Austria From simon at josefsson.org Sun Feb 4 12:59:05 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 04 Feb 2007 12:59:05 +0100 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <200702021806.15123.thresh@immo.ru> (Pavlov Konstantin's message of "Fri\, 2 Feb 2007 18\:06\:15 +0300") References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> Message-ID: <873b5myvzq.fsf@latte.josefsson.org> I'm copying the list on this, since I'd appreciate wider discussion. Pavlov Konstantin writes: > Another problem i recognized is the lack of real symbol versioning in > libgnutls: > GNUTLS_1_3 > { > global: _gnutls*; gnutls*; _E_*; > local: *; > }; > > I made a new .version file for 1.6.1 release, it looks like : > GNUTLS_1_3 > { > global: _gnutls*; gnutls*; _E_*; > }; > > GNUTLS_1_6_1 { > global: > gnutls_transport_set_errno; > gnutls_transport_set_global_errno; > local: *; > }; > > > What do you think about it ? I've re-read the relevant parts of Drepper's DSO howto to refresh my memory on this, but still, I don't see what problem the above change would fix. Could you explain? The only problem that I can think of that the above would solve if is an application that uses e.g. gnutls_transport_set_errno was built against 1.6.x or later is moved to a system which has an older libgnutls installed that doesn't have that symbol. The application will not work. We can't protect against that, though, as far as I can see. If an application uses a new interface, he must make sure a library that implements that interface is available. Thus, my conclusion would be that, generally, adding new interface doesn't require changes to the version script. If we ever _change_ an ABI, rather than adding new ones, we definitely need to use versioning on that symbol. Then old applications get the old behaviour and new applications get the new behaviour. But I'm trying to avoid changing ABIs because it is complex and confusing to document and think about that situation. All this said, I'm not an expert on DSO versioning, so I'd appreciate comments on the reasoning in this post. Thanks, Simon From ametzler at downhill.at.eu.org Sun Feb 4 17:42:02 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 4 Feb 2007 17:42:02 +0100 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <873b5myvzq.fsf@latte.josefsson.org> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> Message-ID: <20070204164202.GD3791@downhill.g.la> On 2007-02-04 Simon Josefsson wrote: > I'm copying the list on this, since I'd appreciate wider discussion. [...] > I've re-read the relevant parts of Drepper's DSO howto to refresh my > memory on this, but still, I don't see what problem the above change > would fix. [...] FWIW this (and the other stuff you wrote) matches my understanding of symbol versioning. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From jw+debian at jameswestby.net Sun Feb 4 22:04:57 2007 From: jw+debian at jameswestby.net (James Westby) Date: Sun, 4 Feb 2007 21:04:57 +0000 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <871wm4tz9v.fsf@latte.josefsson.org> References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> <871wm4tz9v.fsf@latte.josefsson.org> Message-ID: <20070204210457.GE3684@jameswestby.net> On (09/01/07 08:50), Simon Josefsson wrote: > James Westby writes: > > As for debugging the actual data on the wire I'm not sure of the best > > approach for doing this. > > Using wireshark and comparing between two sessions, one that work, and > one that doesn't, and look for differences, is the only I can think > of... there are some TLS dump tools around, but none as versatile as > wireshark + RFC + pen&paper. > I have sat down tonight and gone through two packet captures that Marc provided me with. One is the failing one, the other obtained by disallowing SHA. The only difference that I can see is in the cipher suite negotiated, which is purely the server's decision. Everything that was going on seemed to tie in OK with the RFC as well. It seems that the client doesn't fall back to SSL v3, I don't know where I got that from. Both of the sequences use TLS1.0 all the way through. This only leaves the encrypted bits to check. Do you know of anyway to do this? Apparently wireshark can do some of it if you give it the server's private key. Marc would it be possible for you to generate a testing key and certificate and provide them to me along with a trace of the session when using them? Thanks, James -- James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 From simon at josefsson.org Mon Feb 5 10:26:46 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 05 Feb 2007 10:26:46 +0100 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <20070204210457.GE3684@jameswestby.net> (James Westby's message of "Sun\, 4 Feb 2007 21\:04\:57 +0000") References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> <871wm4tz9v.fsf@latte.josefsson.org> <20070204210457.GE3684@jameswestby.net> Message-ID: <87d54px8dl.fsf@latte.josefsson.org> James Westby writes: > On (09/01/07 08:50), Simon Josefsson wrote: >> James Westby writes: >> > As for debugging the actual data on the wire I'm not sure of the best >> > approach for doing this. >> >> Using wireshark and comparing between two sessions, one that work, and >> one that doesn't, and look for differences, is the only I can think >> of... there are some TLS dump tools around, but none as versatile as >> wireshark + RFC + pen&paper. >> > > I have sat down tonight and gone through two packet captures that Marc > provided me with. One is the failing one, the other obtained by > disallowing SHA. The only difference that I can see is in the cipher > suite negotiated, which is purely the server's decision. Everything that > was going on seemed to tie in OK with the RFC as well. > > It seems that the client doesn't fall back to SSL v3, I don't know where > I got that from. Both of the sequences use TLS1.0 all the way through. Thanks for doing that! Is it easy for administrators to disable SHA with the application that was used here (exim IIRC)? Perhaps a work-around would be configuration options to disable SHA-1 for particular IP's, or an option to attempt a to re-handshake a failed handshake without SHA-1. Of course, none of it should be the default, but options would allow administrators to relax the defaults to make things work with this client. > This only leaves the encrypted bits to check. Do you know of anyway to > do this? Apparently wireshark can do some of it if you give it the > server's private key. Marc would it be possible for you to generate a > testing key and certificate and provide them to me along with a trace of > the session when using them? Yup, as far as I know, wireshark should be able to decrypt everything. Looking at that output for both failed and successful sessions would be good. Comparing with a successful OpenSSL handshake would be best. IIRC, OpenSSL could negotiate successfully with SHA-1? Then there must be some kind of difference in what is sent over the wire. Btw, it might be better to compare against the OpenSSL dump rather than comparing against the RFC. Following the RFC isn't guaranteed to work against the client, but if OpenSSL works against the client, it is doing something that the client likes. We could mimic that behaviour if we know what it is. /Simon From simon at josefsson.org Mon Feb 5 14:12:01 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 05 Feb 2007 14:12:01 +0100 Subject: [gnutls-dev] GnuTLS 1.7.4 Message-ID: <87odo8wxy6.fsf@latte.josefsson.org> Support for RSA-SHA256/384/512. Remember, the GnuTLS 1.7.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. * Version 1.7.4 (released 2007-02-05) ** Support for RSA signing using SHA-256/384/512. A new self test "sha2" tries to build a long X.509 certificate chain testing all new hashes. ** The gnutls-serv tool now use static DH parameters if none are supplied. ** Discuss proxy certificates in the manual. ** Improve bibliographical citations in the manual. ** Update of gnulib files. ** Fix certtool template handling of pathLenConstraints. It now defaults to -1 instead of 0, which causes the field to be missing unless the template specify it. ** API and ABI modifications: GNUTLS_MAC_SHA256, GNUTLS_MAC_SHA384, GNUTLS_MAC_SHA512: New gnutls_mac_algorithm_t values. GNUTLS_DIG_SHA256, GNUTLS_DIG_SHA384, GNUTLS_DIG_SHA512: New gnutls_digest_algorithm_t values. GNUTLS_SIGN_RSA_SHA256, GNUTLS_SIGN_RSA_SHA384, GNUTLS_SIGN_RSA_SHA512: New gnutls_sign_algorithm_t values. Here are the compressed sources (4.1MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.4.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.4.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.4.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.4.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: f0113ef08dea9679819768eab86e0dfb168f4086 gnutls-1.7.4.tar.bz2 d962751c4a25f0937b90a725b029dd8276618b2d gnutls-1.7.4.tar.bz2.sig d1373bb6dc2bdb74c38c9f56db0aaac48f763bacc8c0c65fe154773c gnutls-1.7.4.tar.bz2 85583a1d1b07daf4b1abbeebe9680a8525fabd480f24a92145f009ed gnutls-1.7.4.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From jw+debian at jameswestby.net Mon Feb 5 22:06:12 2007 From: jw+debian at jameswestby.net (James Westby) Date: Mon, 5 Feb 2007 21:06:12 +0000 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <87d54px8dl.fsf@latte.josefsson.org> References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> <871wm4tz9v.fsf@latte.josefsson.org> <20070204210457.GE3684@jameswestby.net> <87d54px8dl.fsf@latte.josefsson.org> Message-ID: <20070205210607.GJ3684@jameswestby.net> On (05/02/07 10:26), Simon Josefsson wrote: > James Westby writes: > > This only leaves the encrypted bits to check. Do you know of anyway to > > do this? Apparently wireshark can do some of it if you give it the > > server's private key. Marc would it be possible for you to generate a > > testing key and certificate and provide them to me along with a trace of > > the session when using them? > > Yup, as far as I know, wireshark should be able to decrypt everything. > Looking at that output for both failed and successful sessions would > be good. Yes, it decrypts everything (it gives an extra tab at the bottom with the decrypted values in). I'm not sure that it actually verifies the message contents. Specifically the server finished meesage that is prime suspect includes a hash based on previous messages (not sure that I need to tell you that of all people.) It's behaviour for say failed checksums in TCP packets is to highlight that, so maybe it would do it here as well, though it uses a different part of the screen. (Note to anyone else who wants to try this specify the key in the wireshark properties as ip,port,protocol,/path/to/key not with ip:port:/path/to/key as some places claim.) I'm not entirely sure that I have given the protocol correctly, so maybe that will make a difference. I have the source here, so I will try and see if it makes any attempts to verify stuff. Also I'm going to see if I can find the bits in the openssl source that do this and use them to check the dump. Failing that I might have to resort to coding up something myself, but hopefully it wont come to that. Simon, can I ask when you would be satisfied that GnuTLS is behaving correctly? Would calculations of all values do it? Anything more or less? > Comparing with a successful OpenSSL handshake would be best. > IIRC, OpenSSL could negotiate successfully with SHA-1? Then there > must be some kind of difference in what is sent over the wire. Marc has also provided me with a dump of an OpenSSL transaction. the differences that I saw with a quick look was that the client certificate wasn't requested, and that the 256 variant of TLS_RSA_AES_CBC_SHA was picked by the server. The first can be done with the -verify option to s_server, the second can be done with the -ciphers option, somehow, but it is not clear what the format of this option is. In a private exchange with Marc he is helping me to get the traces as similar as possible. > > Btw, it might be better to compare against the OpenSSL dump rather > than comparing against the RFC. Following the RFC isn't guaranteed to > work against the client, but if OpenSSL works against the client, it > is doing something that the client likes. We could mimic that > behaviour if we know what it is. That sounds fair. If I can see a difference then I will try and pinpoint it to allow you to decide what to do. Thanks, James -- James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 From simon at josefsson.org Tue Feb 6 08:19:01 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 06 Feb 2007 08:19:01 +0100 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <20070205210607.GJ3684@jameswestby.net> (James Westby's message of "Mon\, 5 Feb 2007 21\:06\:12 +0000") References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> <871wm4tz9v.fsf@latte.josefsson.org> <20070204210457.GE3684@jameswestby.net> <87d54px8dl.fsf@latte.josefsson.org> <20070205210607.GJ3684@jameswestby.net> Message-ID: <87hctzg3dm.fsf@latte.josefsson.org> James Westby writes: > Simon, can I ask when you would be satisfied that GnuTLS is behaving > correctly? Would calculations of all values do it? Anything more or less? Until someone proves me wrong, I assume that the GnuTLS behaviour is correct. It seems better to try to disprove that assumption, by finding some flaw. If OpenSSL works and GnuTLS doesn't, there reasonably must be _some_ kind of difference. It might be that the behaviour is permitted by the standard, and the phone doesn't handle that correctly, but then at least we know what to document. And let Nokia know about it. Maybe we could even make that behaviour in GnuTLS configurable. >> Comparing with a successful OpenSSL handshake would be best. >> IIRC, OpenSSL could negotiate successfully with SHA-1? Then there >> must be some kind of difference in what is sent over the wire. > > Marc has also provided me with a dump of an OpenSSL transaction. the > differences that I saw with a quick look was that the client certificate > wasn't requested, and that the 256 variant of TLS_RSA_AES_CBC_SHA was > picked by the server. The first can be done with the -verify option to > s_server, the second can be done with the -ciphers option, somehow, but > it is not clear what the format of this option is. In a private exchange > with Marc he is helping me to get the traces as similar as possible. Oh! A client certificate request could easily bug out a poorly written TLS implementation. See if you can make OpenSSL request a client certificate as well. Getting both programs to send exactly the same parameters is important. Otherwise it will be difficult to track down exactly what change is causing the problem. >> Btw, it might be better to compare against the OpenSSL dump rather >> than comparing against the RFC. Following the RFC isn't guaranteed to >> work against the client, but if OpenSSL works against the client, it >> is doing something that the client likes. We could mimic that >> behaviour if we know what it is. > > That sounds fair. If I can see a difference then I will try and pinpoint > it to allow you to decide what to do. Yes, I think that is the best approach. The goal here seems to be interoperability, not standards-compliance, after all. Good luck, Simon From jw+debian at jameswestby.net Tue Feb 6 08:31:59 2007 From: jw+debian at jameswestby.net (James Westby) Date: Tue, 6 Feb 2007 07:31:59 +0000 Subject: [gnutls-dev] [Pkg-gnutls-maint] Re: Possible bug in GnuTLS AES/SHA1 In-Reply-To: <87hctzg3dm.fsf@latte.josefsson.org> References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> <871wm4tz9v.fsf@latte.josefsson.org> <20070204210457.GE3684@jameswestby.net> <87d54px8dl.fsf@latte.josefsson.org> <20070205210607.GJ3684@jameswestby.net> <87hctzg3dm.fsf@latte.josefsson.org> Message-ID: <20070206073159.GC28297@jameswestby.net> On (06/02/07 08:19), Simon Josefsson wrote: > Until someone proves me wrong, I assume that the GnuTLS behaviour is > correct. It seems better to try to disprove that assumption, by > finding some flaw. If OpenSSL works and GnuTLS doesn't, there > reasonably must be _some_ kind of difference. It might be that the > behaviour is permitted by the standard, and the phone doesn't handle > that correctly, but then at least we know what to document. And let > Nokia know about it. Maybe we could even make that behaviour in > GnuTLS configurable. That sounds reasonable. I will try and get you a proof if there is one. > James Westby writes: > > Marc has also provided me with a dump of an OpenSSL transaction. the > > differences that I saw with a quick look was that the client certificate > > wasn't requested, and that the 256 variant of TLS_RSA_AES_CBC_SHA was > > picked by the server. The first can be done with the -verify option to > > s_server, the second can be done with the -ciphers option, somehow, but > > it is not clear what the format of this option is. In a private exchange > > with Marc he is helping me to get the traces as similar as possible. > > Oh! A client certificate request could easily bug out a poorly > written TLS implementation. See if you can make OpenSSL request a > client certificate as well. > > Getting both programs to send exactly the same parameters is > important. Otherwise it will be difficult to track down exactly what > change is causing the problem. Yes, I realise this. Last night I sent Marc the correct parameters to get OpenSSL s_server to request a client certificate and to select the same cipher suite. At least I hope they were correct this time. When I get the dump of that session from Marc I will look for any differences in the configuration, and if I can't see any I'll start looking for problems in the numbers. I have found the code in OpenSSL that calculates the finished message, so I think I should be able to use that. The hard part after that is to work out how do the hashes, and to get the data to go in them. I am assuming that the handshake messages that must be hashed refers to the data that the SSL library sent over the wire, excluding the headers like type of packet, version and length. Or does it include those? I don't imagine that it is the whole packets with TCP/IP headers etc. Thanks, James -- James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 From simon at josefsson.org Tue Feb 6 09:27:05 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 06 Feb 2007 09:27:05 +0100 Subject: [gnutls-dev] [Pkg-gnutls-maint] Re: Possible bug in GnuTLS AES/SHA1 In-Reply-To: <20070206073159.GC28297@jameswestby.net> (James Westby's message of "Tue\, 6 Feb 2007 07\:31\:59 +0000") References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> <871wm4tz9v.fsf@latte.josefsson.org> <20070204210457.GE3684@jameswestby.net> <87d54px8dl.fsf@latte.josefsson.org> <20070205210607.GJ3684@jameswestby.net> <87hctzg3dm.fsf@latte.josefsson.org> <20070206073159.GC28297@jameswestby.net> Message-ID: <871wl3g086.fsf@latte.josefsson.org> James Westby writes: > Yes, I realise this. Last night I sent Marc the correct parameters to > get OpenSSL s_server to request a client certificate and to select the > same cipher suite. At least I hope they were correct this time. > > When I get the dump of that session from Marc I will look for any > differences in the configuration, and if I can't see any I'll start > looking for problems in the numbers. Great, I think that is the best approach. > I have found the code in OpenSSL that calculates the finished message, > so I think I should be able to use that. The hard part after that is to > work out how do the hashes, and to get the data to go in them. > > I am assuming that the handshake messages that must be hashed refers to > the data that the SSL library sent over the wire, excluding the headers > like type of packet, version and length. Or does it include those? I > don't imagine that it is the whole packets with TCP/IP headers etc. RFC 4346 says: verify_data PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; ... handshake_messages All of the data from all messages in this handshake (not including any HelloRequest messages) up to but not including this message. This is only data visible at the handshake layer and does not include record layer headers. This is the concatenation of all the Handshake structures, as defined in 7.4, exchanged thus far. So, yes, it will be tedious to compute which data goes into the hash. Easiest to start by printing the input to the hash function and comparing it against a wireshark dump. However, if there is a problem in the finished message, I think we should have much more serious problems. I wouldn't spend too much time on the finished message theory, especially when you can find easier differences to debug first -- things like the missing/present certificate request messages are IMHO more likely to cause a problem like this. /Simon From simon at josefsson.org Tue Feb 6 17:52:09 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 06 Feb 2007 17:52:09 +0100 Subject: [gnutls-dev] GnuTLS 1.7.5 Message-ID: <87lkjbdy9y.fsf@latte.josefsson.org> This release contains improvements that allow us to run an online test server using "gnutls-serv" more easily. I have one up and running now, with support for TLS 1.2, X.509, OpenPGP, SRP and PSK, see . Remember, the GnuTLS 1.7.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. * Version 1.7.5 (released 2007-02-06) ** Servers won't negotiate SRP RSA/DSS cipher suites if no SRP credential ** is set. ** Default behaviour for the gnutls-cli and gnutls-serv tools improved. ** Fix --list output for gnutls-cli and gnutls-serv. Mention TLS1.2, SHA512 etc. ** Manual contains new section on setting up a test HTTP server. A server set up following those descriptions are available online via . ** Update of gnulib files. ** API and ABI modifications: No changes since last version. Here are the compressed sources (4.1MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.5.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.5.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.5.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.5.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: 87119b60efd3b76078b11cbe0448d94899477bae gnutls-1.7.5.tar.bz2 6e7f7a9666f1e868c96a91ca38d60d28e8b392ac gnutls-1.7.5.tar.bz2.sig cc10e7b96615ddc8e60d81d79f716769ab012246e7d80bfc97871309 gnutls-1.7.5.tar.bz2 8fa6e76f94c0425820605328aa3cbcc98d357237f099fa5e4d601015 gnutls-1.7.5.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Mon Feb 12 16:06:26 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 12 Feb 2007 16:06:26 +0100 Subject: [gnutls-dev] GnuTLS 1.7.6 Message-ID: <877iunv2j1.fsf@latte.josefsson.org> Various fixes, see below. Remember, the GnuTLS 1.7.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. * Version 1.7.6 (released 2007-02-12) ** Support for 'otherName' Subject Alternative Names. The existing API gnutls_x509_crt_get_subject_alt_name may now return the new type GNUTLS_SAN_OTHERNAME together with the otherName value. To find out the otherName OID (necessary for proper parsing of the value), use the new API gnutls_x509_crt_get_subject_alt_othername_oid. For known OIDs, gnutls_x509_crt_get_subject_alt_othername_oid will return "virtual" SAN values, e.g., GNUTLS_SAN_OTHERNAME_XMPP to simplify OID matching. Suggested by Matthias Wimmer . ** Certtool can print otherName SAN values for certificates. For known otherName OIDs (currently only id-on-xmppAddr as defined by RFC 3920), it will also print the name. ** Fix TLS 1.2 RSA signing in servers. Before it used the old-style MD5+SHA1 signature, but the TLS signatures should be normal PKCS#1 signatures. FYI, we use and require that DigestInfo parameters are present and NULL for TLS 1.2. ** Add APIs to access X.509 extensions sequentially. The existing APIs gnutls_x509_crt_get_extension_oid() and gnutls_x509_crt_get_extension_by_oid() does not permit callers to inspect the extensions in the order defined by the certificate. ** Add API to extract signature value from X.509 certificates. The function is gnutls_x509_crt_get_signature. ** Fix crash when generating proxy certificates in batch mode. If you don't specify a proxy policy in batch mode, it will use id-ppl-inheritALL. ** Add API to print information about X.509 certificates. The function is gnutls_x509_crt_print. ** Certtool uses the new API gnutls_x509_crt_print to print certificate info. One consequence of this is that the output syntax has changed slightly. Some more fields are printed. ** Doc fixes. ** API and ABI modifications: gnutls_x509_crt_print: ADD gnutls_certificate_print_formats_t: ADD, new enum. gnutls_x509_crt_get_signature: ADD. gnutls_x509_crt_get_extension_data: ADD. gnutls_x509_crt_get_extension_info: ADD. gnutls_x509_crt_get_subject_alt_othername_oid: ADD. GNUTLS_SAN_OTHERNAME: ADD, new gnutls_x509_subject_alt_name_t element. GNUTLS_SAN_OTHERNAME_XMPP: ADD, new gnutls_x509_subject_alt_name_t element. Here are the compressed sources (4.2MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.6.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.6.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.6.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.6.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: 7d3c3342a749cbd996007f8f6f6140ea61ea0ee9 gnutls-1.7.6.tar.bz2 b0a3907ede3eefa3e6a29e12f08bbfbb1fdf4c33 gnutls-1.7.6.tar.bz2.sig fa885612040b34f62728db5a4fcd8203e24c8ceb625c8ed35bb40ff9 gnutls-1.7.6.tar.bz2 cadd2db39cbe7dbcd8fd8953211bb8e6ba84feb9b94e98ca1ad86c5c gnutls-1.7.6.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From edu at eduardovillanueva.es Tue Feb 13 03:23:09 2007 From: edu at eduardovillanueva.es (Eduardo Villanueva Che) Date: Tue, 13 Feb 2007 03:23:09 +0100 Subject: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd) Message-ID: <1171333389.32003.98.camel@hecate.veloxia.com> > From: Rupert Kittinger-Sereinig mur.at> > Subject: Re: Building GnuTLS 1.6.1 under Mac OS X (fwd) > Newsgroups: gmane.comp.encryption.gpg.gnutls.devel > Date: 2007-02-01 17:55:51 GMT (1 week, 4 days, 3 hours and 17 minutes > ago) > > >> I looked up the mail that reported the error, and it seems that the > >> compiler fails to create an instance of the set_ptr() member function > >> in the object file. In this case, I would try to uninline set_ptr(). > >> This can hardly be a performance problem and should fix the linker error :-) > > > > I'd really appreciate your help here. What would your recommendation > > be, more specifically? The old code is the one which is used when the > > newly added #if's are not chosen. I've seen other bug reports too, > > such as this failure: > > > >>> verify-elf: ERROR: ./usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: > >>> _ZN6gnutls11credentials7set_ptrEPv > > > > But that may actually be the same, I don't know... > > > > /Simon > > Hi Simon, Hi all, I have the same problem with Linux, but the bug is platform independent, it's a C++ issue. > to make sense of the above error message, you need to feed it through > c++filt, so we get > > /usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: > gnutls::credentials::set_ptr(void*) > > So, gnutls::credentials::set_ptr(void*) is missing from the library. > > The reason is almost certainly that the functions was declared inline. No, it's missing because it was declared as pure virtual. Apparently there are no problem with this, because it was defined in each derived class. That's OK, but it has one limitation: A virtual function MUST NOT be called inside constructors or destructors, because such calls will never go to a more derived class than the caller class. At this point, the derived class wasn't constructed yet (in the constructor), or it was destroyed (in the destructor). When a virtual function is called inside the constructor/destructor, the compiler ALWAYS uses the base class implementation, but here the base class function was declared as pure virtual, so it was undefined. But this isn't the only problem, at the moment the C++ API is very dangerous, the copy operators/constructors must be explicitly coded or disabled. The exception class must be specialized too. This patches (see attached files), fixes the virtual function bug at credentials. I added a noncopyable base class, and all classes with dangerous copy operator/constructor derive now from it. This is a quick fix, until they will be coded correctly. I ported the "ex-client2.c" to C++, using the C++ API, and I will try to port all the examples tomorrow, and I'll test the API more. I'm interested in the C++ API, and I offer my help to improve it. Eduardo Villanueva Che. -------------- next part -------------- A non-text attachment was scrubbed... Name: exx-client2.cpp Type: text/x-c++src Size: 2354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutlsxx.cpp.patch Type: text/x-patch Size: 19349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutlsxx.h.patch Type: text/x-patch Size: 2054 bytes Desc: not available URL: From thresh at altlinux.ru Wed Feb 14 22:47:05 2007 From: thresh at altlinux.ru (Pavlov Konstantin) Date: Thu, 15 Feb 2007 00:47:05 +0300 Subject: [gnutls-dev] pkg-config file for libgnutls Message-ID: <20070214214705.GA21490@cryo.net.ru> Hello everyone. I noticed that my libgnutls-devel package doesn't depend on libtasn1-devel one. Looks like this is due to that line in .pc file: Libs.private: -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error Shouldnt it be Libs: -L${libdir} @LIBGNUTLS_LIBS@ instead? Without libtasn1-devel installed, macro AM_PATH_LIBGNUTLS doesnt work. From ldv at altlinux.org Thu Feb 15 00:44:14 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Thu, 15 Feb 2007 02:44:14 +0300 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <873b5myvzq.fsf@latte.josefsson.org> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> Message-ID: <20070214234414.GA23619@nomad.office.altlinux.org> Hi, On Sun, Feb 04, 2007 at 12:59:05PM +0100, Simon Josefsson wrote: > I'm copying the list on this, since I'd appreciate wider discussion. > > Pavlov Konstantin writes: > > > Another problem i recognized is the lack of real symbol versioning in > > libgnutls: > > GNUTLS_1_3 > > { > > global: _gnutls*; gnutls*; _E_*; > > local: *; > > }; > > > > I made a new .version file for 1.6.1 release, it looks like : > > GNUTLS_1_3 > > { > > global: _gnutls*; gnutls*; _E_*; > > }; > > > > GNUTLS_1_6_1 { > > global: > > gnutls_transport_set_errno; > > gnutls_transport_set_global_errno; > > local: *; > > }; > > > > > > What do you think about it ? > > I've re-read the relevant parts of Drepper's DSO howto to refresh my > memory on this, but still, I don't see what problem the above change > would fix. Could you explain? > > The only problem that I can think of that the above would solve if is > an application that uses e.g. gnutls_transport_set_errno was built > against 1.6.x or later is moved to a system which has an older > libgnutls installed that doesn't have that symbol. The application > will not work. Yes. Imagine large binary package repository (e.g. Debian or Sisyphus). Maintainer builds new software which uses new symbols from gnutls. When user installs package with this new software, there are no indication that it requires new version of gnutls, so old version of gnutls may remain unupgraded. As result, user will see runtime relocation error which is not what maintainer usually want. To resolve this issue, our gnutls package maintainer had to create new interface, e.g. GNUTLS_1_6_1 and place new symbols there. As result, every package with software which uses these symbols will automatically have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1), so any user installing this package will also update gnutls package. > We can't protect against that, though, as far as I can see. If an > application uses a new interface, he must make sure a library that > implements that interface is available. Just otherwise, library should provide new symbols via new interface, so an application which uses new symbols will get necessary dependencies. > Thus, my conclusion would be that, generally, adding new interface > doesn't require changes to the version script. If new version of a library exports new symbols, it should add new interface explicitly, using version script or any other available method. As I see, gnutls uses version script for this purposes. > All this said, I'm not an expert on DSO versioning, so I'd appreciate > comments on the reasoning in this post. No problem. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon at josefsson.org Thu Feb 15 12:01:13 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 15 Feb 2007 12:01:13 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070214214705.GA21490@cryo.net.ru> (Pavlov Konstantin's message of "Thu\, 15 Feb 2007 00\:47\:05 +0300") References: <20070214214705.GA21490@cryo.net.ru> Message-ID: <87odnv65xi.fsf@latte.josefsson.org> Pavlov Konstantin writes: > Hello everyone. > > I noticed that my libgnutls-devel package doesn't depend on libtasn1-devel > one. > > Looks like this is due to that line in .pc file: > > Libs.private: -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error > > Shouldnt it be Libs: -L${libdir} @LIBGNUTLS_LIBS@ instead? > > Without libtasn1-devel installed, macro AM_PATH_LIBGNUTLS doesnt work. As far as I understand the pkg-config documentation, Libs.private is for static linking and Libs is for dynamic linking. So I think that this is correct, since the dynamic linker takes care of the dependencies. Libs: -L${libdir} -lgnutls Libs.private: @LIBGNUTLS_LIBS@ Possibly we could have a 'Requires: libtasn1' line added, which I think would have the effect as you want: 'pkg-config --libs gnutls' will mention -ltasn1. /Simon From simon at josefsson.org Thu Feb 15 12:20:50 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 15 Feb 2007 12:20:50 +0100 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <20070214234414.GA23619@nomad.office.altlinux.org> (Dmitry V. Levin's message of "Thu\, 15 Feb 2007 02\:44\:14 +0300") References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> Message-ID: <87hctn650t.fsf@latte.josefsson.org> "Dmitry V. Levin" writes: > Hi, > > On Sun, Feb 04, 2007 at 12:59:05PM +0100, Simon Josefsson wrote: >> I'm copying the list on this, since I'd appreciate wider discussion. >> >> Pavlov Konstantin writes: >> >> > Another problem i recognized is the lack of real symbol versioning in >> > libgnutls: >> > GNUTLS_1_3 >> > { >> > global: _gnutls*; gnutls*; _E_*; >> > local: *; >> > }; >> > >> > I made a new .version file for 1.6.1 release, it looks like : >> > GNUTLS_1_3 >> > { >> > global: _gnutls*; gnutls*; _E_*; >> > }; >> > >> > GNUTLS_1_6_1 { >> > global: >> > gnutls_transport_set_errno; >> > gnutls_transport_set_global_errno; >> > local: *; >> > }; >> > >> > >> > What do you think about it ? >> >> I've re-read the relevant parts of Drepper's DSO howto to refresh my >> memory on this, but still, I don't see what problem the above change >> would fix. Could you explain? >> >> The only problem that I can think of that the above would solve if is >> an application that uses e.g. gnutls_transport_set_errno was built >> against 1.6.x or later is moved to a system which has an older >> libgnutls installed that doesn't have that symbol. The application >> will not work. > > Yes. Imagine large binary package repository (e.g. Debian or Sisyphus). > Maintainer builds new software which uses new symbols from gnutls. > When user installs package with this new software, there are no indication > that it requires new version of gnutls, so old version of gnutls may > remain unupgraded. As result, user will see runtime relocation error > which is not what maintainer usually want. One solution to that is for the new software packages to have a versioned dependency on the newer version of the gnutls packages. > To resolve this issue, our gnutls package maintainer had to create new > interface, e.g. GNUTLS_1_6_1 and place new symbols there. As result, > every package with software which uses these symbols will automatically > have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1), > so any user installing this package will also update gnutls package. There needs to be some mechanisms here that figures out that application X uses symbols from libgnutls.so.13 with the GNUTLS_1_6_1 label, and maps GNUTLS_1_6_1 back to a versioned dependency on GnuTLS version Y, and adds it to the application X packages. Right? That mechanism is presumably part of your package build scripts. Why can't that mechanism check for the new APIs instead, and add the versioned dependency when applications use them? That seems to amount to roughly the same amount of hard-coding and special mapping. But it seems more reliable. I wonder if it isn't easier to hand-maintain these versioned dependencies. Eventually, you'll run into the situation where application X depends on the behaviour (i.e., not causing a security problem) of some API gnutls_foo in GnuTLS version P or later. Shared library symbols won't protect you from this, since the shared library label of gnutls_foo won't be incremented when we fix a security problem in that function. Only hand-maintained version information does. >> We can't protect against that, though, as far as I can see. If an >> application uses a new interface, he must make sure a library that >> implements that interface is available. > > Just otherwise, library should provide new symbols via new interface, > so an application which uses new symbols will get necessary dependencies. As far as I understand, the linker scripts weren't designed for that purpose. >> Thus, my conclusion would be that, generally, adding new interface >> doesn't require changes to the version script. > > If new version of a library exports new symbols, it should add new > interface explicitly, using version script or any other available method. > As I see, gnutls uses version script for this purposes. No, GnuTLS uses version scripts to make sure that we can safely CHANGE the behaviour of an API function in a later release, and be sure that old applications will still work with the new library. If I understand Drepper's paper on shared library versioning, that was what this feature was originally designed for. I'll grant you that there is no really good documentation that seem to answer this question. It may be that adding new APIs should cause a new shared library label to be added. I see some signs that libc actually do this. Also, I doubt that I will ever CHANGE an existing API, and then use the tricky shared library tricks described in Drepper's paper to avoid problems. That mechanism isn't portable. So I frankly don't know why we are using the versioned library mechanism. Other than the Debian folks asking us to. Does anyone recall the motivation for Debian the require versioned libraries? I'd like to continue discuss this. Maybe we can write down our conclusions. There doesn't seem to be a best practice on shared library version handling written from the point of view of the maintainer of a library. /Simon From ldv at altlinux.org Thu Feb 15 13:52:10 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Thu, 15 Feb 2007 15:52:10 +0300 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <87hctn650t.fsf@latte.josefsson.org> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> <87hctn650t.fsf@latte.josefsson.org> Message-ID: <20070215125210.GA5039@basalt.office.altlinux.org> Hi, On Thu, Feb 15, 2007 at 12:20:50PM +0100, Simon Josefsson wrote: > Dmitry V. Levin writes: [...] > > Yes. Imagine large binary package repository (e.g. Debian or Sisyphus). > > Maintainer builds new software which uses new symbols from gnutls. > > When user installs package with this new software, there are no indication > > that it requires new version of gnutls, so old version of gnutls may > > remain unupgraded. As result, user will see runtime relocation error > > which is not what maintainer usually want. > > One solution to that is for the new software packages to have a > versioned dependency on the newer version of the gnutls packages. It would be error prone to rely on dependencies made by hand, especially because there is a method to make all these necessary dependencies automatically. > > To resolve this issue, our gnutls package maintainer had to create new > > interface, e.g. GNUTLS_1_6_1 and place new symbols there. As result, > > every package with software which uses these symbols will automatically > > have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1), > > so any user installing this package will also update gnutls package. > > There needs to be some mechanisms here that figures out that > application X uses symbols from libgnutls.so.13 with the GNUTLS_1_6_1 > label, and maps GNUTLS_1_6_1 back to a versioned dependency on GnuTLS > version Y, and adds it to the application X packages. Right? That > mechanism is presumably part of your package build scripts. Not exactly. ELF object X which uses symbols from libgnutls.so.13 with GNUTLS_1_3 and GNUTLS_1_6_1 interface names contains not only undefined references to these symbols but also list of required interfaces for each soname it linked with. When dynamic linker loads a library the ELF object is linked with, it checks that this library provides all requested interfaces, and aborts if check fails. Our package build scripts just fetch these interfaces requirements from ELF objects and place it to package metadata. This technique seems to be widespread. > Why can't that mechanism check for the new APIs instead, and add the > versioned dependency when applications use them? That seems to amount > to roughly the same amount of hard-coding and special mapping. But it > seems more reliable. This is exactly how described mechanism works. All it needs to work is information about API. Symbol versioning is used to be that information. > I wonder if it isn't easier to hand-maintain these versioned > dependencies. Eventually, you'll run into the situation where > application X depends on the behaviour (i.e., not causing a security > problem) of some API gnutls_foo in GnuTLS version P or later. Shared > library symbols won't protect you from this, since the shared library > label of gnutls_foo won't be incremented when we fix a security > problem in that function. Only hand-maintained version information > does. Hand-maintained versioned dependencies cannot replace automated versioned dependencies just because they are hand-maintained. When automated dependencies are not enough (like in the case described above), hand-maintained dependencies complement (but do not replace) them. > > Just otherwise, library should provide new symbols via new interface, > > so an application which uses new symbols will get necessary dependencies. > > As far as I understand, the linker scripts weren't designed for that > purpose. I can only guess what linker scripts was designed for, but they work for that purpose long time yet. > > If new version of a library exports new symbols, it should add new > > interface explicitly, using version script or any other available method. > > As I see, gnutls uses version script for this purposes. > > No, GnuTLS uses version scripts to make sure that we can safely CHANGE > the behaviour of an API function in a later release, and be sure that > old applications will still work with the new library. If I > understand Drepper's paper on shared library versioning, that was what > this feature was originally designed for. > > I'll grant you that there is no really good documentation that seem to > answer this question. It may be that adding new APIs should cause a > new shared library label to be added. I see some signs that libc > actually do this. Yes, there is a practice to follow this way. I remember gcc, elfutils, libacl, libattr, libasound, libpam, but there are certainly others. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon at josefsson.org Thu Feb 15 14:02:09 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 15 Feb 2007 14:02:09 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070215125731.GA6523@cryo.net.ru> (Pavlov Konstantin's message of "Thu\, 15 Feb 2007 15\:57\:31 +0300") References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215125731.GA6523@cryo.net.ru> Message-ID: <873b5760by.fsf@latte.josefsson.org> Pavlov Konstantin writes: > On Thu, Feb 15, 2007 at 12:01:13PM +0100, Simon Josefsson wrote: >> Pavlov Konstantin writes: >> >> > Hello everyone. >> > >> > I noticed that my libgnutls-devel package doesn't depend on libtasn1-devel >> > one. >> > >> > Looks like this is due to that line in .pc file: >> > >> > Libs.private: -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error >> > >> > Shouldnt it be Libs: -L${libdir} @LIBGNUTLS_LIBS@ instead? >> > >> > Without libtasn1-devel installed, macro AM_PATH_LIBGNUTLS doesnt work. >> >> As far as I understand the pkg-config documentation, Libs.private is >> for static linking and Libs is for dynamic linking. So I think that >> this is correct, since the dynamic linker takes care of the >> dependencies. >> >> Libs: -L${libdir} -lgnutls >> Libs.private: @LIBGNUTLS_LIBS@ >> >> Possibly we could have a 'Requires: libtasn1' line added, which I >> think would have the effect as you want: 'pkg-config --libs gnutls' >> will mention -ltasn1. > > Yes, i think this way is more correct than suggested by myself. Ok, installed. Thanks! /Simon From ametzler at downhill.at.eu.org Thu Feb 15 20:48:11 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 15 Feb 2007 20:48:11 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070214214705.GA21490@cryo.net.ru> References: <20070214214705.GA21490@cryo.net.ru> Message-ID: <20070215194811.GA4098@downhill.g.la> On 2007-02-14 Pavlov Konstantin wrote: > I noticed that my libgnutls-devel package doesn't depend on libtasn1-devel > one. Nudge the packager kindly. > Looks like this is due to that line in .pc file: I do not think so, setting a development package's dependencies is usually done semi-manually. > Libs.private: -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error > Shouldnt it be Libs: -L${libdir} @LIBGNUTLS_LIBS@ instead? No, absolutely not. There are archs that require direct linking of dependent libaries i.e. if your program is using gnutls_init() you'll need to build it by using cc -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error foo.c since libgnutsls itself is linked against libtasn. However other archs (for example Linux) do not require it, if you are just using functions from gnutls.h *directly* but none from libtasn linking against libtasn is not needed and cc -L/usr/lib -lgnutls foo.c will be the right thing to do. The point of pkg-config is to centralize the knowledge about archs needing additional linking and which do not, "pkg-config --libs gnutls" will list the additional dependencies (that is the stuff in Libs.private) if it is necessary for that arch and won't do otherwise. (All the above holds for dynamic linking, static linking requires different stuff, "pkg-config --libs --static" will help you for that.) > Without libtasn1-devel installed, macro AM_PATH_LIBGNUTLS doesnt work. That is beyond pkg-config's domain. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ametzler at downhill.at.eu.org Thu Feb 15 20:56:25 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 15 Feb 2007 20:56:25 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <87odnv65xi.fsf@latte.josefsson.org> References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> Message-ID: <20070215195625.GB4098@downhill.g.la> On 2007-02-15 Simon Josefsson wrote: [...] > Possibly we could have a 'Requires: libtasn1' line added, It would not be the right thing imho. Afaik Requires is rarely the right thing for dependencies that are libraries (Only if the API of the required library is intentionally exposed by original library.)> > which I > think would have the effect as you want: 'pkg-config --libs gnutls' > will mention -ltasn1. Well, it shouldn't. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From simon at josefsson.org Fri Feb 16 08:03:13 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 16 Feb 2007 08:03:13 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070215195625.GB4098@downhill.g.la> (Andreas Metzler's message of "Thu\, 15 Feb 2007 20\:56\:25 +0100") References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> Message-ID: <87y7my4ma6.fsf@latte.josefsson.org> Andreas Metzler writes: > On 2007-02-15 Simon Josefsson wrote: > [...] >> Possibly we could have a 'Requires: libtasn1' line added, > > It would not be the right thing imho. Afaik Requires is rarely the > right thing for dependencies that are libraries (Only if the API > of the required library is intentionally exposed by original library.)> The GTK people seem to use plenty of Requires: jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/gtk+-2.0.pc Requires: gdk-${target}-2.0 atk cairo jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/atk.pc Requires: gobject-2.0 gmodule-no-export-2.0 jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/gobject-2.0.pc Requires: glib-2.0 jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/gdk-x11-2.0.pc Requires: gdk-pixbuf-2.0 pango pangocairo fontconfig x11 xext xrender xinerama xi xrandr xcursor xfixes ... Which leads to, on my Debian box: jas at mocca:~$ pkg-config --libs gtk+-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 jas at mocca:~$ Note that even '-lm' and '-lX11' is there. IIRC, the gtk people invented pkg-config, so they should hopefully use the best practice. >> which I >> think would have the effect as you want: 'pkg-config --libs gnutls' >> will mention -ltasn1. > > Well, it shouldn't. That statement seem to be in contrast with the example above and also: > There are archs that require direct linking of dependent libaries > i.e. if your program is using gnutls_init() you'll need to build it by > using > > cc -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error foo.c > > since libgnutsls itself is linked against libtasn. If some archs require that all dependent libraries are mentioned at link-time, it seems 'pkg-config --libs gnutls' should mention all of the required library. Just like the 'gtk+-2.0' example above. > The point of pkg-config is to centralize the knowledge about archs > needing additional linking and which do not, "pkg-config --libs > gnutls" will list the additional dependencies (that is the stuff in > Libs.private) if it is necessary for that arch and won't do otherwise. Oh! Is this what is happening? Is pkg-config clever enough to do this? Anyway, I consider pkg-config a poor design since it doesn't use the test-for-a-feature-approach. It is better if applications needing GnuTLS test for it directly, using something like Bruno's M4 macros. Maybe I should write about this in the manual... Anyway, I'd be happy to change GnuTLS' pkg-config files to whatever seems to be the best common practice. /Simon From rjones at redhat.com Fri Feb 16 12:12:53 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 16 Feb 2007 11:12:53 +0000 Subject: [gnutls-dev] Patch to lib/x509/rfc2818_hostname.c Message-ID: <45D591B5.70609@redhat.com> Not a security problem because CAs you trust ought not to be issuing certificates without dnsname and common name (thanks to Tomas Mraz for correcting me on this). But it still seems wrong to be returning that the hostname is valid if it has missing/malformed common name. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759) -------------- next part -------------- A non-text attachment was scrubbed... Name: rfc2818_hostname.c.patch Type: text/x-patch Size: 286 bytes Desc: not available URL: From simon at josefsson.org Fri Feb 16 14:29:59 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 16 Feb 2007 14:29:59 +0100 Subject: [gnutls-dev] Patch to lib/x509/rfc2818_hostname.c In-Reply-To: <45D591B5.70609@redhat.com> (Richard W. M. Jones's message of "Fri\, 16 Feb 2007 11\:12\:53 +0000") References: <45D591B5.70609@redhat.com> Message-ID: <87k5yi9qnc.fsf@latte.josefsson.org> "Richard W.M. Jones" writes: > Not a security problem because CAs you trust ought not to be issuing > certificates without dnsname and common name (thanks to Tomas Mraz for > correcting me on this). But it still seems wrong to be returning that > the hostname is valid if it has missing/malformed common name. Hi! Thanks for the report. I have created a self-test for this (tests/hostname-check), to catch any regressions in this area, and fixed the problem in CVS. I also noticed that we currently don't support URIs with IP addresses and CA's with iPAddress SAN's in the comparison function. I implemented support for that. /Simon From ametzler at downhill.at.eu.org Sun Feb 18 12:47:13 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 18 Feb 2007 12:47:13 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <87y7my4ma6.fsf@latte.josefsson.org> References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> Message-ID: <20070218114713.GA3882@downhill.g.la> On 2007-02-16 Simon Josefsson wrote: > Andreas Metzler writes: > > On 2007-02-15 Simon Josefsson wrote: > > [...] > >> Possibly we could have a 'Requires: libtasn1' line added, > > > > It would not be the right thing imho. Afaik Requires is rarely the > > right thing for dependencies that are libraries (Only if the API > > of the required library is intentionally exposed by original library.)> > The GTK people seem to use plenty of Requires: > jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/gtk+-2.0.pc > Requires: gdk-${target}-2.0 atk cairo > jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/atk.pc > Requires: gobject-2.0 gmodule-no-export-2.0 > jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/gobject-2.0.pc > Requires: glib-2.0 > jas at mocca:~$ grep '^Requires:' /usr/lib/pkgconfig/gdk-x11-2.0.pc > Requires: gdk-pixbuf-2.0 pango pangocairo fontconfig x11 xext xrender xinerama xi xrandr xcursor xfixes > ... > Which leads to, on my Debian box: > jas at mocca:~$ pkg-config --libs gtk+-2.0 > -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 > jas at mocca:~$ > Note that even '-lm' and '-lX11' is there. IIRC, the gtk people > invented pkg-config, so they should hopefully use the best practice. Afaik that is because a) gtk *does* expose and require the atk (/usr/include/gtk-2.0/gtk/gtkaccessible.h) and cairo (/usr/include/gtk-2.0/gdk/gdkcairo.h) APIs/headers and b) because Requires.private is currently rather useless http://bugs.debian.org/390132 forcing GNOME to use Requires instead. gnutls does not expose the tasn API or require its headers, so it does not need to use Requires. > >> which I > >> think would have the effect as you want: 'pkg-config --libs gnutls' > >> will mention -ltasn1. > > Well, it shouldn't. > That statement seem to be in contrast with the example above and also: > > There are archs that require direct linking of dependent libaries > > i.e. if your program is using gnutls_init() you'll need to build it by > > using > > cc -L/usr/lib -lgnutls -ltasn1 -lgcrypt -lgpg-error foo.c > > since libgnutsls itself is linked against libtasn. > If some archs require that all dependent libraries are mentioned at > link-time, it seems 'pkg-config --libs gnutls' should mention all of > the required library. Just like the 'gtk+-2.0' example above. > > The point of pkg-config is to centralize the knowledge about archs > > needing additional linking and which do not, "pkg-config --libs > > gnutls" will list the additional dependencies (that is the stuff in > > Libs.private) if it is necessary for that arch and won't do otherwise. > Oh! Is this what is happening? Is pkg-config clever enough to do > this? Yes, when building pkg-config itself it queries libtool to check whether indirect dependencies should be reported on the arch it is building for. The result is then hardcoded into the pkg-config binary. > Anyway, I consider pkg-config a poor design since it doesn't use the > test-for-a-feature-approach. [...] I do not disagree. ;-) It is a little bit better still than using a separate libfoo-config script. ;-) thanks, cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From wk at gnupg.org Sun Feb 18 14:11:55 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Feb 2007 14:11:55 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070218114713.GA3882@downhill.g.la> (Andreas Metzler's message of "Sun\, 18 Feb 2007 12\:47\:13 +0100") References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> <20070218114713.GA3882@downhill.g.la> Message-ID: <87d547hap0.fsf@wheatstone.g10code.de> On Sun, 18 Feb 2007 12:47, ametzler at downhill.at.eu.org said: > I do not disagree. ;-) It is a little bit better still than using a > separate libfoo-config script. ;-) libfoo-config allows from cross-compilation. With pkg-config you need to edit the .pc files first. Salam-Shalom, Werner From ametzler at downhill.at.eu.org Sun Feb 18 15:32:52 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 18 Feb 2007 15:32:52 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <87d547hap0.fsf@wheatstone.g10code.de> References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> <20070218114713.GA3882@downhill.g.la> <87d547hap0.fsf@wheatstone.g10code.de> Message-ID: <20070218143252.GA4483@downhill.g.la> On 2007-02-18 Werner Koch wrote: > On Sun, 18 Feb 2007 12:47, ametzler at downhill.at.eu.org said: > > I do not disagree. ;-) It is a little bit better still than using a > > separate libfoo-config script. ;-) > libfoo-config allows from cross-compilation. With pkg-config you need > to edit the .pc files first. Never done that, but setting PKG_CONFIG_LIBDIR should be sufficient. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ametzler at downhill.at.eu.org Sun Feb 18 17:56:30 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 18 Feb 2007 17:56:30 +0100 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <20070214234414.GA23619@nomad.office.altlinux.org> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> Message-ID: <20070218165630.GB4483@downhill.g.la> On 2007-02-15 "Dmitry V. Levin" wrote: > On Sun, Feb 04, 2007 at 12:59:05PM +0100, Simon Josefsson wrote: [...] > > I've re-read the relevant parts of Drepper's DSO howto to refresh my > > memory on this, but still, I don't see what problem the above change > > would fix. Could you explain? [...] > Yes. Imagine large binary package repository (e.g. Debian or Sisyphus). > Maintainer builds new software which uses new symbols from gnutls. > When user installs package with this new software, there are no indication > that it requires new version of gnutls, so old version of gnutls may > remain unupgraded. As result, user will see runtime relocation error > which is not what maintainer usually want. > To resolve this issue, our gnutls package maintainer had to create new > interface, e.g. GNUTLS_1_6_1 and place new symbols there. As result, > every package with software which uses these symbols will automatically > have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1), > so any user installing this package will also update gnutls package. [...] Hello, Your proposed change would not improve things for Debian at all. The current way for searching dependencies in Debian is symbol-versioning agnostic, it basically[1] works like this: 1. Use "objdump -p binaryfile | grep NEEDED" to search for direct dependencies. (Yields "libgcrypt.so.11".) 2. Search for the package containing the libraryfile ("libgcrypt.so.11") using dpkg --search and check *its* shlibs file[2] for the dependency information to put into the new Depends. Therefore the only thing that is actually looked at is the soname of the library and your change would not help. However *if* gnutls introduces new symbols, Debian handles the just fine. The gnutls package maintainer is supposed to know that (either from reading the diff or some other source of information) and will "bump gnutls' shlibs file", i.e. he will change the dependency information in gnutls, causing every package built against the new gnutls version to have stricter version requirements. --------------------------------------------- Afaict[3] things are different for rpm. /usr/lib/rpm/find-provides and /usr/lib/rpm/find-requires seem to handle versioned symbols, but will never generate a normal versioned dependency. rpm looks into "Version References" and "Version definitions" in opbdump's output and handles libgnutls.so.13(GNUTLS_1_3) instead of just libgnutls.so.13. Therefore you end up with stuff with --requires libgnutls.so.13 libgnutls.so.13(GNUTLS_1_3) and the gnutls library package --provides libgnutls.so.13 libgnutls.so.13(GNUTLS_1_3) So afaict Dmitry's change might indeed improve things for rpm. However it seems to be a rather big hammer. And the problem is old, I think I am missing something _big_, the majority of libraries does not use symbol versioning, rpm based distributions must already have some different way to handle adding of symbols to libraries and generating the necessary dependencies. cu andreas [1] There are also override files and searching for the dependency in the current buildtree. [2] /var/lib/dpkg/info/libgnutls13.shlibs libgnutls 13 libgnutls13 (>=1.4.0-0) libgnutls-extra 13 libgnutls13 (>=1.4.0-0) libgnutls-openssl 13 libgnutls13 (>=1.4.0-0) [3] I have not got access to a installation using an rpm based distro and have not used one for years. -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ldv at altlinux.org Sun Feb 18 19:28:42 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Sun, 18 Feb 2007 21:28:42 +0300 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <20070218165630.GB4483@downhill.g.la> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> <20070218165630.GB4483@downhill.g.la> Message-ID: <20070218182842.GA893@basalt.office.altlinux.org> Hi, On Sun, Feb 18, 2007 at 05:56:30PM +0100, Andreas Metzler wrote: > On 2007-02-15 Dmitry V. Levin wrote: [...] > > To resolve this issue, our gnutls package maintainer had to create new > > interface, e.g. GNUTLS_1_6_1 and place new symbols there. As result, > > every package with software which uses these symbols will automatically > > have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1), > > so any user installing this package will also update gnutls package. [...] > Your proposed change would not improve things for Debian at all. > The current way for searching dependencies in Debian is > symbol-versioning agnostic [...] > Afaict things are different for rpm. /usr/lib/rpm/find-provides and > /usr/lib/rpm/find-requires seem to handle versioned symbols, but will > never generate a normal versioned dependency. rpm looks into "Version > References" and "Version definitions" in opbdump's output and handles > libgnutls.so.13(GNUTLS_1_3) instead of just libgnutls.so.13. Therefore > you end up with stuff with --requires > > libgnutls.so.13 > libgnutls.so.13(GNUTLS_1_3) > > and the gnutls library package --provides > > libgnutls.so.13 > libgnutls.so.13(GNUTLS_1_3) > > So afaict Dmitry's change might indeed improve things for rpm. Yes, it does. > However > it seems to be a rather big hammer. And the problem is old, I think I > am missing something _big_, the majority of libraries does > not use symbol versioning, Probably because symbol versioning is not portable. Most of libraries which use symbol versioning are maintained by GNU/Linux developers. > rpm based distributions must already have > some different way to handle adding of symbols to libraries and > generating the necessary dependencies. Besides of the the method we are talking about, there are no reliable methods I'm aware of. rpm based distributions usually follow reactive strategy: when application package fails to run with some library package, they just rebuild application package with verioned dependency on library package which is known to work nice with this application package. I prefer (and introduce in Sisyphus) a proactive solution instead. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wk at gnupg.org Sun Feb 18 23:13:42 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Feb 2007 23:13:42 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070218143252.GA4483@downhill.g.la> (Andreas Metzler's message of "Sun\, 18 Feb 2007 15\:32\:52 +0100") References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> <20070218114713.GA3882@downhill.g.la> <87d547hap0.fsf@wheatstone.g10code.de> <20070218143252.GA4483@downhill.g.la> Message-ID: <874ppjf71l.fsf@wheatstone.g10code.de> On Sun, 18 Feb 2007 15:32, ametzler at downhill.at.eu.org said: > Never done that, but setting PKG_CONFIG_LIBDIR should be sufficient. No it is not. We need to use an extra pkg-config wrapper to fix the problems. And that for gtk+ stuff. Salam-Shalom, Werner From ametzler at downhill.at.eu.org Mon Feb 19 20:14:58 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 19 Feb 2007 20:14:58 +0100 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <20070218182842.GA893@basalt.office.altlinux.org> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> <20070218165630.GB4483@downhill.g.la> <20070218182842.GA893@basalt.office.altlinux.org> Message-ID: <20070219191458.GA3799@downhill.g.la> On 2007-02-18 "Dmitry V. Levin" wrote: > On Sun, Feb 18, 2007 at 05:56:30PM +0100, Andreas Metzler wrote: [...] > > However > > it seems to be a rather big hammer. And the problem is old, I think I > > am missing something _big_, the majority of libraries does > > not use symbol versioning, > Probably because symbol versioning is not portable. > Most of libraries which use symbol versioning are maintained by > GNU/Linux developers. > > rpm based distributions must already have > > some different way to handle adding of symbols to libraries and > > generating the necessary dependencies. > Besides of the the method we are talking about, there are no reliable > methods I'm aware of. rpm based distributions usually follow reactive > strategy: when application package fails to run with some library > package, they just rebuild application package with verioned dependency on > library package which is known to work nice with this application package. [...] I don't understand how /that/ could help. The problem as I see it is that the dependencies of the program on the library are unversioned and therefore allow installing the program with a too old version of the library. Rebuilding would not change the dependency and would not fix the problem. cu andreas From ldv at altlinux.org Mon Feb 19 22:34:18 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Tue, 20 Feb 2007 00:34:18 +0300 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <20070219191458.GA3799@downhill.g.la> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> <20070218165630.GB4483@downhill.g.la> <20070218182842.GA893@basalt.office.altlinux.org> <20070219191458.GA3799@downhill.g.la> Message-ID: <20070219213418.GA12773@basalt.office.altlinux.org> On Mon, Feb 19, 2007 at 08:14:58PM +0100, Andreas Metzler wrote: > On 2007-02-18 Dmitry V. Levin wrote: > > On Sun, Feb 18, 2007 at 05:56:30PM +0100, Andreas Metzler wrote: > [...] > > > However > > > it seems to be a rather big hammer. And the problem is old, I think I > > > am missing something _big_, the majority of libraries does > > > not use symbol versioning, > > > Probably because symbol versioning is not portable. > > Most of libraries which use symbol versioning are maintained by > > GNU/Linux developers. > > > > rpm based distributions must already have > > > some different way to handle adding of symbols to libraries and > > > generating the necessary dependencies. > > > Besides of the the method we are talking about, there are no reliable > > methods I'm aware of. pkg-config versioned requirementes in applications also may help, but these requirements require efforts from application maintainers and therefore not reliable. > > rpm based distributions usually follow reactive > > strategy: when application package fails to run with some library > > package, they just rebuild application package with verioned dependency on > > library package which is known to work nice with this application package. > [...] > > I don't understand how /that/ could help. The problem as I see it is > that the dependencies of the program on the library are unversioned and > therefore allow installing the program with a too old version of the > library. Rebuilding would not change the dependency and would not fix > the problem. They do add verioned requirement by hand and rebuild. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon at josefsson.org Tue Feb 20 00:14:06 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 20 Feb 2007 00:14:06 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070218114713.GA3882@downhill.g.la> (Andreas Metzler's message of "Sun\, 18 Feb 2007 12\:47\:13 +0100") References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> <20070218114713.GA3882@downhill.g.la> Message-ID: <87abz9g2pt.fsf@latte.josefsson.org> Andreas Metzler writes: >> Which leads to, on my Debian box: > >> jas at mocca:~$ pkg-config --libs gtk+-2.0 >> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 >> jas at mocca:~$ > >> Note that even '-lm' and '-lX11' is there. IIRC, the gtk people >> invented pkg-config, so they should hopefully use the best practice. > > Afaik that is because > a) gtk *does* expose and require the atk > (/usr/include/gtk-2.0/gtk/gtkaccessible.h) and cairo > (/usr/include/gtk-2.0/gdk/gdkcairo.h) APIs/headers I see your point, but I'm not sure it holds for gtk. Does gtk, or one of its dependencies, also expose the -lm, -lX11, -lpango etc APIs? The 'pkg-config --libs gtk+-2.0' output seem to contain all libraries use by any gtk application. That wouldn't be necessary, since both libgtk and libgdk dynamically links with -lX11, -lpango etc. Lacking any clear and referencable documentation to answer this, I think mimicking the GTK people's pkg-config behaviour is the best we can do. They wrote pkg-config after all. That means adding the 'Requires:'. > and > b) because Requires.private is currently rather useless > http://bugs.debian.org/390132 forcing GNOME to use Requires instead. Ah, maybe fixing that bug is the real solution. Then gnutls could have: Requires.private: libtasn1 and no 'Requires:'. Maybe we could make this change now, reverting to the old behaviour, and be prepared for when 'Requires.private' works fine? As far as I understand, it does work today, except recursively. > Yes, when building pkg-config itself it queries libtool to check > whether indirect dependencies should be reported on the arch it is > building for. The result is then hardcoded into the pkg-config binary. Yes, ok, so I now think it should be 'Requires.private: libtasn1'. >> Anyway, I consider pkg-config a poor design since it doesn't use the >> test-for-a-feature-approach. > [...] > > I do not disagree. ;-) It is a little bit better still than using a > separate libfoo-config script. ;-) Yes. Although it does require users to install yet another package (pkg-config)... to me, that almost, but only almost, cancels out the advantage. /Simon From ametzler at downhill.at.eu.org Tue Feb 20 16:30:39 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 20 Feb 2007 16:30:39 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <87abz9g2pt.fsf@latte.josefsson.org> References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> <20070218114713.GA3882@downhill.g.la> <87abz9g2pt.fsf@latte.josefsson.org> Message-ID: <20070220153039.GA3700@downhill.g.la> On 2007-02-20 Simon Josefsson wrote: > Andreas Metzler writes: > >> Which leads to, on my Debian box: > > > >> jas at mocca:~$ pkg-config --libs gtk+-2.0 > >> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lpango-1.0 -lcairo -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 > >> jas at mocca:~$ > > > >> Note that even '-lm' and '-lX11' is there. IIRC, the gtk people > >> invented pkg-config, so they should hopefully use the best practice. > > > > Afaik that is because > > a) gtk *does* expose and require the atk > > (/usr/include/gtk-2.0/gtk/gtkaccessible.h) and cairo > > (/usr/include/gtk-2.0/gdk/gdkcairo.h) APIs/headers > I see your point, but I'm not sure it holds for gtk. Does gtk, or one > of its dependencies, also expose the -lm, -lX11, -lpango etc APIs? Yes, they do. gtk.h includes gdk/gdk.h. --> gtk+-2.0.pc Requires: gdk-${target}-2.0 gtkwidget.h includes atk/atkobject.h --> gtk+-2.0.pc Requires: atk gdkx.h includes X11/Xlib.h --> gdk-x11-2.0.pc needs Requires: x11 etc. ad nauseam, grep is your friend. ;-) I tend to think the Requires on cairo should not be there. (Not that it makes any difference gdk-x11-2.0.pc rightfully requies it.) The -lm is caused by brokenness in gdk-pixbuf-2.0.pc (just Libs: instead of splitting into Libs: and Libs.private) [...] > Ah, maybe fixing that bug is the real solution. Then gnutls could > have: > Requires.private: libtasn1 > and no 'Requires:'. [...] gnutls is not in the same boat as gtk*. None of gnutls headers include headers from tasn. Requires are not necessary for gnutls. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From simon at josefsson.org Thu Feb 22 07:59:12 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 22 Feb 2007 07:59:12 +0100 Subject: [gnutls-dev] pkg-config file for libgnutls In-Reply-To: <20070220153039.GA3700@downhill.g.la> (Andreas Metzler's message of "Tue\, 20 Feb 2007 16\:30\:39 +0100") References: <20070214214705.GA21490@cryo.net.ru> <87odnv65xi.fsf@latte.josefsson.org> <20070215195625.GB4098@downhill.g.la> <87y7my4ma6.fsf@latte.josefsson.org> <20070218114713.GA3882@downhill.g.la> <87abz9g2pt.fsf@latte.josefsson.org> <20070220153039.GA3700@downhill.g.la> Message-ID: <87zm76lltr.fsf@latte.josefsson.org> Andreas Metzler writes: >> Ah, maybe fixing that bug is the real solution. Then gnutls could >> have: > >> Requires.private: libtasn1 > >> and no 'Requires:'. > [...] > > > gnutls is not in the same boat as gtk*. None of gnutls headers include > headers from tasn. Requires are not necessary for gnutls. You've convinced me, I'm reverting this change. I came up with another reason why the 'Requires: libtasn1' is wrong: gnutls doesn't use or require libtasn1 if GnuTLS was built with --with-included-minitasn1. This means that Pavlov's gnutls-dev package will have to contain a manually maintained dependency on libtasn1-dev. For my Debian shishi package, I had the same issue with the *-dev packages, and as far as I can see, there is unfortunately no better way to solve it. /Simon From simon at josefsson.org Thu Feb 22 09:58:30 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 22 Feb 2007 09:58:30 +0100 Subject: [gnutls-dev] GnuTLS 1.7.7 Message-ID: <87y7mqin61.fsf@latte.josefsson.org> Support for Supplemental handshake messages and the TLS authorization extension, and some other stuff. Remember, the GnuTLS 1.7.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. * Version 1.7.7 (released 2007-02-22) ** Support for supplemental handshake messages and authorization data. Supplemental data is described in RFC 4680 and the authorization extensions in draft-housley-tls-authz-extns-07. ** Support for authorization data in gnutls-cli and gnutls-serv. New parameters --authz-x509-attr-cert and --authz-saml-assertion. ** Fix for gnutls_x509_crt_check_hostname. Before it would have reported that the certificate matched a hostname when it did not have any dNSName or any CN field. Report and tiny patch from "Richard W.M. Jones" . ** New self test for RFC 2818 comparison in gnutls_x509_crt_check_hostname. Tests regressions of the bug, and several other features. ** GnuTLS now matches URI's with IP Addresses against iPAddress SAN's. Before there were no support for iPAddress SAN's during comparison. ** New API to print information about CRL's. The function is gnutls_x509_crl_print. ** New API to extract signature value from CRL's. The function is gnutls_x509_crl_get_signature. ** Support for directoryName Subject Alternative Name's. The gnutls_x509_crt_get_subject_alt_name function returns the DN as a string in the provided buffer. ** Internal improvements to certtool. It uses gnutls_x509_crl_print to print CRL information. It uses some more gnulib modules to simplify error handling. ** API and ABI modifications: GNUTLS_HANDSHAKE_SUPPLEMENTAL: ADD, new gnutls_handshake_description_t element. gnutls_supplemental_data_format_type_t: ADD. gnutls_authz_data_format_type_t: ADD. gnutls_supplemental_get_name: ADD. gnutls_authz_recv_callback_func, gnutls_authz_send_callback_func: ADD, callback prototypes. gnutls_authz_enable: ADD. gnutls_authz_send_x509_attr_cert, gnutls_authz_send_saml_assertion, gnutls_authz_send_x509_attr_cert_url, gnutls_authz_send_saml_assertion_url: ADD. GNUTLS_SAN_DN: ADD, new gnutls_x509_subject_alt_name_t element. gnutls_x509_crl_print: ADD. gnutls_x509_crl_get_signature: ADD. Here are the compressed sources (4.2MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.7.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.7.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.7.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.7.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: 2306eaa68b41ff51f81d3801282208c5bc12baae gnutls-1.7.7.tar.bz2 b2a14e5469e7029425c4e524a45c89997b95b075 gnutls-1.7.7.tar.bz2.sig a4dd37fae3070321ff5936c8384c272192f5d447ffba4aaabe3e6655 gnutls-1.7.7.tar.bz2 7a72d5ffe485419058810ef6400fb181e8bf7795c845dca608a1d7a4 gnutls-1.7.7.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Fri Feb 23 13:35:03 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 23 Feb 2007 13:35:03 +0100 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS Message-ID: <87y7mpm4qw.fsf@latte.josefsson.org> I'm considering moving away from CVS, mainly because of branch handling and offline repository support. Officially only 1.6.x and 1.7.x are supported, but I suspect that I would have to release patches for at least 1.4.x and 1.2.x too, and perhaps even 1.0.x, when a security problem is discovered. Offline repositories allows me and others to work with full VC history available when I don't have connectivity. My main candidate is git, but I'm considering other tools too. I need to learn git a bit more before deciding, but right now, it seems to be the most promising choice. Now, packing for FOSDEM... /Simon From ldv at altlinux.org Fri Feb 23 16:13:40 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Fri, 23 Feb 2007 18:13:40 +0300 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <87y7mpm4qw.fsf@latte.josefsson.org> References: <87y7mpm4qw.fsf@latte.josefsson.org> Message-ID: <20070223151340.GI28905@basalt.office.altlinux.org> On Fri, Feb 23, 2007 at 01:35:03PM +0100, Simon Josefsson wrote: > I'm considering moving away from CVS, mainly because of branch > handling and offline repository support. Officially only 1.6.x and > 1.7.x are supported, but I suspect that I would have to release > patches for at least 1.4.x and 1.2.x too, and perhaps even 1.0.x, when > a security problem is discovered. Offline repositories allows me and > others to work with full VC history available when I don't have > connectivity. > > My main candidate is git, but I'm considering other tools too. I need > to learn git a bit more before deciding, but right now, it seems to be > the most promising choice. Choosing git would be most comfortable choice for ALT since we also use git, see e.g. http://git.altlinux.org/people/thresh/packages/?p=gnutls.git -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ldv at altlinux.org Fri Feb 23 18:54:45 2007 From: ldv at altlinux.org (Dmitry V. Levin) Date: Fri, 23 Feb 2007 20:54:45 +0300 Subject: [gnutls-dev] gnutls versioning again In-Reply-To: <20070218182842.GA893@basalt.office.altlinux.org> References: <200702021701.07959.thresh@immo.ru> <873b5ovcpy.fsf@latte.josefsson.org> <200702021806.15123.thresh@immo.ru> <873b5myvzq.fsf@latte.josefsson.org> <20070214234414.GA23619@nomad.office.altlinux.org> <20070218165630.GB4483@downhill.g.la> <20070218182842.GA893@basalt.office.altlinux.org> Message-ID: <20070223175445.GA11534@nomad.office.altlinux.org> On Sun, Feb 18, 2007 at 09:28:42PM +0300, Dmitry V. Levin wrote: > On Sun, Feb 18, 2007 at 05:56:30PM +0100, Andreas Metzler wrote: > > On 2007-02-15 Dmitry V. Levin wrote: [...] > > However > > it seems to be a rather big hammer. And the problem is old, I think I > > am missing something _big_, the majority of libraries does > > not use symbol versioning, > > Probably because symbol versioning is not portable. > Most of libraries which use symbol versioning are maintained by > GNU/Linux developers. JFYI, in Sisyphus/x86-64 only 148 shared libraries (where total is 2043 shared libraries) use symbol versioning. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon at josefsson.org Tue Feb 27 10:46:09 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 27 Feb 2007 10:46:09 +0100 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <20070223151340.GI28905@basalt.office.altlinux.org> (Dmitry V. Levin's message of "Fri\, 23 Feb 2007 18\:13\:40 +0300") References: <87y7mpm4qw.fsf@latte.josefsson.org> <20070223151340.GI28905@basalt.office.altlinux.org> Message-ID: <87odngorvi.fsf@latte.josefsson.org> "Dmitry V. Levin" writes: > On Fri, Feb 23, 2007 at 01:35:03PM +0100, Simon Josefsson wrote: >> I'm considering moving away from CVS, mainly because of branch >> handling and offline repository support. Officially only 1.6.x and >> 1.7.x are supported, but I suspect that I would have to release >> patches for at least 1.4.x and 1.2.x too, and perhaps even 1.0.x, when >> a security problem is discovered. Offline repositories allows me and >> others to work with full VC history available when I don't have >> connectivity. >> >> My main candidate is git, but I'm considering other tools too. I need >> to learn git a bit more before deciding, but right now, it seems to be >> the most promising choice. > > Choosing git would be most comfortable choice for ALT since we also use > git, see e.g. > http://git.altlinux.org/people/thresh/packages/?p=gnutls.git Ok, nice! I thought that trying things out is the best way to learn. So I have started with libtasn1, and did this (paths slightly altered): $ rsync --delete -e ssh -av cvs.gnupg.org:/cvs/gnutls/ tmp $ cat< /tmp/foo wkoch:Werner Koch nmav:Nikos Mavrogiannopoulos fiorinaf:Fabio Fiorina twoaday:Timo Schulz admcd:Andrew McDonald jas:Simon Josefsson EOF $ mkdir git $ git-cvsimport -A /tmp/foo -k -d tmp -C git libtasn1 $ cg-clone libtasn1 ff defaulting to local storage area Using hard links Fetching head... Fetching objects... Getting pack 9e406f174c6b3e8a7351986b22d8de9a4dd75562 which contains 53377078be6f9746db1662ee6e03fe8ce5e5c6d3 progress: 2 objects, 0 bytes Fetching tags... Missing tag gnutls_0_5_0... Missing tag gnutls_0_5_0... Missing tag gnutls_0_5_1... Missing tag gnutls_0_5_1... Missing tag libasn1_0_1_0... Missing tag libasn1_0_1_0... Missing tag libtasn1_0_1_2... Missing tag libtasn1_0_1_2... Missing tag libtasn1_0_2_0... Missing tag libtasn1_0_2_0... Missing tag libtasn1_0_2_1... Missing tag libtasn1_0_2_1... Missing tag libtasn1_0_2_10... Missing tag libtasn1_0_2_10... Missing tag libtasn1_0_2_11... Missing tag libtasn1_0_2_11... Missing tag libtasn1_0_2_12... Missing tag libtasn1_0_2_12... Missing tag libtasn1_0_2_13... Missing tag libtasn1_0_2_13... Missing tag libtasn1_0_2_14... Missing tag libtasn1_0_2_14... Missing tag libtasn1_0_2_15... Missing tag libtasn1_0_2_15... Missing tag libtasn1_0_2_16... Missing tag libtasn1_0_2_16... Missing tag libtasn1_0_2_17... Missing tag libtasn1_0_2_17... Missing tag libtasn1_0_2_18... Missing tag libtasn1_0_2_18... Missing tag libtasn1_0_2_2... Missing tag libtasn1_0_2_2... Missing tag libtasn1_0_2_3... Missing tag libtasn1_0_2_3... Missing tag libtasn1_0_2_4... Missing tag libtasn1_0_2_4... Missing tag libtasn1_0_2_5... Missing tag libtasn1_0_2_5... Missing tag libtasn1_0_2_6... Missing tag libtasn1_0_2_6... Missing tag libtasn1_0_2_7... Missing tag libtasn1_0_2_7... Missing tag libtasn1_0_2_8... Missing tag libtasn1_0_2_8... Missing tag libtasn1_0_2_9... Missing tag libtasn1_0_2_9... Missing tag libtasn1_0_3_0... Missing tag libtasn1_0_3_0... Missing tag libtasn1_0_3_1... Missing tag libtasn1_0_3_1... Missing tag libtasn1_0_3_2... Missing tag libtasn1_0_3_2... Missing tag libtasn1-0-3-2... Missing tag libtasn1-0-3-2... Missing tag libtasn1_0_3_3... Missing tag libtasn1_0_3_3... Missing tag libtasn1_0_3_4... Missing tag libtasn1_0_3_4... Missing tag libtasn1_0_3_5... Missing tag libtasn1_0_3_5... Missing tag libtasn1_0_3_6... Missing tag libtasn1_0_3_6... Missing tag libtasn1_0_3_7... Missing tag libtasn1_0_3_7... Missing tag libtasn1_0_3_8... Missing tag libtasn1_0_3_8... Missing tag libtasn1_after_rename... Missing tag libtasn1_after_rename... Missing tag start... Missing tag start... New branch: 53377078be6f9746db1662ee6e03fe8ce5e5c6d3 Cloned to ff/ (origin /home/jas/self/private-git/libtasn1 available as branch "origin") $ cd ff $ cg-branch-add pub git+ssh://repo.or.cz/srv/git/libtasn1.git $ cg-push pub The authenticity of host 'repo.or.cz (62.24.64.27)' can't be established. RSA key fingerprint is 07:7a:5c:6c:39:b3:ac:a9:e5:70:5d:41:ba:a6:37:04. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'repo.or.cz,62.24.64.27' (RSA) to the list of known hosts. updating 'refs/heads/master' from 0000000000000000000000000000000000000000 to 53377078be6f9746db1662ee6e03fe8ce5e5c6d3 Generating pack... Done counting 2273 objects. Deltifying 2273 objects. 100% (2273/2273) done Writing 2273 objects. Unpacking 2273 objects 100% (2273/2273) done Total 2273, written 2273 (delta 1558), reused 2261 (delta 1558) refs/heads/master: 0000000000000000000000000000000000000000 -> 53377078be6f9746db1662ee6e03fe8ce5e5c6d3 $ And something appears on: http://repo.or.cz/w/libtasn1.git However, I wonder if I lost all the tags? Any ideas how to fix that? I'll see if I can solve this... /Simon From simon at josefsson.org Tue Feb 27 10:58:22 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 27 Feb 2007 10:58:22 +0100 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <87odngorvi.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue\, 27 Feb 2007 10\:46\:09 +0100") References: <87y7mpm4qw.fsf@latte.josefsson.org> <20070223151340.GI28905@basalt.office.altlinux.org> <87odngorvi.fsf@latte.josefsson.org> Message-ID: <87k5y3q5vl.fsf@latte.josefsson.org> Simon Josefsson writes: > However, I wonder if I lost all the tags? Any ideas how to fix that? > I'll see if I can solve this... It seems 'cg-push' doesn't handle tags, sigh: -t TAG Tells cg-push to also push the given tag. Note that in the future, cg-push should push tags automatically. Also note that even if you pass cg-push(1) the -t arguments, your HEAD is still pushed as well in addition to the tags. However, 'git-push --tags pub' solved it. I think I won't use Cogito any more.. Let's see if I can make a release from our new git tree. /Simon From simon at josefsson.org Tue Feb 27 11:08:53 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 27 Feb 2007 11:08:53 +0100 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <87odngorvi.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue\, 27 Feb 2007 10\:46\:09 +0100") References: <87y7mpm4qw.fsf@latte.josefsson.org> <20070223151340.GI28905@basalt.office.altlinux.org> <87odngorvi.fsf@latte.josefsson.org> Message-ID: <87fy8rq5e2.fsf@latte.josefsson.org> For future reference, below are the complete steps I made to move from CVS to GIT for libtasn1. Quite easy once I found all the commands (which took some time, there is not much good high-level documentation). Further, the steps are idempotent, so I can run this more than once. I have no idea what happens if I make any changes on the CVS server though, although git-cvsimport claims to support that. Possibly I should then call git-cvsimport on an existing work tree for things to work best. Now, let's see if I can make a release based on this git repository... /Simon # Start in a fresh directory. jas at mocca:~$ mkdir git jas at mocca:~$ cd git jas at mocca:~/git$ # Get a local copy of the CVS repository jas at mocca:~/git$ rsync --delete -e ssh -av cvs.gnupg.org:/cvs/gnutls/ gnutls/ ... # Fix usernames (optional, but remove -A below if you skip this) cat< /tmp/foo wkoch:Werner Koch nmav:Nikos Mavrogiannopoulos fiorinaf:Fabio Fiorina twoaday:Timo Schulz admcd:Andrew McDonald jas:Simon Josefsson EOF # Convert into a new git repository. jas at mocca:~/git$ git-cvsimport -A /tmp/foo -k -d $PWD/gnutls -C repo libtasn1 Committing initial tree 397dce26cda49d25909964c68cb65b302a26c8e9 Generating pack... Done counting 2314 objects. Deltifying 2314 objects. 100% (2314/2314) done Writing 2314 objects. 100% (2314/2314) done Total 2314, written 2314 (delta 1574), reused 0 (delta 0) Pack pack-9e406f174c6b3e8a7351986b22d8de9a4dd75562 created. jas at mocca:~/git$ # Check out a working copy. jas at mocca:~/git$ git-clone repo work remote: Generating pack... remote: Done counting 2314 objects. remote: Deltifying 2314 objects. remote: 100% (2314/2314) done Indexing 2314 objects. remote: Total 2314, written 2314 (delta 1574), reused 2314 (delta 1574) 100% (2314/2314) done Resolving 1574 deltas. 100% (1574/1574) done jas at mocca:~/git$ # Add a push branch to make stuff accessible publicly. jas at mocca:~/git$ cd work/ jas at mocca:~/git/work$ cg-branch-add pub git+ssh://repo.or.cz/srv/git/libtasn1.git # Push everything to the public site. jas at mocca:~/git/work$ git-push --tags pub Everything up-to-date jas at mocca:~/git/work$ From fw at deneb.enyo.de Wed Feb 28 20:40:25 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 28 Feb 2007 20:40:25 +0100 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <87fy8rq5e2.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 27 Feb 2007 11:08:53 +0100") References: <87y7mpm4qw.fsf@latte.josefsson.org> <20070223151340.GI28905@basalt.office.altlinux.org> <87odngorvi.fsf@latte.josefsson.org> <87fy8rq5e2.fsf@latte.josefsson.org> Message-ID: <87y7mi840m.fsf@mid.deneb.enyo.de> * Simon Josefsson: > I have no idea what happens if I make any changes on the CVS server > though, although git-cvsimport claims to support that. Incremental conversion seems to work relatively well, especially if you haven't used broken CVS versions on your repository. Note that GIT has one drawback: it doesn't preserve file identity. Almost all other sytems (except CVS) keep file identity, which means that some manual work is necessary when you import GIT changesets into them. The other way round is far easier. I believe the HTTP transport is a bit like a stepchild these days. And I couldn't clone your GIT repostory. From simon at josefsson.org Wed Feb 28 22:41:27 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 28 Feb 2007 22:41:27 +0100 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <87y7mi840m.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Wed\, 28 Feb 2007 20\:40\:25 +0100") References: <87y7mpm4qw.fsf@latte.josefsson.org> <20070223151340.GI28905@basalt.office.altlinux.org> <87odngorvi.fsf@latte.josefsson.org> <87fy8rq5e2.fsf@latte.josefsson.org> <87y7mi840m.fsf@mid.deneb.enyo.de> Message-ID: <87tzx6rmd4.fsf@latte.josefsson.org> Florian Weimer writes: > * Simon Josefsson: > >> I have no idea what happens if I make any changes on the CVS server >> though, although git-cvsimport claims to support that. > > Incremental conversion seems to work relatively well, especially if > you haven't used broken CVS versions on your repository. > > Note that GIT has one drawback: it doesn't preserve file identity. > Almost all other sytems (except CVS) keep file identity, which means > that some manual work is necessary when you import GIT changesets into > them. The other way round is far easier. Once I make the switch, I don't expect to import changesets back into CVS actively. However, one prerequisite for making the switch to git is a read-only CVS mirror of the git repository (for people who want to continue to use CVS), but if I understand correctly, git-cvsserver takes care of that. Or do these problems apply equally to git-cvsserver? > I believe the HTTP transport is a bit like a stepchild these days. > And I couldn't clone your GIT repostory. It seems to work fine here: jas at mocca:~/t$ git clone git://repo.or.cz/libtasn1.git remote: Generating pack... remote: Done counting 2312 objects. remote: Deltifying 2312 objects. remote: 100% (2312/2312) done Indexing 2312 objects. remote: Total 2312, written 2312 (delta 1572), reused 2312 (delta 1572) 100% (2312/2312) done Resolving 1572 deltas. 100% (1572/1572) done jas at mocca:~/t$ Doesn't it work? /Simon From thresh at altlinux.ru Wed Feb 28 23:33:03 2007 From: thresh at altlinux.ru (Pavlov Konstantin) Date: Thu, 1 Mar 2007 01:33:03 +0300 Subject: [gnutls-dev] HAEDS UP: Moving away from CVS In-Reply-To: <87tzx6rmd4.fsf@latte.josefsson.org> References: <87y7mpm4qw.fsf@latte.josefsson.org> <20070223151340.GI28905@basalt.office.altlinux.org> <87odngorvi.fsf@latte.josefsson.org> <87fy8rq5e2.fsf@latte.josefsson.org> <87y7mi840m.fsf@mid.deneb.enyo.de> <87tzx6rmd4.fsf@latte.josefsson.org> Message-ID: <20070228223303.GA12647@cryo.net.ru> On Wed, Feb 28, 2007 at 10:41:27PM +0100, Simon Josefsson wrote: > > I believe the HTTP transport is a bit like a stepchild these days. > > And I couldn't clone your GIT repostory. > > It seems to work fine here: > > jas at mocca:~/t$ git clone git://repo.or.cz/libtasn1.git > remote: Generating pack... > remote: Done counting 2312 objects. > remote: Deltifying 2312 objects. > remote: 100% (2312/2312) done > Indexing 2312 objects. > remote: Total 2312, written 2312 (delta 1572), reused 2312 (delta 1572) > 100% (2312/2312) done > Resolving 1572 deltas. > 100% (1572/1572) done > jas at mocca:~/t$ > > Doesn't it work? Works fine here too. -- You can never do just one thing. -- Hardin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: