leitang / iksemel Goto Github PK

Would you be willing to relicense iksemel under a BSD license?

What steps will reproduce the problem?
1-a. Login using tls
1-b. Wait for receiving info from the server when usign a tls connection.

What is the expected output? What do you see instead?
Succesfully login using tls and get a timeout when calling to the iks_recv 
function. Instead the login is not succesfull, and if you fix this, the 
iks_recv doesn't get a timeout

What version of the product are you using? On what operating system?
Revision 25 of the trunk on Fedora 9

Please provide any additional information below.
I attached a file to fix this.

What steps will reproduce the problem?
1. ./configure --prefix=/usr
2. make
3. make install

What is the expected output? What do you see instead?
iksemel.pc is installed into /usr/lib/pkgconfig while
on an x86_64 it is expected to be also in /usr/lib64/pkgconfig

What version of the product are you using? On what operating system?
iksemel-1.3 on RHEL5 2.6.18-53.1.4.el5

It seems I would need to implement the SRV standards myself if I use 
iksemel? :/ 

What steps will reproduce the problem?
1.
Current iksemel (trunk) was used for testing against Openfire and Google Talk 
XMPP servers.
2.
The test was performed with iksroster tool with argument -s for secure session. 
The XMPP server requires TLS.
3.
The TLS negotiation failed with both servers.
The TLS negotiation failed with iksemel library configured for
using GnuTLS and also failed with configured with OpenSSL.

In both cases the "TLS handshake" is done without errors
( at leasst no function call return error ), but the first 

read request over secured channel fails.

What is the expected output? What do you see instead?
Expected is the TLS/SALS negotioation is done, instead all combiations of libs 
(GnuTSL and OpenSSL) and destination servers
(Openfire and GoogleTalk) failed.


What version of the product are you using? On what operating system?
iksemel latest version 1.4+ from git repository.
OS, ubuntu 2.6.38-14 and embeded linux an ARM => same faulure


Please provide any additional information below.

Following, both sessions output for OpenSSL and GnuTLS sessions:

--------------------------------------------------------------------
OpenSSL:

SEND[<?xml version='1.0'?><stream:stream 
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' 
to='10.90.6.140' version='1.0'>]
RECV[<?xml version='1.0' encoding='UTF-8'?><stream:stream 
xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" 
from="10.90.6.140" id="a73cb530" xml:lang="en" 
version="1.0"><stream:features><starttls 
xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms 
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mecha
nism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mecha
nism></mechanisms></stream:features>]
SEND[<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>]
RECV[<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>]
TLS OPENSSL: tls_handshake
TLS OPENSSL: my_bio_write: 95 bytes

16 03 01 00 5a 01 00 00 56 03 01 4f ac fc 55 27 
78 32 6d 01 99 c1 09 b0 12 61 e3 30 96 68 bc 73 
e6 19 69 a0 8a 36 80 47 34 1f d0 00 00 28 00 39 
00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f 
00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 
00 06 00 03 00 ff 02 01 00 00 04 00 23 00 00 
TLS OPENSSL: tls_send: [<?xml version='1.0'?><stream:stream 
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' 
to='10.90.6.140' version='1.0'>] 137 bytes
TLS OPENSSL: my_bio_write: 95 bytes

16 03 01 00 5a 01 00 00 56 03 01 4f ac fc 55 27 
78 32 6d 01 99 c1 09 b0 12 61 e3 30 96 68 bc 73 
e6 19 69 a0 8a 36 80 47 34 1f d0 00 00 28 00 39 
00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f 
00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 
00 06 00 03 00 ff 02 01 00 00 04 00 23 00 00 
TLS OPENSSL: tls_recv
TLS OPENSSL: my_bio_write: 95 bytes

16 03 01 00 5a 01 00 00 56 03 01 4f ac fc 55 27 
78 32 6d 01 99 c1 09 b0 12 61 e3 30 96 68 bc 73 
e6 19 69 a0 8a 36 80 47 34 1f d0 00 00 28 00 39 
00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f 
00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 
00 06 00 03 00 ff 02 01 00 00 04 00 23 00 00 

TLS OPENSSL: tls_recv: SSl_read result 1 <== SSL_ERROR_SSL

iksroster: io error

--------------------------------------------------------------------
GnuTLS:

SEND[<?xml version='1.0'?><stream:stream 
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' 
to='10.90.6.140' version='1.0'>]
RECV[<?xml version='1.0' encoding='UTF-8'?><stream:stream 
xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" 
from="10.90.6.140" id="2cb01145" xml:lang="en" 
version="1.0"><stream:features><starttls 
xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms 
xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mecha
nism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mecha
nism></mechanisms></stream:features>]
SEND[<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>]
RECV[<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>]
TLS GNUTLS: tls_handshake
TLS GNUTLS: tls_push: 55 bytes

16 03 01 00 32 01 00 00 2e 03 01 4f ad 00 10 ab 
f2 66 d9 3f e2 d2 60 15 95 ef f5 c2 c7 c7 19 14 
91 dd c2 f3 5f 38 93 4f 71 ef a5 00 00 06 00 0a 
00 05 00 04 02 01 00 

TLS GNUTLS: tls_pull

16 03 01 03 34 

TLS GNUTLS: tls_pull

02 00 00 46 03 01 4f ad 00 10 c3 80 19 37 6a 4c 
97 a3 19 a4 e6 a4 f9 f6 6d e9 37 c0 a5 53 e8 f7 
f3 ee dd 9e 1f b1 20 4f ad 00 10 96 31 0b 0f e8 
82 4a 50 c7 7f f1 42 36 45 98 81 ef 05 f5 8e 10 
9b e1 7a ab be 58 f5 00 0a 00 0b 00 02 e2 00 02 
df 00 02 dc 30 82 02 d8 30 82 01 c0 a0 03 02 01 
02 02 08 67 bd 0d b9 b4 2c 66 23 30 0d 06 09 2a 
86 48 86 f7 0d 01 01 05 05 00 30 16 31 14 30 12 
06 03 55 04 03 0c 0b 31 30 2e 39 30 2e 36 2e 31 
34 30 30 1e 17 0d 31 32 30 32 31 30 31 31 30 30 
35 38 5a 17 0d 31 37 30 31 31 34 31 31 30 30 35 
38 5a 30 16 31 14 30 12 06 03 55 04 03 0c 0b 31 
30 2e 39 30 2e 36 2e 31 34 30 30 82 01 22 30 0d 
06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 
0f 00 30 82 01 0a 02 82 01 01 00 c7 da cc cf 72 
8c 85 75 03 ee 1b 90 90 8f cd f2 db a0 14 fc bc 
ed 74 28 a5 21 e0 52 7f f6 41 45 fa 17 95 f9 16 
02 6b c4 e7 93 f2 3c be a8 34 ab b5 79 12 28 ba 
39 43 18 44 4a bf a1 ac 43 7a 94 7b 9f c9 4d 00 
bb 93 c0 dd 70 e3 b4 75 b4 3e 33 b5 a0 24 67 d0 
a3 52 43 60 89 5c 4b ce b3 be fa 4c 80 6e fa 87 
5d bf c9 d6 e7 35 44 36 88 aa ef f8 50 a3 3d 16 
bd 12 28 59 8d 0d fa 1d f8 64 03 b4 96 2e ff 56 
41 17 93 44 cf 7a 75 42 f9 c8 2d b2 4c 1b 12 35 
fb 1d 45 e0 62 5b 1a d1 4b d3 4b 91 94 49 74 4a 
24 1e 58 06 d5 06 f2 87 ab eb 44 06 6f 4d 6d d8 
6d eb b3 22 68 37 7b 8b cc f5 18 5b 39 1b 8d 07 
da 7f 53 a6 99 7e 78 56 64 ad 5c c4 94 a7 d3 3e 
a4 c9 d2 37 c6 3c 73 49 60 54 ea 40 ef 41 ff 32 
d7 77 6b ab b9 0b bd f7 72 50 fc ca 7a 26 34 43 
99 79 60 5f ec 32 3c 0b 51 64 cb 02 03 01 00 01 
a3 2a 30 28 30 26 06 03 55 1d 11 04 1f 30 1d a0 
1b 06 08 2b 06 01 05 05 07 08 05 a0 0f 0c 0d 2a 
2e 31 30 2e 39 30 2e 36 2e 31 34 30 30 0d 06 09 
2a 86 48 86 f7 0d 01 01 05 05 00 03 82 01 01 00 
70 fe fb a5 9e 0c 6f 51 4c 4e b9 e9 fa 4f 75 b6 
ec da 25 c7 e5 c0 13 6e 99 0a 08 67 f9 e1 48 dd 
19 62 7d 94 eb 86 bd 41 6d c8 ae e6 06 1b 98 44 
77 b6 8c 1a d8 6d bc b0 ee e8 2b bf a8 99 10 2a 
ce cc e3 81 ee 0f 7a 41 f6 27 3c c8 9a b9 32 0c 
48 7d 33 09 ce af b2 5a 13 01 d0 a7 b4 f9 80 96 
20 8b 87 95 cc 67 78 b6 e5 68 6a e5 27 7c 15 39 
15 54 b3 82 9e b0 27 c4 fe 72 9e 6b e2 c7 54 5e 
41 b3 f6 dc 00 ff 7d 1a 3d 82 cd 8c fc b3 96 8f 
f1 f3 46 5e 8d 62 33 3f c2 ab 78 66 b9 00 51 88 
ee 0a 2b 99 95 46 9d 4b e8 94 fe f8 e2 39 88 0e 
57 30 b0 31 93 89 ed c8 08 05 2e 76 08 92 99 3a 
10 40 79 70 b3 e7 70 a3 c6 c4 af 06 60 81 60 64 
2f 5b 09 99 f0 d2 fa c0 17 5f ac 85 d5 04 38 e1 
6f 8b 7f 97 1f 0d 90 57 e5 df bd 2d 31 f3 55 85 
86 d2 6b b0 3a 29 4e 18 e5 b6 a4 b8 3d 5a 0c 7b 
0e 00 00 00 

TLS GNUTLS: tls_push: 267 bytes

16 03 01 01 06 10 00 01 02 01 00 53 c6 71 b0 a9 
e9 9d 5e 73 e6 0a bd 45 e2 88 5b 8b 52 38 d4 4e 
6c d4 ef 49 db dd e1 3c 33 65 1b 03 5d 51 36 74 
bc d3 7e a8 d2 7b 82 95 4a a4 b8 a3 18 88 4a 5a 
68 ac 47 87 3f cd 50 c3 24 c2 43 26 d3 08 06 d1 
cd bc 34 c8 bc 67 7d 68 e3 95 b0 51 4c 6e cf 8c 
81 6d 48 54 2c 2e 8d 74 1f ac 29 69 c4 8f e7 c6 
80 98 7a bb 7b fd 0b 38 10 87 5c 84 23 75 e6 19 
0d e2 74 02 17 ff aa b6 81 a8 e7 55 ea e5 b6 ea 
87 74 f6 bf 8b 12 4b e4 99 06 3b 06 27 12 e3 16 
9a 8b d9 c4 01 ca d2 b3 2f eb 74 11 72 5a 71 9a 
a9 80 81 53 bc 12 26 70 17 22 00 da 79 1f 85 f2 
16 cf 80 d8 2b d9 8a ba 06 a4 e0 6e f1 9e 93 6f 
06 85 65 88 2d 3b 81 e3 3c f2 b4 e5 49 27 9d 67 
85 de 89 c4 53 d3 a8 78 b8 15 0d 5f 8f a5 37 c8 
92 c2 98 48 17 32 e5 b5 07 25 69 21 6a e8 5a d5 
13 9b 26 75 59 a3 33 3e e3 e7 b2 

TLS GNUTLS: tls_push: 6 bytes

14 03 01 00 01 01 

TLS GNUTLS: tls_push: 45 bytes

16 03 01 00 28 f5 75 44 9f b3 df 21 cf 2f e2 9d 
4e 61 b3 b6 4d 0b ca bf 00 42 8d af 0c 37 62 fa 
97 58 25 d4 9e e3 e8 a5 cb 12 1d 7d f7 

TLS GNUTLS: tls_pull

14 03 01 00 01 

TLS GNUTLS: tls_pull

01 

TLS GNUTLS: tls_pull

16 03 01 00 28 

TLS GNUTLS: tls_pull

09 a7 ef c6 01 2a e8 80 1f 0f 73 30 df 89 44 7f 
a8 c6 c2 7c e8 f7 c2 8f f6 9f d7 62 e5 5d e9 e0 
47 6c c5 17 e6 3f 8c 58 

TLS GNUTLS: tls_send: [<?xml version='1.0'?><stream:stream 
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' 
to='10.90.6.140' version='1.0'>] 137 bytes
TLS GNUTLS: tls_push: 253 bytes

17 03 01 00 f8 d4 75 17 4a 71 d4 1b f7 6e 5d 66 
32 61 b6 c6 df a0 de 75 2b b9 74 93 52 8e ba ab 
7f 66 a2 d4 5c eb 27 c7 03 ba 20 1a d6 7f d2 e9 
03 81 ee e5 59 9a 75 0f df 65 ee 0e de af 2f f5 
44 f2 7d 18 e7 4a 56 3c ca 21 4f d0 92 8e 71 7c 
d8 29 06 88 b0 d0 b0 54 bc a6 0f 7f c3 4d 79 f4 
c9 98 f7 b8 53 f0 7f 67 57 e6 d3 3e 0a 70 53 54 
c4 bd 9b 39 b6 d9 9f ad 1f aa f9 a0 e3 82 41 ad 
43 06 62 7d c8 14 3c 6c 6f bc 3b 54 ab 8e c6 f8 
f4 da a5 ab f2 28 c5 22 8f 08 b9 97 35 d5 11 5e 
68 3f 03 26 27 37 ba af e5 36 f5 9a 5e 6b a8 8d 
5d 02 45 69 5f 42 90 3e c0 f1 ba 60 e0 d3 1d f8 
8e 44 5d a8 00 0c ba 48 3e 42 e4 d3 41 be 57 7a 
55 4d 5a 35 65 db b0 b9 1c ff 0c a1 3f ca 8c c4 
25 42 26 46 ae a5 aa cc ac c7 43 74 41 26 51 c3 
45 44 25 c3 68 48 9d 77 bc df af b2 16 

SecSEND[<?xml version='1.0'?><stream:stream 
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' 
to='10.90.6.140' version='1.0'>]
TLS GNUTLS: tls_recv
TLS GNUTLS: tls_pull

16 03 01 00 28 

TLS GNUTLS: tls_recv: ret: -9 <== GNUTLS_E_UNEXPECTED_PACKET_LENGTH /* 
GNUTLS_A_RECORD_OVERFLOW */

iksroster: io error

md5.c -> iks_md5_new uses malloc instead of iks_malloc and also uses free
instead of iks_free 

What steps will reproduce the problem?
1. Compile iksemel on an amd64 architecture
2. There should be many "cast from pointer to integer of different size" 
compilation warnings

What is the expected output? What do you see instead?
Those warnings betray void* -> int casts.

What version of the product are you using? On what operating system?
1.4 on FreeBSD 8.0/amd64

Please provide any additional information below.
void* could be casted to long int instead, thus ajusting themselves to the 
right size (but what about architectures with sizeof(long int) = 4 and 
sizeof(void *) = 8?).

What steps will reproduce the problem?
1. Compile version 1.4 or trunk
2. Run iksroster example with "-s -a -l" against openfire 3.7 server
3. TSL fails for trunk but is successful in 1.4.  SASL fails in both versions.

What is the expected output? What do you see instead?
Expected TLS and SASL success in trunk.

What version of the product are you using? On what operating system?
Using trunk but tested 1.4 and even 1.3.  Ubuntu natty.

Please provide any additional information below.
OpenFire 3.7

I successfully compiled it, but it wasn't able to connect to a server.
The bug was in 2 lines.

Please check lines #137 and #142

I changed it to:
#137 if (sess->features & IKS_STREAM_SESSION) {
#142 if (sess->features & IKS_STREAM_BIND) {

And now example works. :)

What steps will reproduce the problem?
Openfire 3.9.3
Debian 7.6
Try to connect to openfire with iksemel.
Openfire seems to send all TLS-encrypted data, spread into two Application-Data 
packets, where -after decrypting- the first one seems to include only the first 
character (usually '<').

What is the expected output? What do you see instead?
Iksemel should read both Application-Data packets, concatenate the included 
parts of the XML and parse the resulting string.
Unfortunately iksemel reads the first packet and tries to parse it's payload, 
which fails ('<'). After that it reads the second packet and tries to parse the 
resulting string, which results in the first XML-Tag missing (because the '<' 
is missing).
If the message contained of an XML with only one Tag, the result is empty.

What version of the product are you using? On what operating system?
iksemel 1.4 (not the Debian-version!)
Debian 7.6

Please provide any additional information below.
Patch for git-HEAD attached (only solves the issue, where the message is 
splitted after the first few characters).

Please consider including the attached patch or find a more complete way of 
fixing this issue

Best Regards,
Markus

What steps will reproduce the problem?
1. Connect with server.
2. Kill server.
3. libiksemel says that everything is ok.

What is the expected output? What do you see instead?
I expect information that remote server died, instead I don't see it.


What version of the product are you using? On what operating system?
1.2 on Ubuntu Hardy, but code in svn version of io_send is the same.


Please provide any additional information below.
Attached patch resolves this problem, and moreover sends all data which
have to be send, not only a part (it's not guaranted that send will send
all data, so it should be used in loop)

For connecting to google server "iks_connect_via" must be used
which is not documented. The "iks_connect_tcp" which is documented is not
usable.

What can be done here:
Include iks_connect_via in documentation 

I used following SAX parser given in iksemel.pdf

code:
//---------------------------------------------------------
// file name : test_sax.c

#include <stdio.h>
#include <iksemel.h>
int pr_tag (void *udata, char *name, char **atts, int type)
{
    switch (type) {
        case IKS_OPEN:
            printf ("TAG <%s>\n", name);
            break;
        case IKS_CLOSE:
            printf ("TAG </%s>\n", name);
            break;
        case IKS_SINGLE:
            printf ("TAG <%s/>\n", name);
            break;
    }
    if (atts) {
        int i = 0;
        while (atts[i]) {
            printf (" ATTRIB %s=’%s’\n", atts[i], atts[i+1]);
            i += 2;
        }
    }
    return IKS_OK;
}
enum ikserror pr_cdata (void *udata, char *data, size_t len)
{
    int i;
    printf ("CDATA [");
    for (i = 0; i < len; i++)
        putchar (data[i]);
    printf ("]\n");
    return IKS_OK;
}
int main (int argc, char *argv[])
{
    iksparser *p;
    p = iks_sax_new (NULL, pr_tag, pr_cdata);
    switch (iks_parse (p, argv[1], 0, 1)) {
        case IKS_OK:
            puts ("OK");
            break;
        case IKS_NOMEM:
          puts ("Not enough memory");
          exit (1);
      case IKS_BADXML:
          puts ("XML document is not well-formed");
          exit (2);
      case IKS_HOOK:
          puts ("Our hooks didn’t like something");
          exit (2);
  }
  iks_parser_delete (p);
  return 0;
}
//----------------------------------------------------------
code ends

I compile the code as

#gcc test_sax.c -o test_sax -l iksemel

then execute as

#./test_sax "<status>ptr -&gt; /dev/null</status>"

output

TAG <status>
CDATA [ptr -]
CDATA [>]
CDATA [ /dev/null]
TAG </status>
OK


I think output should look like

TAG <status>
CDATA [ptr -> /dev/null]
TAG </status>
OK

Precisely this is the output of program when I run it as

#./test_sax "<status>ptr -> /dev/null</status>"

output

TAG <status>
CDATA [ptr -> /dev/null]
TAG </status>
OK

What steps will reproduce the problem?
1. In sax_core (iksparser *prs, char *buf, int len)
2. When attribute multiples of 12

code in sax.c:388: 
prs->atts[prs->attcur] = NULL;
this will lead a invalid write.

replace the line in sax.c:358
if (prs->attcur >= (prs->attmax * 2)) 
with this:
if (prs->attcur >= ((prs->attmax - 1)* 2)) 

I found this bug on my Fedora 7 machine. I confirmed this on Ubuntu 8.04
machine too.

Installation of iksemel 1.3 fails on x86_64 machine.  See below the error 
generated by make check:

Any idea?

PASS: tst-ikstack
PASS: tst-iks
Sax test 3, blocksize 0, element 1:
  Expecting tag <mytag>
    abc='123'
    id='XC72'
/bin/sh: line 4:  3395 Segmentation fault      ${dir}$tst
FAIL: tst-sax
PASS: tst-dom
PASS: tst-sha
PASS: tst-md5
PASS: tst-filter
PASS: tst-jid
===================

Hello, 
Functions from sha.c doesn't work properly on 64-bit architecture, because
there is used 'unsigned long' (which is 8-bytes long on 64 and 4-bytes on
32). The way to repair it is to use uint32_t (from stdint.h) instead of
unsigned long. I simply replaced all occurences of 'unsigned long' with
'uint32_t' and now library seems working ok.

What steps will reproduce the problem?
1. provide ikstransport working around Debian #511808, i.e. that will do a
select() before any read() and return -1 + errno=EAGAIN if nothing
available to be read when the  read function is called
2. connect to an XMPP server supporting starttls and get the ssl handshake
triggered
3. GnuTLS wants to read data during the handshake that has not arrived yet
4. read returns -1 and errno=EAGAIN
5. gnutls_handshake() returns GNUTLS_E_AGAIN
6. libiksemel considers the handshake to have failed and closes the connection

What is the expected output? What do you see instead?
libiksemel should be able to cope with network latency (without blocking).

What version of the product are you using? On what operating system?
Irrelevant.

Please provide any additional information below.
Here's the fix (including fixes from Debian#511808):

diff -rU2 iksemel-1.3/src/stream.c libiksemel-1.3/src/stream.c
--- iksemel-1.3/src/stream.c    2007-08-02 12:45:10.000000000 +0200
+++ libiksemel-1.3/src/stream.c 2009-03-03 20:24:35.000000000 +0100
@@ -15,4 +17,5 @@
 #define SF_TRY_SECURE 2
 #define SF_SECURE 4
+#define SF_HS_SECURE_IP 8

 struct stream_data {
@@ -34,4 +37,5 @@
        gnutls_session sess;
        gnutls_certificate_credentials cred;
+       int timeout;
 #endif
 };
@@ -56,10 +60,34 @@
        int ret;

-       ret = data->trans->recv (data->sock, buffer, len, -1);
+       ret = data->trans->recv (data->sock, buffer, len, data->timeout);
        if (ret == -1) return (size_t) -1;
        return ret;
 }

 static int
+handshake_continue (struct stream_data *data)
+{
+       int ret = gnutls_handshake (data->sess);
+       if (ret != 0) {
+               if  (ret == GNUTLS_E_AGAIN || ret == GNUTLS_E_INTERRUPTED) {
+                       return IKS_OK;
+               }
+               gnutls_deinit (data->sess);
+               gnutls_certificate_free_credentials (data->cred);
+               return IKS_NET_TLSFAIL;
+       }
+
+       data->flags &= (~SF_TRY_SECURE);
+       data->flags &= ~SF_HS_SECURE_IP;
+       data->flags |= SF_SECURE;
+
+       iks_send_header (data->prs, data->server);
+
+       return IKS_OK;
+}
+
+static int
 handshake (struct stream_data *data)
 {
@@ -87,22 +113,13 @@
        gnutls_mac_set_priority(data->sess, mac_priority);
        gnutls_credentials_set (data->sess, GNUTLS_CRD_CERTIFICATE,
data->cred);
+
+       data->timeout = -1;

        gnutls_transport_set_push_function (data->sess, (gnutls_push_func)
tls_push);
        gnutls_transport_set_pull_function (data->sess, (gnutls_pull_func)
tls_pull);
        gnutls_transport_set_ptr (data->sess, data->prs);
-
-       ret = gnutls_handshake (data->sess);
-       if (ret != 0) {
-               gnutls_deinit (data->sess);
-               gnutls_certificate_free_credentials (data->cred);
-               return IKS_NET_TLSFAIL;
-       }
-
-       data->flags &= (~SF_TRY_SECURE);
-       data->flags |= SF_SECURE;
-
-       iks_send_header (data->prs, data->server);
-
-       return IKS_OK;
+       data->flags |= SF_HS_SECURE_IP;
+
+       return handshake_continue (data);
 }
 #endif
@@ -489,5 +506,11 @@
        while (1) {
 #ifdef HAVE_GNUTLS
-               if (data->flags & SF_SECURE) {
+               if (data->flags & SF_HS_SECURE_IP) {
+                       ret = handshake_continue (data);
+                       if (ret != IKS_OK)
+                               return IKS_NET_TLSFAIL;
+                       len = 0;
+               } else if (data->flags & SF_SECURE) {
+                       data->timeout = timeout;
                        len = gnutls_record_recv (data->sess, data->buf,
NET_IO_BUF_SIZE - 1);
                } else

`tst-ikstack` fails on 

armel:
    https://buildd.debian.org/status/fetch.php?pkg=libiksemel&arch=armel&ver=1.4-1&stamp=1410595861

armhf:
    https://buildd.debian.org/status/fetch.php?pkg=libiksemel&arch=armhf&ver=1.4-1&stamp=1410596358

mips:
    https://buildd.debian.org/status/fetch.php?pkg=libiksemel&arch=mips&ver=1.4-1&stamp=1410591397

mipsel:
    https://buildd.debian.org/status/fetch.php?pkg=libiksemel&arch=mipsel&ver=1.4-1&stamp=1410590338

powerpc:
    https://buildd.debian.org/status/fetch.php?pkg=libiksemel&arch=powerpc&ver=1.4-1&stamp=1410589888

sparc:
    https://buildd.debian.org/status/fetch.php?pkg=libiksemel&arch=sparc&ver=1.4-1&stamp=1410594686

Please advise.

On most systems the strdup function (used in utility.c) calls the internal 
malloc function. On embedded systems with there own heap management this would 
not work like expected. This patch fix the issue and the defined iks_malloc 
function is used. 

What steps will reproduce the problem?
1.I tried to run xmpp client using HTTP proxy, but couldn't pass through the 
proxy. It always connect to 5222 port with XMPP server. 


Please provide any additional information below.

Hi, I've just added 1.3 to Gentoo Portage but there is a long unresolved
issue that would need your attention,

$ LD_LIBRARY_PATH="/tmp/iksemel-1.3/src/.libs:$LD_LIBRARY_PATH" gdb ./tst-sax 

GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /tmp/iksemel-1.3/test/.libs/tst-sax 
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7fff20dfd000
Sax test 3, blocksize 0, element 1:
  Expecting tag <mytag>
    abc='123'
    id='XC72'

Program received signal SIGSEGV, Segmentation fault.
0x00002add8ae28cc0 in strlen () from /lib/libc.so.6
(gdb) bt
#0  0x00002add8ae28cc0 in strlen () from /lib/libc.so.6
#1  0x00002add8adf7e10 in vfprintf () from /lib/libc.so.6
#2  0x00002add8adfda1a in printf () from /lib/libc.so.6
#3  0x0000000000400e1c in debug_tag (type=IKS_OPEN, name=0x6042a0 "mytag", 
    atts=0x604330) at tst-sax.c:123
#4  0x00000000004010ac in tagHook (udata=<value optimized out>, 
    name=0x6042a0 "mytag", atts=0x604330, type=<value optimized out>)
    at tst-sax.c:169
#5  0x00002add89f7bb51 in iks_parse (prs=0x604200, 
    data=0x401d00 "<mytag abc='123' id=\"XC72\"></mytag>", 
    len=<value optimized out>, finish=<value optimized out>) at sax.c:324
#6  0x0000000000400c43 in test_size (blocksize=550816680) at tst-sax.c:228
#7  0x0000000000400cea in test () at tst-sax.c:253
#8  0x000000000040142f in main (argc=<value optimized out>, 
    argv=<value optimized out>) at tst-sax.c:299
(gdb)

This is x86_64 system with GCC 4.2.2.

We have problem that special xlm characters (i.e > < &) are not parsed
correctly when read as attribute. When data is sent as CDATA it works fine.
So when reading (iks_load) and writing (iks_save) the same xml file the
data is corrupted since the iks_load handle the & correct.

What steps will reproduce the problem?
1. Create an XML file with data
foo attribe bar="M&M" CDATA=N&N  frotz CDATA=1
<test><foo bar="M&amp;M">N&amp;N</foo><frotz>1</frotz></test>
2. Read the file an only change data in frotz from 1 to 2
3. The result will be
<test><foo bar="M&amp;amp;M">N&amp;N</foo><frotz>2</frotz></test>

What is the expected output? What do you see instead?
The expected output would be
<test><foo bar="M&amp;M">N&amp;N</foo><frotz>2</frotz></test>

What version of the product are you using? On what operating system?
1.2 on Linux (See no changes in 1.3)

Hello, 
Functions from sha.c doesn't work properly on 64-bit architecture, because
there is used 'unsigned long' (which is 8-bytes long on 64 and 4-bytes on
32). The way to repair it is to use uint32_t (from stdint.h) instead of
unsigned long. I simply replaced all occurences of 'unsigned long' with
'uint32_t' and now library seems working ok.

What steps will reproduce the problem?
1. Enable MD5 authorization
2. Issue login/logout
3. Determine memory allocated
4. Issue login/logout
5. Determine memory allocated

What is the expected output? What do you see instead?

I expected no more memory allocated at step 5 than in step 3.
What I saw was a 548 byte memory leak.

What version of the product are you using? On what operating system?

Version 1.4 (according to README) on an embedded system.

Please provide any additional information below.

The node processed in tagHook() in stream.c is normally released
by the user supplied routine that is processing the node. But for
the special case of an MD5 challenge, the node is processed locally
and never released. So you end up leaking a node.

Fix:

--- os-tcp-arm/modules/iksemel/src/stream.c     (revision 1711)
+++ os-tcp-arm/modules/iksemel/src/stream.c     (working copy)
@@ -303,8 +303,10 @@
                        }
                        if (NULL == iks_parent (x)) {
                                data->current = NULL;
-                               if (iks_strcmp (name, "challenge") == 0)
-                                       iks_sasl_challenge(data, x);
+                               if (iks_strcmp (name, "challenge") == 0) {
+          iks_sasl_challenge(data, x);
+          iks_delete(x) ;
+        }
                                else if (iks_strcmp (name, "stream:error")
== 0) {
                                        err = data->streamHook
(data->user_data, IKS_NODE_ERROR, x);
                                        if (err != IKS_OK) return err;

Hi,

For the time being iksemel lib doesn't support "invisible" status, i wonder if 
there is a projection to implement this ??

Best regards.

The current trunk code doesn't handle correctly the timeout parameter. When
the timeout expires, "tls_pull" returns 0 (the number of read bytes) but
gnutls interpreters it as the TCP connection was closed. 

To make it behave correctly you have to use errno EAGAIN when returning
from "tls_pull". This change has been made directly to the "io_recv" so
that it behaves correctly in any situation (with or without TLS).

A patch (against r25) is attached to correct this wrong behaviour. It
should be correct.

I see there is a similar problem (with patch) in Issue 10, but the one
attached here is against current trunk.

What steps will reproduce the problem?
1. Get source from SVN
2. ./autogen.sh
3. ./configure

What is the expected output? What do you see instead?
Succesfully created Makefiles

./configure: line 19878: syntax error near unexpected token `GNUTLS,'
./configure: line 19878: `PKG_CHECK_MODULES(GNUTLS, gnutls >= 2.0.0, 
have_gnutls=yes, have_gnutls=no)'

What version of the product are you using? On what operating system?
SVN r25 on Centos 5.6

Please provide any additional information below.
autoconf-2.59-12
automake-1.9.6-2.3.el5
gnutls-1.4.1-3.el5_4.8
libtool-1.5.22-7.el5_4

What steps will reproduce the problem?
1.Trying to use asterisk from Gtalk to internal SIP

What version of the product are you using? On what operating system?
I'm on debian sqeeze, with libiksemel3 (1.2-4) package, but also with compiled 
version from lastest sources can  reproduce the problem.
The Android version is Android IceCream Sandiwch 4.0 with Google Talk 
4.0.3-239410 (330)


Essentially iksemel can't parse the android client data, the error from 
asterisk is "chan_gtalk.c:2005 gtalk_parser: No attribute "type" found.  
Ignoring message."

the problem is that "iks_find_attrib(pak->query, "type")" returns null

I attach the full log with some Android client data.

I'm pretty sure that it is an iksemel issue (or/combined with Android client 
issue) because with emphaty from desktop with the same google account there are 
no problems.

(sorry for my bad english)

iks_recv() dose not time-out when TLS is on. 

This patch fix two missing pointer checks.

This patch will add a -p|--plain flag to ikroster to allow it to support
plain text authentication.

This is based off of SVN trunk

What steps will reproduce the problem?
1. Use CentOS 5, install iksemel.
2.
3.

What is the expected output? What do you see instead?
If openssl is installed, should not give any error. Instead, it gives,the 
following.
"[Jun 17 13:01:00] ERROR[10136]: res_jabber.c:889 aji_act_hook: OpenSSL not 
installed. You need to install OpenSSL on this system, or disable the TLS 
option in your configuration file
[Jun 17 13:01:00] WARNING[10136]: res_jabber.c:695 aji_recv: Parsing failure: 
Hook returned an error.
[Jun 17 13:01:00] WARNING[10136]: res_jabber.c:1937 aji_recv_loop: JABBER: Got 
hook event."

What version of the product are you using? On what operating system?
1.4

Please provide any additional information below.
Openssl is installed in the system. If I just type openssl, it comes up with 
the openssl terminal
i.e, 
---------------------------------
[root@localhost iksemel]# openssl
OpenSSL>
---------------------------------

This however works on FC8 correctly.

When multi-byte UTF-8 sequences in attribute names or values are passed to
iks_parse() across two or more invocations, the resulting DOM tree fails to
retain the complete UTF-8 sequences, rather it contains invalid UTF-8
sequences.

To observe the problem:
1. Declare an XML string constant that contains UTF-8 text in attribute
value, say:  <a b="田"/>
2. Pass the XML string to iks_parse() one byte at a time.
3. Examine the DOM tree.  The value of attribute "b" contains an invalid
UTF-8 sequence.

The expected value of attribute "b" should be "田".

This bug is present in trunk, and happens regardless of the OS.

The attached patch fixes the problem by detecting orphaned UTF-8 sequences
and pushing them onto the stack.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

I copied all library files from .libs to my directory of libiks after 
I compiling the source code of iksemel-1.4.tar.gz.    
And then when I compile the  codes like this：
gcc -g test.c sax.c utility.c ikstack.c  -o test  -L/opt/myp/libiks
It came out with a lot of warnings such as follows：

test.c: In function ‘main’:
test.c:56: warning: passing argument 3 of ‘iks_sax_new’ from incompatible 
pointer type
sax.c: In function ‘iks_sax_new’:
sax.c:83: warning: incompatible implicit declaration of built-in function 
‘memset’
sax.c: In function ‘iks_sax_extend’:
sax.c:97: warning: incompatible implicit declaration of built-in function 
‘memset’
sax.c: In function ‘stack_expand’:
sax.c:159: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c: In function ‘sax_core’:
sax.c:311: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:320: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:327: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:367: warning: incompatible implicit declaration of built-in function 
‘memset’
sax.c:375: warning: incompatible implicit declaration of built-in function 
‘memset’
sax.c:376: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:389: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:396: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:438: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:450: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c:619: warning: incompatible implicit declaration of built-in function 
‘memcpy’
sax.c: In function ‘iks_parse’:
sax.c:631: warning: incompatible implicit declaration of built-in function 
‘strlen’
utility.c: In function ‘iks_malloc’:
utility.c:21: warning: incompatible implicit declaration of built-in function 
‘malloc’

at last I found may be a bug existed in common.h:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif


I changed the first line to   #ifndef HAVE_CONFIG_H
then the all warnings went away.

Sorry for my bad English. Best regards!

What steps will reproduce the problem?
1. take a text of mod 64 len
2. use iks_md5_hash/print functions to generate an md5 hash

What is the expected output? What do you see instead?
A correct md5 hash

What version of the product are you using? On what operating system?
The last revision of the trunk

Please provide any additional information below.
I used the test code attached to verify the calculation of the md5 function 
comparing it with the openssl functions.

What steps will reproduce the problem?
1.start asterisk
2.
3.

What is the expected output? What do you see instead?

asterisk[1063]: segfault at 0 ip 00007f117aee122d sp 00007fffbc398990 error 4 
in libiksemel.so.3.1.1[7f117aed8000+d000]


What version of the product are you using? On what operating system?
iksemel-1.4-4.fc17.x86_64.rpm

Fedora 17

Please provide any additional information below.

What steps will reproduce the problem?
1. Create a document with the following data

   <data><![CDATA[[TEST]]]></data>

What is the expected output? What do you see instead?

Expected is that Character data of the data node is "[TEST]"

The datahook returns "[TEST" instead. 

What version of the product are you using? On what operating system?

N/A

Please provide any additional information below.

This should fix the problem:


            case C_SECT_CDATA_E2:
                if ('>' == c) {
                    old = pos + 1;
                    prs->context = C_CDATA;
                } else {
                    old = pos;
                    if (']' == c)
                    {
                        prs->context = C_SECT_CDATA_E2;
                        if (prs->cdataHook) {
                            err = (ikserror)prs->cdataHook (prs->user_data, "]", 1);
                            if (IKS_OK != err) return err;
                        }

                    }
                    else
                    {
                        prs->context = C_SECT_CDATA_C;
                        if (prs->cdataHook) {
                            err = (ikserror)prs->cdataHook (prs->user_data, "]]", 2);
                            if (IKS_OK != err) return err;
                        }
                    }
                }
                break;

Ipv6 is enabled in my machine and getaddrinfo returns the ipv6 address first. 
Since it is a valid address the socket function does not fail but the connect 
function fails because the jabber server is not listening on ipv6. As a result, 
the library does not attempt to connect on the ipv4 address and fails to 
connect to the server. The library try the second address only if the socket 
function fails.

When JID is 31 characters long (or more), authetication fails. Example jid 
which causes failure: [email protected], 
9999@@kotikokki-dev.mydom.local works fine.

Tested with iksemel-1.4/tools/iksroster + our own code.

What steps will reproduce the problem?
1. autoreconf configure.ac
2. ./configure


What is the expected output? What do you see instead?
Successful build,I see failure

What version of the product are you using? On what operating system?
Ubuntu 10.04

Please provide any additional information below.

julius@ubuntu:~/Downloads/iksemel-1.4$ autoreconf configure.ac 
configure.ac:48: warning: macro `AM_PATH_LIBGNUTLS' not found in library
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:48: warning: macro `AM_PATH_LIBGNUTLS' not found in library

julius@ubuntu:~/Downloads/iksemel-1.4$ ./configure
.
.
.
checking for struct stat.st_blksize... yes
checking for library containing recv... none required
checking for getopt_long... yes
checking for getaddrinfo... yes
./configure: line 11035: syntax error near unexpected token `,'
./configure: line 11035: `AM_PATH_LIBGNUTLS(,'

On my system gnutls-2.8.5 is installed. This is the output of configure:

checking for libgnutls - version >= 0.1.0... no
*** The libgnutls-config script installed by LIBGNUTLS could not be found
*** If LIBGNUTLS was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBGNUTLS_CONFIG environment variable to the
*** full path to libgnutls-config.

In gnutls news file it's possible to find (for 2.8.0):
*** Old libgnutls.m4 and libgnutls-config scripts removed.
Please use pkg-config instead

and from ChangeLog it looks like pkg-config detection was available since
* Version 1.0.22 (2004-10-28)

Thus to fix this issue it's safe to use patch like this:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/iksemel/files/iksemel-1
.3-gnutls-2.8.patch?rev=1.1&view=markup

What steps will reproduce the problem?
1. Download and extract iksemel-1.4 sources
2. ./configure
3.

What is the expected output? What do you see instead?

checking for libgnutls-config... no
checking for libgnutls - version >= 0.1.0... no
*** The libgnutls-config script installed by LIBGNUTLS could not be found
*** If LIBGNUTLS was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBGNUTLS_CONFIG environment variable to the
*** full path to libgnutls-config.


What version of the product are you using? On what operating system?

OpenSUSE 11.4 RC2 x86_64
libgnutls-2.6

Please provide any additional information below.

lifbgnutls-config is obsolete and does not present in modern distributions:

http://lists.gnu.org/archive/html/help-gnutls/2009-05/msg00034.html

"** Old libgnutls.m4 and libgnutls-config scripts removed.
Please use pkg-config instead."

What steps will reproduce the problem?
1. Compile

What is the expected output? What do you see instead?

None. I see the compiler warning.

filter.c: In function 'iks_filter_packet':
filter.c:128: warning: comparison between 'enum ikstype' and 'enum ikspaktype' 
[-Wenum-compare]

What version of the product are you using? On what operating system?

Latest version.