From nmav at gnutls.org Sat Jul 6 23:31:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat Jul 6 23:31:01 2002 Subject: [gnutls-dev]gnutls 0.5.0 Message-ID: <20020706212849.GA18836@gnutls.org> I've just released gnutls 0.5.0 The major news in this release are: - Added X.509 certificate tests in tests/ directory - Removed stubs for SRP and Anonymous authentication. They served no purpose since they are always included, unless it was requested not to do so. - Added gnutls_handshake_set_private_extensions() function. This function can be used to enable private (gnutls specific) cipher suites and compression algorithms. - Added check for C99 macro support by the compiler. - Added functions gnutls_b64_encode_fmt2() and gnutls_b64_decode_fmt2() - Added the new libtasn1 library. - Removed the gdbm backend. Applications are now responsible for the session resuming backend. The gnutls-serv application contains an simple example on how to use gdbm for resuming. - Headers for the gnutls library are now installed in $(includedir)/gnutls - Added an OpenSSL compatible interface (with some limitations). - Added functions to convert DER encoded certificates to XML format. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Wed Jul 10 12:30:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Jul 10 12:30:01 2002 Subject: [gnutls-dev]Re: GNU TLS In-Reply-To: <20020710090453.17381.qmail@brouhaha.com> References: <20020710090453.17381.qmail@brouhaha.com> Message-ID: <20020710103217.GA1349@i-net.gr> On Wed, Jul 10, 2002 at 09:04:53AM -0000, phr-2002 at nightsong.com wrote: > I have one complaint, which is that weak ciphers aren't supported. I > assume this was decided as a political statement. But I think it is a > mistake. That kind of decision should be reserved for the application > developer--a library should not impose it. The issue isn't that the > library user might be subject to crypto restrictions. It's that GNU TLS > is a network communication tool, and the OTHER END of the connection > might be restricted, either legally or by its implementation. > For example, web browsers--even most of the ones installed on US > machines which were permitted to use strong cryptography--almost > entirely used weak cryptography until just a year or two ago. A lot > of those browsers are still being used. A GNU TLS-based web server > without weak cryptography support wouldn't be able to communicate > securely with these browsers. You seem to make an assumption that is not correct. You assume that the 40 bit restricted browsers, offer some security. Actually they do not offer any security at all. It is better to communicate in plain, instead of having a false feeling of security. It is trivial to crack 40 bit protected communications by brute force. > The application developer might decide that for security reasons, it's > best for his/her site to not support such browsers, and simply tell > users to upgrade (for example by downloading the appropriate MSIE > service pack). But THAT IS UP TO THE APPLICATION DEVELOPER. S/he > might decide that weak cryptography is good enough for the specific > data being encrypted. The most common use of SSL on the web is for > credit card numbers, and it's simply not worth the effort of an > attacker brute-forcing a 56-bit (or even 40-bit) encryption key to get > a single card number. Well, I'm not aware of software that cracks 40 bit restricted TLS sessions, but we shouldn't assume that there aren't such programs available in underground communities. One can use a network of general purpose computers to break 40 bit ciphers would in days or (in the worst case) weeks, which does really worth the effort. > Without the possibility of supporting a weak-cryptography client, the > application developer must choose between abandoning the user (most > won't bother upgrading til they get a new computer) or else turning > off TLS entirely and using an unencrypted connection. Many will > choose to turn off TLS, so GNU TLS's attempt to increase security by > omitting weak ciphers will in fact decrease security. As I said, I do not believe that the weak ciphers offer any security. > Similarly, a lot of web SERVERS such as older versions of Microsoft > IIS still use weak cryptography. If GNU TLS is used in a browser, it > won't be able to connect by SSL to such servers. This situation is > even worse than the GNU TLS server case, since the GNU TLS browser > user will usually have no hope of persuading the server operator to > upgrade. So again, s/he'll have to abandon the site or else turn > off TLS. He cannot persuade him, but he should not trust him bussiness anyway. Offering secure services restricted to 40 bit ciphers, is a joke. [I CC'ed the developers mailing list for further comments and discussion] > Regards > Paul Rubin > Fort GNOX Cryptography -- Nikos Mavroyanopoulos From pasky at pasky.ji.cz Wed Jul 10 12:42:02 2002 From: pasky at pasky.ji.cz (Petr Baudis) Date: Wed Jul 10 12:42:02 2002 Subject: [gnutls-dev]Re: GNU TLS In-Reply-To: <20020710103217.GA1349@i-net.gr> References: <20020710090453.17381.qmail@brouhaha.com> <20020710103217.GA1349@i-net.gr> Message-ID: <20020710104322.GG2947@pasky.ji.cz> Dear diary, on Wed, Jul 10, 2002 at 12:32:17PM CEST, I got a letter, where Nikos Mavroyanopoulos told me, that... > > Similarly, a lot of web SERVERS such as older versions of Microsoft > > IIS still use weak cryptography. If GNU TLS is used in a browser, it > > won't be able to connect by SSL to such servers. This situation is > > even worse than the GNU TLS server case, since the GNU TLS browser > > user will usually have no hope of persuading the server operator to > > upgrade. So again, s/he'll have to abandon the site or else turn > > off TLS. > He cannot persuade him, but he should not trust him bussiness anyway. > Offering secure services restricted to 40 bit ciphers, is a joke. I develop browser with support for GNUTLS (parallel to OpenSSL, for legal reasons; thanks for GNUTLS as an alternative!), and I must say that such statements like "he shouldn't use it anyway" are unfortunately a bit far away from reality. Users usually don't care, they just ie. paid some service and just know that they must write "https://" in front of the URL. They don't understand this cypher bussiness at all, they just want to be able to use that service with my browser and no matter what excuses I will make why the browser can't display the page, they will be just upset on me and possibly stop using the browser. By supporting weak cyphers and ie. popping up a warning window that the cypher is too weak and easy to break and if the user really want to proceed, one can educate users, make them ask site admins why such a weak cypher is used etc. If the page is just not displayed, users just think it's some strange paranoia of this browser and that the browser is basically broken, as "it can't display pages other browsers can display". Kind regards, -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . "Capitalism is the extraordinary belief that the nastiest of men, for the nastiest of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ From phr-2002 at nightsong.com Thu Jul 11 11:29:02 2002 From: phr-2002 at nightsong.com (phr-2002 at nightsong.com) Date: Thu Jul 11 11:29:02 2002 Subject: [gnutls-dev]weak cryptography Message-ID: <20020710113304.18476.qmail@brouhaha.com> > A GNU TLS-based web server > without weak cryptography support wouldn't be able to communicate > securely with these browsers. You seem to make an assumption that is not correct. You assume that the 40 bit restricted browsers, offer some security. Actually they do not offer any security at all. I don't agree with this. 40 bit browsers offer some security, enough for some applications but not for others. It is better to communicate in plain, instead of having a false feeling of security. I don't agree with that either. It's like saying it's better to leave your house completely open, than lock the door but use a door weak enough that an attacker can break it with a sledgehammer. Almost every house can be broken into with a sledgehammer but most people do lock their doors and it's better than leaving them open. It is trivial to crack 40 bit protected communications by brute force. It's not trivial and that's easy to prove: if I send you 1000 messages encrypted with 32-bit encryption and offer to pay you 0.10 US dollars for each message you can read, you might take the trouble to set up a few workstations and make an easy 100 USD (it takes about one hour to crack each key on a PC, so you'd let your network run for a few days). But with 40-bit encryption, it takes weeks to crack each one and you probably won't bother. "Too much work to bother", by definition, is non-trivial. And If I offered 100 USD per message, then it would be worth it for 40 bits but probably not 56 bits, and so forth. Well, I'm not aware of software that cracks 40 bit restricted TLS sessions, but we shouldn't assume that there aren't such programs available in underground communities. One can use a network of general purpose computers to break 40 bit ciphers would in days or (in the worst case) weeks, which does really worth the effort. Yes, programs like that are available. 40-bit ciphers are definitely too weak for highly valuable messages. But they are often ok for not-so-valuable messages. If the message is a digital coin worth 0.10 USD, then nobody will spend weeks of CPU time cracking it. So whether the 40-bit cipher is sufficient is completely application specific. As I said, I do not believe that the weak ciphers offer any security. Of course you're entitled to that opinion, but you should not impose the opinion on GNU TLS application programmers who may not feel the same way. They are not necessarily stupid; they know what compromises are involved, and they know more than the library implementer what the value (or lack of value) is of the data they're trying to protect. > even worse than the GNU TLS server case, since the GNU TLS browser > user will usually have no hope of persuading the server operator to > upgrade. So again, s/he'll have to abandon the site or else turn > off TLS. He cannot persuade him, but he should not trust him bussiness anyway. Offering secure services restricted to 40 bit ciphers, is a joke. In some cases (like typical e-commerce) the cryptography is intended to protect the server and not the client. If a user's credit card number gets cracked, it causes some inconvenience for the user but doesn't cost the user money--the user's bank is responsible for the loss. So I personally don't mind entering my credit card into a 40 bit website. If someone cracks it, it's not my problem. I call the bank and they have to pay for it. And if that happens occasionally, the bank doesn't mind either, since covering such occasional losses is part of their cost structure--basically an insurance policy takes care of it and they have already allocated money for the expense. It's just a business problem to them, not a technical one. But if 1000's of numbers are cracked, the bank and the merchant have a big problem. So the issue is not to make sure that no numbers ever get cracked. It's to make sure that 1000's of numbers don't get cracked at once. 40 bit cryptography takes care of that, by making each one take several CPU weeks. It might not sound so nice to risk inconveniencing a user, but remember that if you use your credit card in a restaurant, you're giving it to a low-paid waiter who can copy the numbers directly from the card because there's no encryption at all. Yet everyone does that all the time. This is clearly a type of data that needs some protection, but doesn't need ultra-strong protection. In fact there has never been a single known publicized case of an actual credit card number being stolen by intercepting and decrypting it from a 40 bit SSL web transaction. Part of the reason is TCP/IP traffic is reasonably private to begin with, but mostly it's because if someone wants stolen credit card numbers, there are easier and cheaper ways to get them than by attacking 40 bit SSL traffic. (The usual way to get them is by buying them from a dishonest merchant). Finally, this discussion has mostly been about 40 bits, but for a brief period some exportable browsers and servers supported 56 bit ciphers. I don't know if GNUTLS considers those "weak". In practice, they are breakable, but only with great difficulty, requiring special hardware and/or very large distributed PC networks. You might like to read "Secrets and Lies" by Bruce Schneier for more discussion along these lines. You've probably already read his earlier book "Applied Cryptography". From nmav at gnutls.org Fri Jul 12 06:25:02 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Jul 12 06:25:02 2002 Subject: [gnutls-dev]Re: weak cryptography In-Reply-To: <20020710113304.18476.qmail@brouhaha.com> References: <20020710113304.18476.qmail@brouhaha.com> Message-ID: <20020712041922.GA1737@gnutls.org> On Wed, Jul 10, 2002 at 11:33:04AM -0000, phr-2002 at nightsong.com wrote: > > A GNU TLS-based web server > > without weak cryptography support wouldn't be able to communicate > > securely with these browsers. > You seem to make an assumption that is not correct. You assume that > the 40 bit restricted browsers, offer some security. > Actually they do not offer any security at all. > I don't agree with this. 40 bit browsers offer some security, enough > for some applications but not for others. Having seen this mail and Petr's I see that you've got some point. I should point out however that enabling the so called export-grade ciphers, has an impact to the security of all the ciphersuites. There is a known weakness in the TLS handshake protocol that in brief, makes all the cipher suites vulnerable to a man in the middle attack if the export-grade ciphersuites can be broken fast enough (before the TCP/IP connection expires). This attack is known to the TLS WG. > It is trivial to crack 40 bit protected communications by brute > force. > It's not trivial and that's easy to prove: if I send you 1000 messages > encrypted with 32-bit encryption and offer to pay you 0.10 US dollars > for each message you can read, you might take the trouble to set up a > few workstations and make an easy 100 USD (it takes about one hour to > crack each key on a PC, so you'd let your network run for a few days). > But with 40-bit encryption, it takes weeks to crack each one and you > probably won't bother. "Too much work to bother", by definition, is > non-trivial. I don't agree with these timings, and there is no point in arguing about this, since the time needed is reduced every year. > Finally, this discussion has mostly been about 40 bits, but for a > brief period some exportable browsers and servers supported 56 bit > ciphers. I don't know if GNUTLS considers those "weak". In practice, > they are breakable, but only with great difficulty, requiring special > hardware and/or very large distributed PC networks. Well the special hardware can be easily accessed. Consider the cards that are supposed to offer TLS in hardware. Anyway, I'll think about this. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nspring at cs.washington.edu Mon Jul 15 20:58:02 2002 From: nspring at cs.washington.edu (Neil Spring) Date: Mon Jul 15 20:58:02 2002 Subject: [gnutls-dev]sigpipe behavior changed? Message-ID: <20020715185836.GC9055@cs.washington.edu> Hi all, I've used wmbiff with gnutls for a while now. I've been able to apm suspend my machine, bring it back, and have wmbiff notice that the connection has failed due to timeout and reconnect. Recently, since linking with gnutls 0.4 instead of 0.3.5, wmbiff dies on resume. Looking into it further, it appears that it's taking a sigpipe. Program received signal SIGPIPE, Broken pipe. 0x402748b2 in send () from /lib/libc.so.6 (gdb) where #0 0x402748b2 in send () from /lib/libc.so.6 #1 0x401783b4 in _gnutls_io_write_buffered () from /usr/lib/libgnutls.so.4 #2 0x9bbd3850 in ?? () Cannot access memory at address 0x10315 (gdb) c Continuing. Program terminated with signal SIGPIPE, Broken pipe. The program no longer exists. (gdb) Now, I may have damaged things in the code of wmbiff, and the fix for wmbiff is trivial (call sigaction and ignore the signal). I thought I should post this message to confirm that this is expected behavior, and that the august 26, 2001 entry in the changelog (the only one I can find that mentions signals) does not apply: 2001-08-26 14:44 nmav * acconfig.h (tags: gnutls_0_2_10, gnutls_0_2_9, gnutls_0_2_3), configure.in, lib/gnutls_global.c: use of sigaction instead of signal(), to ignore SIGPIPE My apologies if I'm reporting a bug that has been fixed in 0.5.0. So the question is, is gnutls supposed to ignore sigpipe? thanks, -neil From nmav at gnutls.org Mon Jul 15 21:31:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Jul 15 21:31:01 2002 Subject: [gnutls-dev]sigpipe behavior changed? In-Reply-To: <20020715185836.GC9055@cs.washington.edu> References: <20020715185836.GC9055@cs.washington.edu> Message-ID: <20020715192849.GB902@gnutls.org> On Mon, Jul 15, 2002 at 11:58:37AM -0700, Neil Spring wrote: > Hi all, > I've used wmbiff with gnutls for a while now. I've been able > to apm suspend my machine, bring it back, and have wmbiff > notice that the connection has failed due to timeout and > reconnect. [...] > My apologies if I'm reporting a bug that has been fixed in > 0.5.0. > So the question is, is gnutls supposed to ignore sigpipe? No, and unfortunately this was not properly documented. The change was in gnutls_0_2_11 where gnutls_global_init() was modified to no longer call signal(), to ignore SIGPIPE. I believe it is better that way, because gnutls does not cope with the transport layer directly, and in some applications blocking this signal might break things. In brief the current behaviour of gnutls is not to cope with signals at all. > thanks, > -neil -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Wed Jul 17 18:54:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Jul 17 18:54:01 2002 Subject: [gnutls-dev]gnutls 0.5.1 Message-ID: <20020717165109.GA726@gnutls.org> I've released this morning gnutls 0.5.1. This is mostly a bugfix release. The news are: - Corrected the m4 macros which used instead of - Documentation fixes - Added gnutls_transport_set_ptr2() function, which accepts two different pointers, to be used while receiving, and while sending data. - Semantic changes in gnutls_record_set_max_size(). The requested size is now immediately enforced at the output buffers. - gnutls_global_init_extra() now fails if the library versions do not match. - Fixes in client and server example programs. Null encryption can be used in these programs, to assist in debuging. - Fixes in zlib compression code. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Thu Jul 18 22:46:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu Jul 18 22:46:01 2002 Subject: [gnutls-dev]new tasks Message-ID: <20020718204345.GA14459@gnutls.org> Some tasks I believe they are important for gnutls are: 1. Add support for PKCS-12 encoded certificates and keys 2. Add some support for some of the so called EXPORT ciphersuites I'll try to work on these in some time, which might be a long time, because I do not expect to be able to work before october. So it might be great if anyone could take care any of these tasks. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From wk at gnupg.org Sat Jul 20 13:43:02 2002 From: wk at gnupg.org (Werner Koch) Date: Sat Jul 20 13:43:02 2002 Subject: [gnutls-dev]Re: GNU TLS In-Reply-To: <20020710104322.GG2947@pasky.ji.cz> (Petr Baudis's message of "Wed, 10 Jul 2002 12:43:22 +0200") References: <20020710090453.17381.qmail@brouhaha.com> <20020710103217.GA1349@i-net.gr> <20020710104322.GG2947@pasky.ji.cz> Message-ID: <87heiu62pb.fsf@alberti.gnupg.de> On Wed, 10 Jul 2002 12:43:22 +0200, Petr Baudis said: > the browser. By supporting weak cyphers and ie. popping up a warning window > that the cypher is too weak and easy to break and if the user really want to Nikos, I'd suggest to return a special error message fro weak ciphers so that Petr is able to display a message "for security reasons this browser does not support easy crackable ciphers; see http:foo.bar for more information." Such a message is even an advantage for a browser giving it a repudation of highly being security aware ;-) Salam-Shalom, Werner From nmav at gnutls.org Sat Jul 20 20:04:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat Jul 20 20:04:01 2002 Subject: [gnutls-dev]Re: GNU TLS In-Reply-To: <87heiu62pb.fsf@alberti.gnupg.de> References: <20020710090453.17381.qmail@brouhaha.com> <20020710103217.GA1349@i-net.gr> <20020710104322.GG2947@pasky.ji.cz> <87heiu62pb.fsf@alberti.gnupg.de> Message-ID: <20020720180123.GA2134@gnutls.org> On Sat, Jul 20, 2002 at 01:47:28PM +0200, Werner Koch wrote: > > the browser. By supporting weak cyphers and ie. popping up a warning window > > that the cypher is too weak and easy to break and if the user really want to > Nikos, I'd suggest to return a special error message fro weak ciphers > so that Petr is able to display a message "for security reasons this > browser does not support easy crackable ciphers; see http:foo.bar for > more information." Yes this sounds neat. This is not easy though, since in TLS the client sends its capabilities - and the ciphersuites it supports - and the server responds with the selected ciphersuite. A way to get over this, is to send an exportable ciphersuite as the last in the priority list, and if this one is negotiated then return the error code. PS. I'm leaving for vacations tomorrow, so have a nice summer! > Salam-Shalom, > Werner -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From andrew at mcdonald.org.uk Mon Jul 22 21:30:01 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Mon Jul 22 21:30:01 2002 Subject: [gnutls-dev]Re: Bug#153906: mutt: 'bus error' while connecting to IMAP server (sparc) In-Reply-To: References: Message-ID: <20020722193125.GB691@mcdonald.org.uk> reassign 153906 libgnutls4 forwarded 153906 gnutls-dev at gnupg.org thanks On Mon, Jul 22, 2002 at 12:53:58PM -0500, Jeffrey Sheldon wrote: > > Attempt to run mutt on sparc architecture results in 'bus error' and > termination immediately after IMAP host lookup. Upgrading to libgnutls4 > worked around the problem until a number of automated package updates > were applied days later. This does not occur under i386 arch. A guess at what happened - you had mutt (compiled against gnutls3) and gnutls3 installed. You use imap:// rather than imaps:// (i.e. opportunistic STARTTLS). Mutt didn't work. You then installed libgnutls4 and removed gnutls3. Mutt no longer could load the gnutls module so didn't use TLS. Mutt worked. You then upgraded to a version of mutt which uses gnutls4. Mutt could use the gnutls module and broke again. (As an aside this reminds me about a bug I've reported on mutt-dev but I ought to file in upstream's BTS - you can't rely on the current opportunistic STARTTLS behaviour to give you TLS in the presence of an active attacker). Anyway, the bug itself - it looks like it is in libgnutls itself, or maybe libgcrypt. I'm forwarding this to the gnutls-dev for thoughts. Can you also confirm which version of the Debian gnutls4 or libgnutls4 package you are using? > Starting program: /usr/bin/mutt > Connecting to math.lsu.edu...(no debugging symbols found)...(no debugging symbol > s found)...(no debugging symbols found)...(no debugging symbols found)...(no deb > ugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no debugging symb > ols found)...(no debugging symbols found)... > Program received signal SIGBUS, Bus error. > 0x704483d4 in gcry_md_open () from /usr/lib/libgcrypt.so.1 > (gdb) backtrace > #0 0x704483d4 in gcry_md_open () from /usr/lib/libgcrypt.so.1 > #1 0x704482ac in gcry_md_algo_name () from /usr/lib/libgcrypt.so.1 > #2 0x704482e0 in gcry_md_open () from /usr/lib/libgcrypt.so.1 > #3 0x70401b58 in _gnutls_hash_init () from /usr/lib/libgnutls.so.4 > #4 0x703fdbdc in gnutls_handshake () from /usr/lib/libgnutls.so.4 > #5 0x703b610c in mutt_gnutls_starttls () from /usr/lib/mutt/mutt_ssl_gnutls.so > #6 0x703b5ef0 in mutt_gnutls_starttls () from /usr/lib/mutt/mutt_ssl_gnutls.so > #7 0x000861c0 in mutt_gnutls_starttls () > #8 0x00080dec in imap_open_connection () > #9 0x00080ccc in imap_conn_find () > #10 0x000810c8 in imap_open_mailbox () > #11 0x0004b734 in mx_open_mailbox () > #12 0x000434d8 in main () > #13 0x700d7438 in __libc_start_main () from /lib/libc.so.6 -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From tss at iki.fi Wed Jul 31 18:53:01 2002 From: tss at iki.fi (Timo Sirainen) Date: Wed Jul 31 18:53:01 2002 Subject: [gnutls-dev]const char* to gnutls.h Message-ID: <20020731195437.G22431@irccrew.org> Currently there's char* parameters for setting x509 files. Annoying when I use consts in my own code to pass the file names. Included patch to fix. -------------- next part -------------- diff -ru gnutls-0.5.1-old/includes/gnutls/gnutls.h gnutls-0.5.1/includes/gnutls/gnutls.h --- gnutls-0.5.1-old/includes/gnutls/gnutls.h 2002-07-17 13:54:39.000000000 +0300 +++ gnutls-0.5.1/includes/gnutls/gnutls.h 2002-07-31 19:39:24.000000000 +0300 @@ -256,13 +256,13 @@ int gnutls_certificate_set_dh_params(GNUTLS_CERTIFICATE_CREDENTIALS res, GNUTLS_DH_PARAMS); -int gnutls_certificate_set_x509_trust_file( GNUTLS_CERTIFICATE_CREDENTIALS res, char* CAFILE, +int gnutls_certificate_set_x509_trust_file( GNUTLS_CERTIFICATE_CREDENTIALS res, const char* CAFILE, GNUTLS_X509_CertificateFmt); int gnutls_certificate_set_x509_trust_mem(GNUTLS_CERTIFICATE_CREDENTIALS res, const gnutls_datum *CA, GNUTLS_X509_CertificateFmt); int gnutls_certificate_set_x509_key_file( GNUTLS_CERTIFICATE_CREDENTIALS res, - char *CERTFILE, char* KEYFILE, GNUTLS_X509_CertificateFmt); + const char* CERTFILE, const char* KEYFILE, GNUTLS_X509_CertificateFmt); int gnutls_certificate_set_x509_key_mem(GNUTLS_CERTIFICATE_CREDENTIALS res, const gnutls_datum* CERT, const gnutls_datum* KEY, GNUTLS_X509_CertificateFmt); diff -ru gnutls-0.5.1-old/lib/gnutls_x509.c gnutls-0.5.1/lib/gnutls_x509.c --- gnutls-0.5.1-old/lib/gnutls_x509.c 2002-07-13 00:12:30.000000000 +0300 +++ gnutls-0.5.1/lib/gnutls_x509.c 2002-07-31 19:38:21.000000000 +0300 @@ -1465,7 +1465,7 @@ /* Reads a certificate file */ -static int read_cert_file(GNUTLS_CERTIFICATE_CREDENTIALS res, char *certfile, +static int read_cert_file(GNUTLS_CERTIFICATE_CREDENTIALS res, const char *certfile, GNUTLS_X509_CertificateFmt type) { int siz; @@ -1488,7 +1488,7 @@ /* Reads a base64 encoded CA file (file contains multiple certificate * authorities). This is to be called once. */ -static int read_ca_file(GNUTLS_CERTIFICATE_CREDENTIALS res, char *cafile, +static int read_ca_file(GNUTLS_CERTIFICATE_CREDENTIALS res, const char *cafile, GNUTLS_X509_CertificateFmt type) { int siz; @@ -1513,7 +1513,7 @@ /* Reads PKCS-1 RSA private key file or a DSA file (in the format openssl * stores it). */ -static int read_key_file(GNUTLS_CERTIFICATE_CREDENTIALS res, char *keyfile, +static int read_key_file(GNUTLS_CERTIFICATE_CREDENTIALS res, const char *keyfile, GNUTLS_X509_CertificateFmt type) { int siz; @@ -1550,8 +1550,8 @@ * this function. * **/ -int gnutls_certificate_set_x509_key_file(GNUTLS_CERTIFICATE_CREDENTIALS res, char *CERTFILE, - char *KEYFILE, GNUTLS_X509_CertificateFmt type) +int gnutls_certificate_set_x509_key_file(GNUTLS_CERTIFICATE_CREDENTIALS res, const char *CERTFILE, + const char *KEYFILE, GNUTLS_X509_CertificateFmt type) { int ret; @@ -1661,7 +1661,7 @@ * **/ int gnutls_certificate_set_x509_trust_file(GNUTLS_CERTIFICATE_CREDENTIALS res, - char *CAFILE, GNUTLS_X509_CertificateFmt type) + const char *CAFILE, GNUTLS_X509_CertificateFmt type) { int ret, ret2;