leitang / iksemel Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/iksemel
License: GNU Lesser General Public License v2.1
Automatically exported from code.google.com/p/iksemel
License: GNU Lesser General Public License v2.1
Would you be willing to relicense iksemel under a BSD license?
Original issue reported on code.google.com by [email protected]
on 16 Apr 2012 at 7:22
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.
Original issue reported on code.google.com by [email protected]
on 8 Dec 2010 at 7:37
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 12 Dec 2007 at 1:58
It seems I would need to implement the SRV standards myself if I use
iksemel? :/
Original issue reported on code.google.com by [email protected]
on 14 Jan 2008 at 11:31
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
Original issue reported on code.google.com by [email protected]
on 11 May 2012 at 12:46
md5.c -> iks_md5_new uses malloc instead of iks_malloc and also uses free
instead of iks_free
Original issue reported on code.google.com by [email protected]
on 9 Apr 2009 at 4:41
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?).
Original issue reported on code.google.com by [email protected]
on 2 Mar 2010 at 8:04
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
Original issue reported on code.google.com by [email protected]
on 3 Sep 2011 at 3:22
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. :)
Original issue reported on code.google.com by xdersd
on 30 Aug 2009 at 1:14
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
Original issue reported on code.google.com by [email protected]
on 23 Jul 2014 at 3:48
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 29 Aug 2008 at 2:21
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 9 Apr 2009 at 4:39
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 -> /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
Original issue reported on code.google.com by [email protected]
on 9 Apr 2009 at 5:02
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))
Original issue reported on code.google.com by [email protected]
on 21 Apr 2009 at 7:27
I found this bug on my Fedora 7 machine. I confirmed this on Ubuntu 8.04
machine too.
Original issue reported on code.google.com by [email protected]
on 9 Apr 2009 at 4:43
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
===================
Original issue reported on code.google.com by [email protected]
on 19 May 2008 at 1:30
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.
Original issue reported on code.google.com by [email protected]
on 23 Jul 2007 at 9:01
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
Original issue reported on code.google.com by [email protected]
on 3 Mar 2009 at 8:35
`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.
Original issue reported on code.google.com by [email protected]
on 13 Sep 2014 at 5:13
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.
Original issue reported on code.google.com by [email protected]
on 8 Aug 2013 at 8:05
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 4 Feb 2013 at 11:44
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.
Original issue reported on code.google.com by [email protected]
on 11 Nov 2007 at 6:40
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&M">N&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;M">N&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&M">N&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)
Original issue reported on code.google.com by [email protected]
on 15 Oct 2008 at 6:59
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.
Original issue reported on code.google.com by [email protected]
on 23 Jul 2007 at 9:01
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;
Original issue reported on code.google.com by [email protected]
on 11 May 2009 at 7:46
Hi,
For the time being iksemel lib doesn't support "invisible" status, i wonder if
there is a projection to implement this ??
Best regards.
Original issue reported on code.google.com by [email protected]
on 15 Apr 2011 at 8:30
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.
Original issue reported on code.google.com by [email protected]
on 4 Nov 2009 at 11:34
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 29 Jun 2011 at 10:26
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)
Original issue reported on code.google.com by [email protected]
on 1 Feb 2012 at 12:02
Attachments:
iks_recv() dose not time-out when TLS is on.
Original issue reported on code.google.com by [email protected]
on 9 Apr 2009 at 5:33
This patch fix two missing pointer checks.
Original issue reported on code.google.com by [email protected]
on 12 Nov 2013 at 10:57
Attachments:
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
Original issue reported on code.google.com by urkle0
on 11 Sep 2007 at 7:33
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2010 at 7:38
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.
Original issue reported on code.google.com by [email protected]
on 31 May 2010 at 6:07
Attachments:
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!
Original issue reported on code.google.com by [email protected]
on 29 Aug 2012 at 4:24
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.
Original issue reported on code.google.com by [email protected]
on 1 Sep 2011 at 11:05
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 5 May 2013 at 2:05
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;
Original issue reported on code.google.com by [email protected]
on 23 Mar 2010 at 4:27
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.
Original issue reported on code.google.com by [email protected]
on 9 Sep 2010 at 10:55
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.
Original issue reported on code.google.com by [email protected]
on 20 Sep 2010 at 9:31
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(,'
Original issue reported on code.google.com by [email protected]
on 26 May 2010 at 6:20
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
Original issue reported on code.google.com by [email protected]
on 26 Dec 2009 at 12:51
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."
Original issue reported on code.google.com by [email protected]
on 3 Mar 2011 at 8:02
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.
Original issue reported on code.google.com by [email protected]
on 19 Feb 2013 at 9:36
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.