opendcp
opendcp copied to clipboard
Published
20 hours ago •
tmeiczin
tmeiczin
Adding digital signatures causes crash
What steps will reproduce the problem?
1. run opendcp_xml with -s -d -r option
2. it will segfault
What is the expected output? What do you see instead?
no segfault :-)
What version of the product are you using? On what operating system?
Xubuntu 12.04 AMD64
Please provide any additional information below.
GDB Debug Output
andreas@notebook:~/Desktop/dcitest/Video Test/KDM$ gdb opendcp_xml
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 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-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /OpenDCP/opendcp_xml...done.
(gdb) run -s -d -r video.j2c.mxf
Starting program: opendcp_xml -s -d -r video.j2c.mxf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
OpenDCP XML 0.0.27 (c) 2010-2012 Terrence Meiczinger. All rights reserved.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ace613 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(gdb) where
#0 0x00007ffff7ace613 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1 0x00007ffff7acf582 in RSA_sign () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2 0x00007ffff7ad3cb3 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3 0x00007ffff7af9134 in EVP_SignFinal () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#4 0x00007ffff72451ea in ?? () from /usr/lib/libxmlsec1-openssl.so.1
#5 0x00007ffff748ea42 in xmlSecTransformDefaultPushBin () from
/usr/lib/libxmlsec1.so.1
#6 0x00007ffff748adee in ?? () from /usr/lib/libxmlsec1.so.1
#7 0x00007ffff77185cc in xmlOutputBufferClose () from
/usr/lib/x86_64-linux-gnu/libxml2.so.2
#8 0x00007ffff746f887 in ?? () from /usr/lib/libxmlsec1.so.1
#9 0x00007ffff748db1c in xmlSecTransformCtxXmlExecute () from
/usr/lib/libxmlsec1.so.1
#10 0x00007ffff749403b in ?? () from /usr/lib/libxmlsec1.so.1
#11 0x00007ffff7495264 in xmlSecDSigCtxSign () from /usr/lib/libxmlsec1.so.1
#12 0x00000000004413e2 in xml_sign (opendcp=<optimized out>,
filename=0x7ffff7ebfa2e "0900d3c1-2c28-4b9b-b92c-94e15c128cd0_cpl.xml")
at /OpenDCP-GIT/tmeiczin-OpenDCP-64449a0/libopendcp/opendcp_xml_sign.c:485
#13 0x00000000004387d3 in write_cpl (opendcp=0x7ffff7ebf010, cpl=0x7ffff7ebf820)
at /OpenDCP-GIT/tmeiczin-OpenDCP-64449a0/libopendcp/opendcp_xml.c:208
#14 0x000000000042aa25 in main (argc=<optimized out>, argv=<optimized out>)
at /OpenDCP-GIT/tmeiczin-OpenDCP-64449a0/cli/opendcp_xml_cmd.c:347
(gdb)
Original issue reported on code.google.com by [email protected] on 2 Oct 2012 at 9:16
I'll keep this in mind. However, it appears you probably compiled from the
latest github source, which is not stable.
Original comment by [email protected] on 2 Oct 2012 at 8:30
Yes - I compiled from GIT as I first stumbled across this error running the
latest stable release. Self do, self have approach: I compiled with debug flags
hoping to find the error with gdb - but IMHO it crashes in libcrypto.so :-(
Regards,
Andreas
Original comment by [email protected] on 2 Oct 2012 at 9:48
Still experiencing this issue. Both on gui and cli versions when doing a signed
cpl.
I got libssl symbols, this is the dump stack from gui:
(gdb) where
#0 RSA_eay_private_encrypt (flen=-401484736, from=0x0, to=0x7fffe811d8b0 "",
rsa=0x7fffe8119d10, padding=1) at rsa_eay.c:442
#1 0x00007ffff64c7cff in RSA_sign (type=672, m=m@entry=0x7ffffff32500
"\354\332\036\267 \352
\202^\375\255\352\005\a9\027\025\265\033\362\275\260\305Mf\t~\357$\017\002\212",
m_len=m_len@entry=32, sigret=sigret@entry=0x7fffe811d8b0 "", siglen=siglen@entry=0x7ffffff3247c, rsa=rsa@entry=0x7fffe8119d10) at rsa_sign.c:141
#2 0x00007ffff64cc9b4 in pkey_rsa_sign (ctx=0x7fffe811d240, sig=0x7fffe811d8b0
"", siglen=0x7ffffff324c8,
tbs=0x7ffffff32500 "\354\332\036\267 \352 \202^\375\255\352\005\a9\027\025\265\033\362\275\260\305Mf\t~\357$\017\002\212", tbslen=32) at rsa_pmeth.c:251
#3 0x00007ffff64f1777 in EVP_SignFinal (ctx=0x7fffe8079aa0,
sigret=0x7fffe811d8b0 "", siglen=0x7ffffff3259c, pkey=<optimized out>) at
p_sign.c:106
#4 0x00007ffff61c95e1 in xmlSecOpenSSLEvpSignatureExecute
(transform=0x7fffe8079a20, last=1, transformCtx=<optimized out>) at
signatures.c:641
#5 0x00007ffff5f77fb9 in xmlSecTransformExecute (transform=<optimized out>,
last=<optimized out>, transformCtx=<optimized out>) at transforms.c:1937
#6 0x00007ffff5f7ae31 in xmlSecTransformDefaultPushBin
(transform=0x7fffe8079a20, data=0x0, dataSize=0, final=1,
transformCtx=0x7fffe8079830) at transforms.c:2205
#7 0x00007ffff5f770ca in xmlSecTransformPushBin (transform=<optimized out>,
data=<optimized out>, dataSize=<optimized out>, final=<optimized out>,
transformCtx=<optimized out>)
at transforms.c:1851
#8 0x00007ffff5f771f6 in xmlSecTransformIOBufferClose (buffer=0x7fffe8117df0)
at transforms.c:2889
#9 0x00007ffff7ec8058 in xmlOutputBufferClose () from
/usr/lib/x86_64-linux-gnu/libxml2.so.2
#10 0x00007ffff5f5ae1d in xmlSecTransformC14NPushXml (transform=0x7fffe8079980,
nodes=0x7fffe8119f10, transformCtx=<optimized out>) at c14n.c:277
#11 0x00007ffff5f7795e in xmlSecTransformPushXml (transform=<optimized out>,
nodes=<optimized out>, transformCtx=<optimized out>) at transforms.c:1897
#12 0x00007ffff5f79ff8 in xmlSecTransformCtxXmlExecute (ctx=0x7fffe8079830,
nodes=0x7fffe8119f10) at transforms.c:1234
#13 0x00007ffff5f8114b in xmlSecDSigCtxProcessSignatureNode
(dsigCtx=0x7fffe8079570, node=<optimized out>) at xmldsig.c:612
#14 0x00007ffff5f81626 in xmlSecDSigCtxSign (dsigCtx=0x7fffe8079570,
tmpl=0x7fffe805ae40) at xmldsig.c:301
#15 0x00000000004a1b4e in xml_sign ()
#16 0x000000000049302a in write_cpl ()
#17 0x0000000000481ec7 in MainWindow::startDcp (this=0x7fffffffe280) at
/home/lars/dcp/opendcp/gui/xml.cpp:226
#18 0x000000000049179a in MainWindow::qt_static_metacall (_o=0x7ffffff32330,
_c=QMetaObject::WriteProperty, _id=0, _a=0x2)
at /home/lars/dcp/opendcp-build/gui/moc_mainwindow.cxx:208
#19 0x00007ffff6de454f in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#20 0x00007ffff7968f32 in QAbstractButton::clicked(bool) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#21 0x00007ffff76bd06e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x00007ffff76bd8a0 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#23 0x00007ffff76bdb0c in QAbstractButton::mouseReleaseEvent(QMouseEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#24 0x00007ffff7352e10 in QWidget::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#25 0x00007ffff730370c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#26 0x00007ffff73083eb in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#27 0x00007ffff6dceb5e in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#28 0x00007ffff730454b in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) ()
from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#29 0x00007ffff737efc4 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#30 0x00007ffff737dd51 in QApplication::x11ProcessEvent(_XEvent*) () from
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#31 0x00007ffff73a4bc2 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#32 0x00007ffff420d355 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#33 0x00007ffff420d688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#34 0x00007ffff420d744 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#35 0x00007ffff6dfd296 in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#36 0x00007ffff73a483e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#37 0x00007ffff6dcd8af in
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#38 0x00007ffff6dcdb38 in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#39 0x00007ffff6dd2cf8 in QCoreApplication::exec() () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#40 0x0000000000449bd3 in main (argc=1, argv=<optimized out>) at
/home/lars/dcp/opendcp/gui/main.cpp:43
The line in question for rsa_eay.c in context from line 435:
435 BIGNUM local_d;
436 BIGNUM *d = NULL;
437
438 if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
439 {
440 BN_init(&local_d);
441 d = &local_d;
442 BN_with_flags(d, rsa->d, BN_FLG_CONSTTIME);
443 }
444 else
445 d= rsa->d;
libssl (openssl) version 1.0.1e (patched for heartbleed, though problem comes
from before patched version) in Debian Wheezy 64 bit.
Original comment by [email protected] on 25 Apr 2014 at 3:15
This might be useful information for debugging for you. I tried again with cli
(opendcp_xml), crawled up to the opendcp xml_sign() context, and printed the
values being passed to xmlSecDSigCtxSign. (p.s., I'm using my own certs in
opendcp_certificates.h but I checked them 10 times already. And I've also tried
passing these certs directly in this run via -1 -2 -3 and -p. the xmlsec cli
tool can sign the produced cpl file without error using these same cert files):
(gdb) up
#15 0x000000000044ee9e in xml_sign (opendcp=<optimized out>,
filename=0x7ffff7dfd87e "CPL_e1544a54-dc74-473a-b915-b395ecf91d87.xml")
at /home/lars/dcp/opendcp/libopendcp/opendcp_xml_sign.c:503
503 if (xmlSecDSigCtxSign(dsig_ctx, sign_node) < 0) {
(gdb) print dsig_ctx
$1 = (xmlSecDSigCtxPtr) 0x74fcb0
(gdb) print *dsig_ctx
$2 = {userData = 0x0, flags = 0, flags2 = 0, keyInfoReadCtx = {userData = 0x0,
flags = 0, flags2 = 0, keysMngr = 0x75d510, mode = xmlSecKeyInfoModeRead,
enabledKeyData = {
id = 0x7ffff732c0a0, data = 0x0, use = 0, max = 1, allocMode = 64}, base64LineSize = 0, retrievalMethodCtx = {userData = 0x0, flags = 65535, flags2 = 0,
enabledUris = 4147298656, enabledTransforms = {id = 0x0, data = 0x0, use = 1, max = 0, allocMode = xmlSecAllocModeExact}, preExecCallback = 0, result = 0x0,
status = xmlSecTransformStatusNone, uri = 0x0, xptrExpr = 0x0, first = 0x0, last = 0x0, reserved0 = 0x1, reserved1 = 0x0}, maxRetrievalMethodLevel = 1, encCtx = 0x0,
maxEncryptedKeyLevel = 9, certsVerificationTime = 0, certsVerificationDepth = 0, pgpReserved = 0x7ffff7569c80, curRetrievalMethodLevel = 2, curEncryptedKeyLevel = 1,
keyReq = {keyId = 0x0, keyType = 4147301152, keyUsage = 32767, keyBitsSize = 0, keyUseWithList = {id = 0x0, data = 0x1, use = 0, max = 0, allocMode = xmlSecAllocModeExact},
reserved1 = 0x0, reserved2 = 0x0}, reserved0 = 0x0, reserved1 = 0x75d510}, keyInfoWriteCtx = {userData = 0x1, flags = 4147298464, flags2 = 32767, keysMngr = 0x0,
mode = xmlSecKeyInfoModeRead, enabledKeyData = {id = 0x1, data = 0x40, use = 0, max = 0, allocMode = 65535}, base64LineSize = -147668640, retrievalMethodCtx = {
userData = 0x0, flags = 0, flags2 = 0, enabledUris = 1, enabledTransforms = {id = 0x0, data = 0x0, use = 0, max = 0, allocMode = xmlSecAllocModeExact}, preExecCallback = 0,
result = 0x0, status = xmlSecTransformStatusNone, uri = 0x0, xptrExpr = 0x1 <Address 0x1 out of bounds>, first = 0x0, last = 0x1, reserved0 = 0x0, reserved1 = 0x9},
maxRetrievalMethodLevel = 0, encCtx = 0x0, maxEncryptedKeyLevel = 0, certsVerificationTime = -4294967295, certsVerificationDepth = 0, pgpReserved = 0x7ffff732cb20,
curRetrievalMethodLevel = 0, curEncryptedKeyLevel = 0, keyReq = {keyId = 0x0, keyType = 1, keyUsage = 0, keyBitsSize = 0, keyUseWithList = {id = 0x0, data = 0x0, use = 0,
max = 0, allocMode = xmlSecAllocModeExact}, reserved1 = 0xffff, reserved2 = 0x7ffff732c160}, reserved0 = 0x0, reserved1 = 0x0}, transformCtx = {userData = 0x1, flags = 0,
flags2 = 0, enabledUris = 7752024, enabledTransforms = {id = 0x1, data = 0x0, use = 0, max = 7667904, allocMode = 7751904}, preExecCallback = 0, result = 0x0, status = 65535,
uri = 0x0, xptrExpr = 0x0, first = 0x0, last = 0x0, reserved0 = 0x0, reserved1 = 0x751b70}, enabledReferenceUris = 3, enabledReferenceTransforms = 0x0,
referencePreExecuteCallback = 0, defSignMethodId = 0x750160, defC14NMethodId = 0x7500c0, defDigestMethodId = 0x0, signKey = 0x75e610, operation = xmlSecTransformOperationNone,
result = 0x7ffff732ce00, status = 7673312, signMethod = 0x4000000001, c14nMethod = 0x1, preSignMemBufMethod = 0x7ffff732ce00, signValueNode = 0x0, id = 0x0,
signedInfoReferences = {id = 0x1, data = 0x0, use = 0, max = 161, allocMode = 4147298944}, manifestReferences = {id = 0x100000000, data = 0x75d550, use = 7668064, max = 0,
allocMode = xmlSecAllocModeExact}, reserved0 = 0x0, reserved1 = 0x1}
(gdb) print *sign_node
$3 = {_private = 0x0, type = XML_ELEMENT_NODE, name = 0x75d150 "Signature",
children = 0x75d170, last = 0x762380, parent = 0x73bae0, next = 0x762420, prev
= 0x75d030,
doc = 0x73bb80, ns = 0x7584e0, content = 0x0, properties = 0x0, nsDef = 0x0, psvi = 0x0, line = 51, extra = 0}
Original comment by [email protected] on 25 Apr 2014 at 3:48
Re-opening since the issue still seems to persist.
Original comment by [email protected] on 25 Apr 2014 at 2:54
- Changed state: Accepted
Trying to debug further, this sigsegv ocurrs in 64 bit wheezy, does not ocurr
in 32 bit wheezy (same libxmlsec and libssl versions). Trying to set a
breakpoint to compare structs in xml_sign calls
Original comment by [email protected] on 25 Apr 2014 at 3:52
This would certainly look like an libxmlsec problem in 64 bit, if it werent for
the fact that the xmlsec tool can easily sign the xml cpl template prepared by
opendcp before segfaulting.
dsig context differences:
Comparing dsig_ctx between the 32 bit build, and the 64 bit build, I see some
differences (beyound the obvious differences in pointer addresses between the
machines):
64 bit:
1 {userData = 0x0,
2 flags = 0,
3 flags2 = 0,
4 keyInfoReadCtx = {userData = 0x0,
5 flags = 0,
6 flags2 = 0,
7 keysMngr = 0x75d510,
8 mode = xmlSecKeyInfoModeRead,
9 enabledKeyData = {
10 id = 0x7ffff732c0a0,
11 data = 0x0,
12 use = 0,
13 max = 1,
14 allocMode = 64},
15 base64LineSize = 0,
16 retrievalMethodCtx = {userData = 0x0,
17 flags = 65535,
18 flags2 = 0,
19
20 enabledUris = 4147298656,
21 enabledTransforms = {id = 0x0,
22 data = 0x0,
23 use = 1,
24 max = 0,
25 allocMode = xmlSecAllocModeExact},
26 preExecCallback = 0,
27 result = 0x0,
28
29 status = xmlSecTransformStatusNone,
30 uri = 0x0,
31 xptrExpr = 0x0,
32 first = 0x0,
33 last = 0x0,
34 reserved0 = 0x1,
35 reserved1 = 0x0},
36 maxRetrievalMethodLevel = 1,
37 encCtx = 0x0,
38
39 maxEncryptedKeyLevel = 9,
40 certsVerificationTime = 0,
41 certsVerificationDepth = 0,
42 pgpReserved = 0x7ffff7569c80,
43 curRetrievalMethodLevel = 2,
44 curEncryptedKeyLevel = 1,
45
46 keyReq = {keyId = 0x0,
47 keyType = 4147301152,
48 keyUsage = 32767,
49 keyBitsSize = 0,
50 keyUseWithList = {id = 0x0,
51 data = 0x1,
52 use = 0,
53 max = 0,
54 allocMode = xmlSecAllocModeExact},
55
56 reserved1 = 0x0,
57 reserved2 = 0x0},
58 reserved0 = 0x0,
59 reserved1 = 0x75d510},
60 keyInfoWriteCtx = {userData = 0x1,
61 flags = 4147298464,
62 flags2 = 32767,
63 keysMngr = 0x0,
64
65 mode = xmlSecKeyInfoModeRead,
66 enabledKeyData = {id = 0x1,
67 data = 0x40,
68 use = 0,
69 max = 0,
70 allocMode = 65535},
71 base64LineSize = -147668640,
72 retrievalMethodCtx = {
73 userData = 0x0,
74 flags = 0,
75 flags2 = 0,
76 enabledUris = 1,
77 enabledTransforms = {id = 0x0,
78 data = 0x0,
79 use = 0,
80 max = 0,
81 allocMode = xmlSecAllocModeExact},
82 preExecCallback = 0,
83
84 result = 0x0,
85 status = xmlSecTransformStatusNone,
86 uri = 0x0,
87 xptrExpr = 0x1 <Address 0x1 out of bounds>,
88 first = 0x0,
89 last = 0x1,
90 reserved0 = 0x0,
91 reserved1 = 0x9},
92
93 maxRetrievalMethodLevel = 0,
94 encCtx = 0x0,
95 maxEncryptedKeyLevel = 0,
96 certsVerificationTime = -4294967295,
97 certsVerificationDepth = 0,
98 pgpReserved = 0x7ffff732cb20,
99
100 curRetrievalMethodLevel = 0,
101 curEncryptedKeyLevel = 0,
102 keyReq = {keyId = 0x0,
103 keyType = 1,
104 keyUsage = 0,
105 keyBitsSize = 0,
106 keyUseWithList = {id = 0x0,
107 data = 0x0,
108 use = 0,
109
110 max = 0,
111 allocMode = xmlSecAllocModeExact},
112 reserved1 = 0xffff,
113 reserved2 = 0x7ffff732c160},
114 reserved0 = 0x0,
115 reserved1 = 0x0},
116 transformCtx = {userData = 0x1,
117 flags = 0,
118
119 flags2 = 0,
120 enabledUris = 7752024,
121 enabledTransforms = {id = 0x1,
122 data = 0x0,
123 use = 0,
124 max = 7667904,
125 allocMode = 7751904},
126 preExecCallback = 0,
127 result = 0x0,
128 status = 65535,
129
130 uri = 0x0,
131 xptrExpr = 0x0,
132 first = 0x0,
133 last = 0x0,
134 reserved0 = 0x0,
135 reserved1 = 0x751b70},
136 enabledReferenceUris = 3,
137 enabledReferenceTransforms = 0x0,
138
139 referencePreExecuteCallback = 0,
140 defSignMethodId = 0x750160,
141 defC14NMethodId = 0x7500c0,
142 defDigestMethodId = 0x0,
143 signKey = 0x75e610,
144 operation = xmlSecTransformOperationNone,
145
146 result = 0x7ffff732ce00,
147 status = 7673312,
148 signMethod = 0x4000000001,
149 c14nMethod = 0x1,
150 preSignMemBufMethod = 0x7ffff732ce00,
151 signValueNode = 0x0,
152 id = 0x0,
153
154 signedInfoReferences = {id = 0x1,
155 data = 0x0,
156 use = 0,
157 max = 161,
158 allocMode = 4147298944},
159 manifestReferences = {id = 0x100000000,
160 data = 0x75d550,
161 use = 7668064,
162 max = 0,
163
164 allocMode = xmlSecAllocModeExact},
165 reserved0 = 0x0,
166 reserved1 = 0x1}
32 bit:
1 {userData = 0x0,
2 flags = 0,
3 flags2 = 0,
4 keyInfoReadCtx = {userData = 0x0,
5 flags = 0,
6 flags2 = 0,
7 keysMngr = 0x81556f0,
8 mode = xmlSecKeyInfoModeRead,
9 enabledKeyData = {id = 0xb7d7b43c,
10
11 data = 0x0,
12 use = 0,
13 max = 0,
14 allocMode = xmlSecAllocModeDouble},
15 base64LineSize = 64,
16 retrievalMethodCtx = {userData = 0x0,
17 flags = 0,
18 flags2 = 0,
19 enabledUris = 65535,
20
21 enabledTransforms = {id = 0xb7d7b494,
22 data = 0x0,
23 use = 0,
24 max = 0,
25 allocMode = xmlSecAllocModeDouble},
26 preExecCallback = 0,
27 result = 0x0,
28 status = xmlSecTransformStatusNone,
29 uri = 0x0,
30
31 xptrExpr = 0x0,
32 first = 0x0,
33 last = 0x0,
34 reserved0 = 0x0,
35 reserved1 = 0x0},
36 maxRetrievalMethodLevel = 1,
37 encCtx = 0x0,
38 maxEncryptedKeyLevel = 1,
39 certsVerificationTime = 0,
40
41 certsVerificationDepth = 9,
42 pgpReserved = 0x0,
43 curRetrievalMethodLevel = 0,
44 curEncryptedKeyLevel = 0,
45 keyReq = {keyId = 0x0,
46 keyType = 0,
47 keyUsage = 4294967295,
48 keyBitsSize = 0,
49
50 keyUseWithList = {id = 0xb7d7b9f8,
51 data = 0x0,
52 use = 0,
53 max = 0,
54 allocMode = xmlSecAllocModeDouble},
55 reserved1 = 0x0,
56 reserved2 = 0x0},
57 reserved0 = 0x0,
58 reserved1 = 0x0},
59
60 keyInfoWriteCtx = {userData = 0x0,
61 flags = 0,
62 flags2 = 0,
63 keysMngr = 0x81556f0,
64 mode = xmlSecKeyInfoModeWrite,
65 enabledKeyData = {id = 0xb7d7b43c,
66 data = 0x0,
67 use = 0,
68 max = 0,
69
70 allocMode = xmlSecAllocModeDouble},
71 base64LineSize = 64,
72 retrievalMethodCtx = {userData = 0x0,
73 flags = 0,
74 flags2 = 0,
75 enabledUris = 65535,
76 enabledTransforms = {id = 0xb7d7b494,
77
78 data = 0x0,
79 use = 0,
80 max = 0,
81 allocMode = xmlSecAllocModeDouble},
82 preExecCallback = 0,
83 result = 0x0,
84 status = xmlSecTransformStatusNone,
85 uri = 0x0,
86 xptrExpr = 0x0,
87 first = 0x0,
88
89 last = 0x0,
90 reserved0 = 0x0,
91 reserved1 = 0x0},
92 maxRetrievalMethodLevel = 1,
93 encCtx = 0x0,
94 maxEncryptedKeyLevel = 1,
95 certsVerificationTime = 0,
96 certsVerificationDepth = 9,
97
98 pgpReserved = 0x0,
99 curRetrievalMethodLevel = 0,
100 curEncryptedKeyLevel = 0,
101 keyReq = {keyId = 0x0,
102 keyType = 1,
103 keyUsage = 4294967295,
104 keyBitsSize = 0,
105 keyUseWithList = {id = 0xb7d7b9f8,
106
107 data = 0x0,
108 use = 0,
109 max = 0,
110 allocMode = xmlSecAllocModeDouble},
111 reserved1 = 0x0,
112 reserved2 = 0x0},
113 reserved0 = 0x0,
114 reserved1 = 0x0},
115 transformCtx = {userData = 0x0,
116 flags = 0,
117
118 flags2 = 0,
119 enabledUris = 65535,
120 enabledTransforms = {id = 0xb7d7b494,
121 data = 0x0,
122 use = 0,
123 max = 0,
124 allocMode = xmlSecAllocModeDouble},
125 preExecCallback = 0,
126 result = 0x0,
127
128 status = xmlSecTransformStatusNone,
129 uri = 0x0,
130 xptrExpr = 0x0,
131 first = 0x0,
132 last = 0x0,
133 reserved0 = 0x0,
134 reserved1 = 0x0},
135 enabledReferenceUris = 65535,
136 enabledReferenceTransforms = 0x0,
137
138 referencePreExecuteCallback = 0,
139 defSignMethodId = 0x0,
140 defC14NMethodId = 0x0,
141 defDigestMethodId = 0x0,
142 signKey = 0x0,
143 operation = xmlSecTransformOperationNone,
144 result = 0x0,
145
146 status = xmlSecDSigStatusUnknown,
147 signMethod = 0x0,
148 c14nMethod = 0x0,
149 preSignMemBufMethod = 0x0,
150 signValueNode = 0x0,
151 id = 0x0,
152 signedInfoReferences = {id = 0xb7d7bb68,
153 data = 0x0,
154 use = 0,
155
156 max = 0,
157 allocMode = xmlSecAllocModeDouble},
158 manifestReferences = {id = 0xb7d7bb68,
159 data = 0x0,
160 use = 0,
161 max = 0,
162 allocMode = xmlSecAllocModeDouble},
163 reserved0 = 0x0,
164 reserved1 = 0x0}
The first thing I noticed, is the allocMode inside the enabledKeyData inside
the keyInfoReadCtx, line 14 in both 32 and 64 bits... in 32 bits it's one of
two accepted enum values for the mode (acoording to xmlsec docs),
xmlSecAllocModeDouble, while in the 64 bit version, it's "64". Not a valid enum
value. Also if you see lines 15, you'll see in the working 32 bit version, the
base64 line size is 64... while in 64 bit it's 0... it makes me think the
struct somehow shifted left, and the value for item base64LineSize populated
the wrong space in the struct in 64 bits.
This dsig_ctx is generated off xmlSecDSigCtxCreate(key_manager); in
opendcp_xml_sign.c in line 493. I'll check the values of live key_manager to
detect if there are differences between 32 bit opendcp and 64 bit opendcp.
Original comment by [email protected] on 25 Apr 2014 at 9:03
Printing key_manager from line 493 in opendcp_xml_sign.c:
32 bits (working):
print *key_manager
$1 = {keysStore = 0x81563b8, storesList = {id = 0xb7d7ba34, data = 0x8155510,
use = 1, max = 64, allocMode = xmlSecAllocModeDouble}, getKey = 0xb7d373d0
<xmlSecKeysMngrGetKey>}
64 bits (failing):
print *key_manager
$5 = {keysStore = 0x73a2d0, storesList = {id = 0x7ffff732cbe0, data = 0x739fd0,
use = 274877906945, max = 1, allocMode = 4144956200}, getKey = 0}
There is definitively something here, first with a damaged allocMode, and
second with an empty getKey pointer.... and strange use and max values.
Original comment by [email protected] on 25 Apr 2014 at 9:17
The trouble/schism in this case seems to appear in line 385 of
opendcp_xml_sign.c following the call inside xmlSecCryptoAppKeyLoadMemory the
key seems perfectly fine inside the function, but once the pointer is returned
to the caller it's when (at that moment) it gets "corrupted". I'm following
this over the libxmlsec mailing list to try and get help from experts in the
library.
Original comment by [email protected] on 26 Apr 2014 at 1:09
Issue seems to be possibly related to this
http://www.aleksey.com/pipermail/xmlsec/2007/008005.html (Text will be copied
bellow in case site goes down).
Yet not entirely sure it's that flag, or that flag alone, as I've tried both
adding -DXMLSEC_NO_SIZE_T to libopendcp and opendcp_xml build process, and also
added the whole host of defines dropped by "pkg-config xmlsec1 --cflags"
(defines only) to the defines for opendcp_lib and opendcp_xml (and checked they
are being defined via preprocessor warnings on the code. they are). and the
problem still persists.
Original text from issue link above as reference: << EOA
Hi list,
I ran into a bit of a problem recently using the xmlsec library today on
a Linux x86_64 box. Here’s the situation:
1) The xmlsec library was compiled using the standard configure, make. (
--enable-debugging, --with-libxlst=no )
2) A piece of code that signs an xml doc was compiled and linked it to
the library.
3) The code involved a call to xmlSecDSigCtxSign()
result = ( xmlSecDSigCtxSign( dsigCtx, signNode ) >= 0);
This was failing because the struct in the library appeared to be
different then the one that our code was passing in. ( Memory was
shifted when it entered the xmlSecDSigCtxSign function ) Note: the code
works fine on 32-bit Windows and Linux.
We determined this was because of a compile flag that is set when
compiling the library: -DXMLSEC_NO_SIZE_T. (configure.in ln: 128)
This results in a size_t being an unsigned int rather than size_t .
(xmlsec.h line:43)
Apparently this is defined when configure detects a 64-bit system.
Obviously when we compiled our code we didn’t compile with this defined
causing a difference in the size of the struct relative to the piece of
code.
We can resolve this in two ways:
1) Not defining XMLSEC_NO_SIZE_T when compiling the library.
2) Compiling our application with XMLSEC_NO_SIZE_T defined.
Is anyone familiar with the implications of each of these actions?
Thank you kindly,
Nolan
--
Nolan Hurlburt
nolanhurlburt at itiva.com
EOA
Response I've gotten from xmlsec list (xmlsec maintainer/creator even) so far:
<< EOB
Check how openssl, xmlsec and opendcp were compiled:
1) The same compile flags are used (in particular, XMLSEC_NO_SIZE_T).
This is done automatically if pkg-config or other standard tools are
used but might not be working correctly if opendcp is setting compile
flags manually.
2) Make sure that same versions of header/library files are used
across the board during compilation/linking/runtime.
Best,
Aleksey
EOB
Original comment by [email protected] on 26 Apr 2014 at 5:57
what does the pkgconfig file for xmlsec have for flags on debian? On Fedora
64-bit and OSX 64-bit they are:
Cflags: -DXMLSEC_CRYPTO=\"openssl\" -D__XMLSEC_FUNCTION__=__FUNCTION__
-DXMLSEC_NO_SIZE_T -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
-DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1
Original comment by [email protected] on 26 Apr 2014 at 9:23
cflags on Debian 64 bits (package libxmlsec build):
-DXMLSEC_CRYPTO=\"openssl\" -D__XMLSEC_FUNCTION__=__FUNCTION__
-DXMLSEC_NO_SIZE_T -DXMLSEC_NO_GOST=1 -DXMLSEC_NO_XKMS=1
-DXMLSEC_NO_CRYPTO_DYNAMIC_LOADING=1 -DXMLSEC_OPENSSL_098=1
-DXMLSEC_CRYPTO_OPENSSL=1
Original comment by [email protected] on 27 Apr 2014 at 7:17
Issue 218 has been merged into this issue.
Original comment by [email protected] on 28 Apr 2014 at 12:44
Original comment by [email protected] on 28 Apr 2014 at 12:45
- Changed title: Adding digital signatures causes crash
Strange. I write a small program that printed the size of xmlSecSize on both
Fedora 19 64-bit, OSX, and Debian 7 64-bit. They all reported a size of 8.
However, only Debian is crashing. Also, the Windows 7 64-bit crashed using the
latest OpenSSL, but when using version 1.0.0d as used in OpenDCP 0.29 it works.
It would be interesting if 1.0.0d works with Debian 7. If this is some type of
memory leak, it could be just luck it works on some systems.
Original comment by [email protected] on 28 Apr 2014 at 12:59
It looks like the flags were not getting set correctly. I committed a test fix,
if you get a chance, give it a try.
Original comment by [email protected] on 2 May 2014 at 2:39
Still segfaults.
A) I am not entirely sure it's the flags, specially since -DXMLSEC_NO_SIZE_T
seems to work when I applied it directly to my .make files on the build
directory (alongside all the other flags) as evidenced here:
Before flags:
ptype dsig_ctx.keyInfoReadCtx.keysMngr.keysStore.id
type = const struct _xmlSecKeyStoreKlass {
size_t klassSize;
size_t objSize;
const xmlChar *name;
xmlSecKeyStoreInitializeMethod initialize;
xmlSecKeyStoreFinalizeMethod finalize;
xmlSecKeyStoreFindKeyMethod findKey;
void *reserved0;
void *reserved1;
} *
After applying all these flags to my .make files:
ptype dsig_ctx.keyInfoReadCtx.keysMngr.keysStore.id
type = const struct _xmlSecKeyStoreKlass {
unsigned int klassSize;
unsigned int objSize;
const xmlChar *name;
xmlSecKeyStoreInitializeMethod initialize;
xmlSecKeyStoreFinalizeMethod finalize;
xmlSecKeyStoreFindKeyMethod findKey;
void *reserved0;
void *reserved1;
} *
As you can see all size_t types are changed to unsigned int which shows the
flags are working (as far as that one flag).
B) I'm not so sure hardcoding the flags into cmake is the best call for
building on different linux installs... don't you think it'd be better to
incorporate the cmake pkg-config module to extract cflags from it is the best
approach?
http://public.kitware.com/cgi-bin/viewcvs.cgi/CMake/Modules/FindPkgConfig.cmake?
view=markup&content-type=text%2Fx-cvsweb-markup
Trouble here is we'd have to either require pkg-config for linux builds (not so
good), or fail gracefully back to a default flag set if pkg-config is not
present... I know very little (none at all) cmake but when I'm done with my
other patch I could ivnestigate how to include this.
So, originally I'd say it seems to be down to openssl... but I seriously doubt
it, as in my debugging shown above it seems the key context in general in 64
bits debian gets broken when passed from the libxmlsec to opendcp, so having it
work with a certain openssl might mean that incorrect xml signing is produced,
which would be tragic. Also it'd force to include libxmlsec and maybe openssl
with opendcp which is messy and a bad practice. It's better to find out why
it's not working and fix it.
This weekend is pretty full for me. But if I find time to continue debugging,
I'll check the calls perfomed in xmlsec1 (the command line tool), when signing
an xml, and compare them against the calls done on opendcp to see if I note
some important difference. Specially along sign context generation (line 493,
xmlSecDSigCtxCreate) and key loading (lines 383 and 385, xmlSecCryptoAppKeyLoad
and xmlSecCryptoAppKeyLoadMemory)
Original comment by [email protected] on 3 May 2014 at 12:09
It's meant as a test, rather than a final solution. If it doesn't fix the
issue, than it doesn't make sense to add more complexity. Although, the support
to use pkg-config is already in the cmake xmlsec module in the OpenDCP source.
It just ignores the cflags. In my opinion, using pkg-config to get cflags of
that type is not a particularly good thing. There is no guarantee the
development host compile flags matches the targets or the target could change
and break binary compatibility. The OSX and Windows versions already compile
xmlsec, so adding it for linux would not be a great concern, though not
desired. Adding openssl would be a huge pain, however.
I'm kinda leaning toward some type of memory leak.
There are also several examples on xmlsec1 site, which could be tried. Thanks
for your help.
Original comment by [email protected] on 3 May 2014 at 12:41
I haven't had a chance to test much yet, but debugging with the flags I see a
few things:
The xmlsec_no_size_t flag at least is necessary. It's the difference between
the keys corrupting when being loaded vs not corrupting, but the trouble is
this is for 64 bit builds, so I think these flags should be wrapped, perhaps
inside a:
TARGET_ARCH STREQUAL like in the windows build, or similar. Only I'd do it in
reverse. match against the 64 bit arch which should be one instead of one of
many (i386, i586, etc). (ia64?? amd64??)
Original comment by [email protected] on 6 May 2014 at 2:08
I solved this problem on Ubuntu 14.04 LTS by installing packages libxmlsec1 and libxmlsec1-dev from repositories Ubuntu 14.10 utopic: deb http://us.archive.ubuntu.com/ubuntu utopic main universe
the fact is that in Ubuntu 14.04 xmlsec1 lib version is 1.18, but for work necessary 1.20
this show how to install: http://installion.co.uk/ubuntu/utopic/universe/l/libxmlsec1/install/index.html
