Hello,

plainText =  "test"
....
 static const char *JWK_RSA
    = "{ \"kty\": \"RSA\", "
    "\"e\": \"AQAB\", "
    "\"n\": "
    "\"wsqJbopx18NQFYLYOq4ZeMSE89yGiEankUpf25yV8QqroKUGrASj_OeqTWUjwPGKTN1vGFFuHYxiJeAUQH2qQPmg9Oqk6-"
    "ATBEKn9COKYniQ5459UxCwmZA2RL6ufhrNyq0JF3GfXkjLDBfhU9zJJEOhknsA0L_c-X4AI3d_NbFdMqxNe1V_"
    "UWAlLcbKdwO6iC9fAvwUmDQxgy6R0DC1CMouQpenMRcALaSHar1cm4K-syoNobv3HEuqgZ3s6-hOOSqauqAO0GUozPpaIA7OeruyRl5sTWT0r-"
    "iz39bchID2bIKtcqLiFcSYPLBcxmsaQCqRlGhmv6stjTCLV1yT9w\", "
    "\"kid\": \"ff3c5c96-392e-46ef-a839-6ff16027af78\", "
    "\"d\": "
    "\"b9hXfQ8lOtw8mX1dpqPcoElGhbczz_-xq2znCXQpbBPSZBUddZvchRSH5pSSKPEHlgb3CSGIdpLqsBCv0C_XmCM9ViN8uqsYgDO9uCLIDK5plWttbkqA_"
    "EufvW03R9UgIKWmOL3W4g4t-"
    "C2mBb8aByaGGVNjLnlb6i186uBsPGkvaeLHbQcRQKAvhOUTeNiyiiCbUGJwCm4avMiZrsz1r81Y1Z5izo0ERxdZymxM3FRZ9vjTB-"
    "6DtitvTXXnaAm1JTu6TIpj38u2mnNLkGMbflOpgelMNKBZVxSmfobIbFN8CHVc1UqLK2ElsZ9RCQANgkMHlMkOMj-XT0wHa3VBUQ\", "
    "\"p\": "
    "\"8mgriveKJAp1S7SHqirQAfZafxVuAK_A2QBYPsAUhikfBOvN0HtZjgurPXSJSdgR8KbWV7ZjdJM_eOivIb_XiuAaUdIOXbLRet7t9a_"
    "NJtmX9iybhoa9VOJFMBq_rbnbbte2kq0-FnXmv3cukbC2LaEw3aEcDgyURLCgWFqt7M0\", "
    "\"q\": "
    "\"zbbTv5421GowOfKVEuVoA35CEWgl8mdasnEZac2LWxMwKExikKU5LLacLQlcOt7A6n1ZGUC2wyH8mstO5tV34Eug3fnNrbnxFUEE_ZB_njs_"
    "rtZnwz57AoUXOXVnd194seIZF9PjdzZcuwXwXbrZ2RSVW8if_ZH5OVYEM1EsA9M\", "
    "\"dp\": "
    "\"1BaIYmIKn1X3InGlcSFcNRtSOnaJdFhRpotCqkRssKUx2qBlxs7ln_5dqLtZkx5VM_UE_GE7yzc6BZOwBxtOftdsr8HVh-14ksSR9rAGEsO2zVBiEuW4qZf_"
    "aQM-ScWfU--wcczZ0dT-Ou8P87Bk9K9fjcn0PeaLoz3WTPepzNE\", "
    "\"dq\": "
    "\"kYw2u4_UmWvcXVOeV_VKJ5aQZkJ6_sxTpodRBMPyQmkMHKcW4eKU1mcJju_"
    "deqWadw5jGPPpm5yTXm5UkAwfOeookoWpGa7CvVf4kPNI6Aphn3GBjunJHNpPuU6w-wvomGsxd-NqQDGNYKHuFFMcyXO_zWXglQdP_1o1tJ1M-BM\", "
    "\"qi\": "
    "\"j94Ens784M8zsfwWoJhYq9prcSZOGgNbtFWQZO8HP8pcNM9ls7YA4snTtAS_"
    "B4peWWFAFZ0LSKPCxAvJnrq69ocmEKEk7ss1Jo062f9pLTQ6cnhMjev3IqLocIFt5Vbsg_PWYpFSR7re6FRbF9EYOM7F2-HRv1idxKCWoyQfBqk\" }";
    
    cjose_err err;
    
    cjose_jwk_t *jwk = cjose_jwk_import(JWK_RSA, strlen(JWK_RSA), &err);

    // set header for JWE
    cjose_header_t *hdr = cjose_header_new(&err);
    cjose_header_set(hdr, CJOSE_HDR_ALG, CJOSE_HDR_ALG_RSA_OAEP, &err);
    cjose_header_set(hdr, CJOSE_HDR_ENC, CJOSE_HDR_ENC_A256GCM, &err);
    
    // create the JWE
    size_t plain1_len = strlen(plainText);
    cjose_jwe_t *jwe1 = cjose_jwe_encrypt(jwk, hdr, (const uint8_t *)plainText, plain1_len, &err);

    // get the compact serialization of JWE
    char *compact = cjose_jwe_export(jwe1, &err);
    printf("compact %s", compact);

    //cjose_get_dealloc()(plain2);
    cjose_header_release(hdr);
    cjose_jwe_release(jwe1);
    //cjose_jwe_release(jwe2);
    cjose_jwk_release(jwk);
    //cjose_get_dealloc()(compact);
    

This code print the result:

eyJhbGciOiAiUlNBLU9BRVAiLCAiZW5jIjogIkEyNTZHQ00ifQ.vKVHv3OdkAoCImJIo9lHHrAiEaUhJurtqeqRv-53OFrUwovqvvpgIWuq-1mhIsxadGgyOqgFHZK9SBNwes8ilCL4QeW3T2UqGdv02SWjBWxopr3qgeR56RvLQNQvncW74hM142WKUmqKxamNREAxG6i19X6oEAVqoYzqdPP3L91jRFPIY-qrm2am3n_yg2RPQxSimj6zNMf-Gr9SLI0WlfR00IwLx1gyVujUDs8KMp8FpqFppsLLBx-j52-q6Wi9uKzEsJW_0hBRWtZSKKmDBvOuB8138AkTfy7Q9AOOQOoXmHwQfzHbNzdNcmxyExy8TCZF2PbNxnJWKyf0BzK8qg.5h6eNxL4t1sH73R9.t8g0zw.JQ8ucCXXJRKeLywlqesDIQ

When i do a base64URl for the header part :

eyJhbGciOiAiUlNBLU9BRVAiLCAiZW5jIjogIkEyNTZHQ00ifQ
I am getting this result:

{"alg": "RSA-OAEP", "enc": "A256GCM"}

Why i am not getting the right header? with the kid part:

{"kid":"ff3c5c96-392e-46ef-a839-6ff16027af78","alg":"RSA-OAEP","enc":"A256GCM"}

Hello.

Is there any plans for X.509 support?
Any proposed structures and names for the corresponding JWK keys?

Thank you

I'm trying to build cjose using --with-jansson, but no matter what value I pass I keep getting:
Invalid configuration /opt/sbox/rcampbell/jansson/install: machine /opt/sbox/rcampbell/jansson/install not recognized (quotes removed to avoid breaking the markdown).

I'm building inside a CentOS v6.5 container using this command line:
CC=/opt/soldev/toolchains/v1/targets/centos7-i686/bin/i686-target-linux-gnu-gcc ./configure --with-jansson /opt/sbox/rcampbell/jansson/install

Before trying the build, I built jansson with CC=/opt/soldev/toolchains/v1/targets/centos7-i686/bin/i686-target-linux-gnu-gcc ./configure --prefix=/opt/sbox/rcampbell/jansson/install.

I've tried passing the "install" directory, or the "lib" directory and even the name of files inside the lib directory, but I keep getting the same error. Is it expecting the install directory name to be formatted in a specific way?

Our project is using the cjose library. When running valgrind for our project, we found a definitely loss issue in cjose. We check our codes and make sure that the memory of cjose_jws_t is released by calling method cjose_jws_release. So I wonder if the memory of jws->dig is leaked in in some cases. Could you please help check this problem?
Valgrind logs
==26157== 32 bytes in 1 blocks are definitely lost in loss record 15 of 61
==26157== at 0x40272B2: malloc (vg_replace_malloc.c:270)
==26157== by 0x88D4C4D: _cjose_jws_build_dig_sha (jws.c:218)
==26157== by 0x88D35BE: cjose_jws_verify (jws.c:1159)
==26157== by 0x88CA701: wbx_ci_self_contained_token_validate::TokenValidateSig::VerifyByKey(std::string const&, _cjose_jws_int*) (token_validate_sig.cpp:87)

As I'm going through the code, I also realized that there can be a problem with the sequence of encryption and serialization.

If there is only one recipient, and both protected and unprotected headers are given, then the compact serialization must join the headers into common headers, and use that as protected header values. However, JSON serialization must maintain the headers separately. Since the protected headers are used as part of the AAD, we can't decide which actual keys to authenticate, if it's not known what serialization is to be used. There are few solutions here, please let me know which one you would rather have:

1. Serialization type must be known at the time of encryption
2. Encryption must produce artifacts that can be used for both JSON and Compact (AFAIU, that means double the cipher text, because GCM blocks will be different if AAD is different)
3. Shift actual encryption to the serialization phase. Re-encrypt on repeat calls, if serialization changes. The serialization can already fail, so the caller must check the return values anyway, I don't see this breaking compatibility.

Thank you.

Guys, can you add documentation section how to compile lib for iOS?

As is available here: https://www.npmjs.com/package/jose

because of:
https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-04

I noticed that if I call cjose_jws_verify a second time, memory is leaked.

==5109== 32 bytes in 1 blocks are definitely lost in loss record 183 of 280
==5109== at 0x4C29F13: malloc (vg_replace_malloc.c:299)
==5109== by 0x546C0C7: _cjose_jws_build_dig_sha (jws.c:176)
==5109== by 0x546D962: cjose_jws_verify (jws.c:1052)

Is this known / expected? and should the application always discard JWS before a second attempt to verify the JWS?

In jwe.c, _cjose_jwe_set_iv_aes_cbc creates different sized IVs depending on the key size. This doesn't seem correct; the CBC IV is based on the block size, which is always 16 bytes for AES, not the key size. I can't find a specific example in RFC7516 of AES256 to confirm my understanding; have I misunderstood something about the spec?

Hello.

So far, CJose only supports "protected" headers. This is true for both JWS and JWE, but I'd like to focus on JWE only for now.
To support multiple recipients, however, unprotected headers are necessary.
I can't find any clear guidelines on which keys can be in either protected or unprotected headers. There are some examples, but they seem to be non-binding.
So, for using the header values, for building up the keys and such, I believe I need to provide all of the 3 headers:

1. protected header
2. shared unprotected header
3. per (current) recipient unprotected header

So, for example, the code that determines the key algorithms, encryption algorithm, and etc., need to get the information it needs. I'm a also a bit puzzled on the order. Looks like "protected" header should be the first choice (because it's protected) before falling back onto the unprotected ones, but that doesn't make sense, because per recipient obviously has higher specificity.

To recap:

1. Are there any rules on which key properties should be in which types of headers
2. What should be the order of probing for a property among various headers

Thank you.

Hi,

Can the project load JWK from RSA PEM format?

Thank you.

Steps to reproduce:
call cjose_jwe_import with a JWE compact serialization that does not include the encrypted key portion (ie, [something]..[something].[something].[something])

expected behavior: cjose creates a _cjose_jwe_int with an empty _cjose_jwe_part_int in the second position of the JWE part array
actual behavior: cjose returns null and gives a CJOSE_ERR_INVALID_ARG error.

notes:
alg is ECDH-ES
enc is A256GCM

Hello.

I see that cjose_jwe_encrypt copies kid value from the key into the headers of the JWE object itself. It doesn't seem to be needed. Though JWS RFC says that the kid must match the one from the key, JWE RFC doesn't have such language.

In File cjose/src/base64.c

In function
static inline bool _decode(const char *input, size_t inlen, uint8_t **output, size_t *outlen, bool url, cjose_err *err)

Line 78:
uint8_t *buffer = cjose_get_alloc()(sizeof(uint8_t) * rlen);

Fix:
memset(buffer, 0, sizeof(uint8_t) * rlen);

Symptoms:
I am using function

jws = cjose_jws_import(access_token, strlen(access_token), err);
to get the jws object and then to get the plaintext version i am using
cjose_jws_get_plaintext(jws, &plaintext, &plaintext_len, err)

However, when i see the plaintext version, it has extra garbage characters in the end after the termination of the JSON

i am using the JSON parse to get the values, C function is
e = cl_json_parse(a_token, &json_top);

It is throwing error because of the corrupted plaintext field (extra garbage character), as i can't change the source code of cjose, workaround is parse from the end till i get the closing } brace to get the final length.

One weird thing is "first time when i decode the string then the JSON plaintext looks ok, its subsequent time when the garbage characters shows up" not sure if it is due to the alloc function.

Please memset the buffer to 0 before using it.

In header.h, globals variables are called the following way:
extern const char *CJOSE_HDR_ALG;

In Visual C++, there's no way to have that declaration included in a third-party application, even by providing a DEF file. All exported variables have to be declared with
extern __declspec(dllimport).

Proposal, compatible with Visual C++ and others:

#ifdef _MSC_VER
# ifdef CJOSE_BUILD
#  define EXTERN extern __declspec(dllexport) 
# else
#  define EXTERN extern __declspec(dllimport) 
# endif
#else
# define EXTERN extern
#endif

EXTERN const char *CJOSE_HDR_ALG;

Please remove platform/debian/qemu-arm-static from the git archive or the release tar.gz .
A binary file should not be in a source archive.
If someone wants to use the armhf docker file, he/she should supply the qemu binary.

CONTRIBUTING indicates that before submitting, clang-format must be run (specifically 3.9), but many of the files do not appear to be consistent with clang-format currently. Is clang-format still required and does it require specifically 3.9 (the current version is 8)? I believe this will generate a large number of unrelated changes.

While building cjose for Debian the test on s390x fails:

check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify_short:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify_empty:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536
check_jws.c:81:F:core:test_cjose_jws_self_sign_self_verify_many:0: cjose_jws_sign failed: crypto error, file: jws.c, function: _cjose_jws_build_sig_rs, line: 536

I don't see a memory problem.

what's up with this line:
https://github.com/cisco/cjose/blob/master/src/jws.c#L827

static bool _cjose_jws_verify_sig_rs256(
            cjose_jws_t *jws, 
            const cjose_jwk_t *jwk, 
            cjose_err *err)
{
    return true;
...

make give me this error message:

...
/usr/bin/ld: /usr/lib/gcc/x86_64-amazon-linux/4.8.3/../../../../lib64/libjansson.a(dump.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-amazon-linux/4.8.3/../../../../lib64/libjansson.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[1]: *** [libcjose.la] Error 1

Any idea how to fix it?

I'd like to request for a new release that includes #40 and #33 .

Since #33 changes the behavior of the API I believe it deserves more than a minor number bump. (I could actually see 1.0.0 coming out...)

I hope this will then propagate to e.g. https://anonscm.debian.org/git/collab-maint/cjose.git/ and http://rpmfind.net/linux/rpm2html/search.php?query=pkgconfig(cjose) so that packages dependent on libcjose (such as https://github.com/pingidentity/mod_auth_openidc) can then refer to it.

Attempts to decrypt the JWE:

eyJhbGciOiJBMjU2S1ciLCJraWQiOiIzYmJhNTkxMC04MzZmLTRjOTYtYjE0My0xNWM0MTkzNTRjNDAiLCJlbmMiOiJBMjU2R0NNIn0.-rqxPUoKNyVTBumul_8dLhK2uVhPRd-l55Xw6No8Fo8wN9wreuQg_g.2ZH9Jxx8tEZ7Dzdz.v2ESxQ.wKR8Ms6EI_st6Pzz424O-w

Using JWK:

{
    "kty" : "oct",
    "k" : "7SOtIzBXT6MJHRG79G7r3FiIOlNa_tuJX00IzLeYRYY"
}

Results in a crash here:
https://github.com/cisco/cjose/blob/master/src/jwe.c#L385

The combined use of alg=A256KW and enc=A256GCM appears to lead to the dereferencing of an invalid pointer (the jwk pointer above has value "1")

in jwe.c, on line 1952:

cek = cjose_get_alloc()(cek_len);
memcpy(cek, jwe->cek, cek_len);

Allocation result is not checked. We should add

if (!cek) {
   CJOSE_ERROR(err, CJOSE_ERR_NO_MEMORY);
   return NULL;
}

Following up on #60, I'm trying to understand how to derive an ECDH-ES key. I had thought that it was with cjose_jwk_derive_ecdh_ephemeral_key, but that seems to be a different HKDF algorithm. If I have a jwe, an apv, a private key and a public key, what can I call to fetch the derived shared secret?

I believe the thing I'm looking for is derived that's computed by _cjose_jwe_decrypt_ek_ecdh_es.

Hello,

I think the project is currently only meant for Mac and Linux distros. Is there a plan to include Windows in the mix ?

CJOSE does not currently support any ECDH algroriths, which hinders some use cases.

To start, at least direct key agreement ("ECDH-ES") should be supported.

I am using the cjose library to create a JWT which will be used while exchanging information with a third-party client.

I found that sometimes, the library returns the below error:
JWT library error: invalid argument in file:jwe.c and func:_cjose_jwe_set_cek_aes_cbc
and line:448
This happens on my call to cjose_jwe_encrypt(jwk, header, (uint8_t*)compact_jws, comp_jws_len, &err);

I traced down the problem, and what I found was the value returned from cjose_base64url_decode() sometimes changes i.e. the output string value returned changes randomly, even though the provided input and inlen remains the same.
I cannot find any reason for this return value to vary even though the input remains constant.

Would it be possible to provide a fix for this or a workaround?

as far as I understand:
https://github.com/cisco/cjose/blob/master/src/version.c#L12

should read:

    return JOSE_VERSION;

instead of:

    return VERSION;

since the former is generated by:
https://github.com/cisco/cjose/blob/master/include/cjose/version.h.in#L25

#define CJOSE_VERSION "@PACKAGE_VERSION@"

which also makes the testing slightly more relevant at:
https://github.com/cisco/cjose/blob/master/test/check_version.c#L21

START_TEST (test_cjose_version_fn)
{
    const char *version = cjose_version();
    ck_assert_str_eq(version, VERSION);
}
END_TEST

as VERSION is obtained from the compiler settings if I'm correct; I may misunderstand what the intent of it is though

Hi @linuxwolf ,
I'm having problems with encryption A128GCM.
Is it supported Algorithm A128GCM for this library?

thank you,
Regards!

Most memory leak detectors redefine the "free" function (and others).
The struct _key_fntable_int contains the following:
void (*free)(cjose_jwk_t *);
This clashes with a redefintion of "free".
Is it possible to rename this field (like "free_func")?
Thanks

Version: 0.4.1
If configured with jansson and/or openssl, there is a '-Lyes/lib' LD_FLAG that is added, that freaks out the libtool.

[vps@phoenix]~/src/cjose$ ./configure --prefix=/opt/soft/cjose --exec-prefix=/opt/soft/cjose 
...
[vps@phoenix]~/src/cjose$ make -j
... <all OK> ...
[vps@phoenix]~/src/cjose$ ./configure --prefix=/opt/soft/cjose --exec-prefix=/opt/soft/cjose --with-jansson --with-openssl
...
[vps@phoenix]~/src/cjose$ make -j
...
/bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99 --pedantic -Wall -Werror -g -O2 -I../include -g -O2 -Iyes/include/ -Iyes/include/ -lm -Lyes/lib -Lyes/lib -o libcjose.la -rpath /opt/soft/cjose/lib libcjose_la-version.lo libcjose_la-util.lo libcjose_la-base64.lo libcjose_la-jwk.lo libcjose_la-jwe.lo libcjose_la-jws.lo libcjose_la-header.lo libcjose_la-error.lo  -ljansson -lcrypto 
../libtool: line 7472: cd: yes/lib: No such file or directory
libtool:   error: cannot determine absolute directory name of 'yes/lib'
Makefile:438: recipe for target 'libcjose.la' failed
[vps@phoenix]~/src/cjose$ grep 'yes/lib' * 2>/dev/null 
config.log:configure:14829: gcc -o conftest -g -O2 -Iyes/include/  -Iyes/include/  -Lyes/lib conftest.c -lcrypto   >&5
config.log:configure:14911: gcc -o conftest -g -O2 -Iyes/include/ -Iyes/include/  -Iyes/include/ -Iyes/include/  -Lyes/lib -Lyes/lib conftest.c -ljansson  -lcrypto  >&5
config.log:LDFLAGS=' -Lyes/lib -Lyes/lib'
config.status:S["LDFLAGS"]=" -Lyes/lib -Lyes/lib"
Makefile:LDFLAGS =  -Lyes/lib -Lyes/lib

When setting a custom memory allocator and deallocator using

I suggest to replace the calls to free with cjose_get_dealloc()

Hi,
It's great library!
automake version: 1.14
autoconf version: 2.69

Execute autoreconf --force --install have warning message:
configure.ac:9: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body

Hi all,

I would like to know the current status of this project, maintenance-wise.
would you please provide some info in this regard.

Regards,

Hi @linuxwolf ,
I'm having problems with encryption A128GCM.
Is it supported Algorithm A128GCM for this library?

thank you,
Regards!

Been trying to use this library to install mod_auth_openidc since this software is a dependency for it, all runnning well untill I tried to run 'make', I got this error

clang: warning: /usr/local/opt/cjose/include: 'linker' input unused
In file included from src/mod_auth_openidc.c:74:
In file included from src/mod_auth_openidc.h:60:
In file included from src/jose.h:64:
In file included from /usr/local/include/cjose/cjose.h:26:
/usr/local/include/cjose/jwk.h:20:10: fatal error: 'openssl/obj_mac.h' file not found
#include <openssl/obj_mac.h>
^
1 error generated.
apxs:Error: Command failed with rc=65536
.
make: *** [src/mod_auth_openidc.la] Error 1

Below is my environment setup

• Apache (2.4.25)
• cjose (latest)
• OpenSSL (OpenSSL 1.0.2j 26 Sep 2016)
• Curl
• Jansson (2.9)
• pcre3 (8.39)
• pkg-config (0.29.1_2)
• hiredis (0.13.3)

*note that all software is installed using Brew (don't know if it will be matter just put some informations together)

Below is my ./configure setup on mod_auth_openidc

erudianto$ CJOSE_CFLAGS=/usr/local/opt/cjose/include CJOSE_LIBS=/usr/local/opt/cjose/lib ./configure --with-apxs2=/Users/erudianto/Downloads/apache-server/dist/bin/apxs --prefix /Users/erudianto/Downloads/mod_auth_openidc-2.1.3/dist

Calling cjose_jwe_decrypt_multi, and not having any keys match, causes a SEGV, as an attempt to decrypt with null CEK is attempted

Could you please consider replacement of openssl with libressl? Or fork of the project which would use libressl? Both libraries cannot be installed at the same time and I am kind of stuck with apache httpd built with libre.

(See also 8693c22#commitcomment-27669403)

Hi there,

Since

• compile with LibreSSL (8693c22aabf31313a4002838e124e93879bbb50b)

building with newer GCC (and Clang supposedly) produces:

util.c: In function 'cjose_apply_allocs':
util.c:53:36: error: this use of "defined" may not be portable [-Werror=expansion-to-defined]
 #if (CJOSE_OPENSSL_11X)
     ^~~~~~~~~~~~~~~~~

(Probably due to this patch: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00738.html)

Maybe there is a way to restructure this macros.

Regards,
Moritz

The current implementation of cjose_jws_verify releases the allocated JWS resources when the verification fails for some reason, see e.g.: https://github.com/cisco/cjose/blob/master/src/jws.c#L1169

Firstly I've found this to be counter-intuitive from a developer perspective.

Secondly it makes the calling code having to differentiate between error paths and successful paths wrt. releasing resources.

Thirdly, it makes it impossible to call cjose_jws_verify in a loop for a number of keys e.g. in scenario's where no kid is presented in the JWS header but a number of verification keys have been pre-configured.

cjose-0.6.1 encountered the following error when running “gamke” on solaris 11.3. I would like to ask “Can cjose be installed successfully on solaris 11.3?”and“If solaris 11.3 was supported, can you suggest a solution for the following error？“ Thanks

Error message：

Making check in doc
Making check in platform
Making check in centos
make: Fatal error in reader: Makefile, line 270: Unexpected end of line seen
Current working directory /root/cjose-latest/platform/centos
*** Error code 1
The following command caused the error:
fail=;
if (target_option=k; case ${target_option-} in ?) ;; ) echo "am__make_running_with_option: internal error: invalid" "target option '${target_option-}' specified" >&2; exit 1;; esac; has_opt=no; sane_makeflags=$MAKEFLAGS; if { if test -z '1'; then false; elif test -n ''; then true; elif test -n '' && test -n ''; then true; else false; fi; }; then sane_makeflags=$MFLAGS; else case $MAKEFLAGS in \[\ \ ]) bs=\; sane_makeflags=printf '%s\n' "$MAKEFLAGS" | sed "s/$bs$bs[$bs $bs ]*//g";; esac; fi; skip_next=no; strip_trailopt () { flg=printf '%s\n' "$flg" | sed "s/$1.*$//"; }; for flg in $sane_makeflags; do test $skip_next = yes && { skip_next=no; continue; }; case $flg in =|--) continue;; -I) strip_trailopt 'I'; skip_next=yes;; -I?) strip_trailopt 'I';; -O) strip_trailopt 'O'; skip_next=yes;; -O?) strip_trailopt 'O';; -l) strip_trailopt 'l'; skip_next=yes;; -l?) strip_trailopt 'l';; -[dEDm]) skip_next=yes;; -[JT]) skip_next=yes;; esac; case $flg in $target_option) has_opt=yes; break;; esac; done; test $has_opt = yes); then
failcom='fail=yes';
else
failcom='exit 1';
fi;
dot_seen=no;
target=echo check-recursive | sed s/-recursive//;
case "check-recursive" in
distclean- | maintainer-clean-) list='centos debian' ;;
) list='centos debian' ;;
esac;
for subdir in $list; do
echo "Making $target in $subdir";
if test "$subdir" = "."; then
dot_seen=yes;
local_target="$target-am";
else
local_target="$target";
fi;
(CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target)
|| eval $failcom;
done;
if test "$dot_seen" = "no"; then
make "$target-am" || exit 1;
fi; test -z "$fail"
make: Fatal error: Command failed for target check-recursive' Current working directory /root/cjose-latest/platform *** Error code 1 The following command caused the error: fail=; \ if (target_option=k; case ${target_option-} in ?) ;; *) echo "am__make_running_with_option: internal error: invalid" "target option '${target_option-}' specified" >&2; exit 1;; esac; has_opt=no; sane_makeflags=$MAKEFLAGS; if { if test -z ''; then false; elif test -n ''; then true; elif test -n '' && test -n ''; then true; else false; fi; }; then sane_makeflags=$MFLAGS; else case $MAKEFLAGS in *\\[\ \ ]*) bs=\\; sane_makeflags=printf '%s\n' "$MAKEFLAGS" | sed "s/$bs$bs[$bs $bs ]//g";; esac; fi; skip_next=no; strip_trailopt () { flg=printf '%s\n' "$flg" | sed "s/$1.$//"; }; for flg in $sane_makeflags; do test $skip_next = yes && { skip_next=no; continue; }; case $flg in *=*|--*) continue;; -*I) strip_trailopt 'I'; skip_next=yes;; -*I?*) strip_trailopt 'I';; -*O) strip_trailopt 'O'; skip_next=yes;; -*O?*) strip_trailopt 'O';; -*l) strip_trailopt 'l'; skip_next=yes;; -*l?*) strip_trailopt 'l';; -[dEDm]) skip_next=yes;; -[JT]) skip_next=yes;; esac; case $flg in *$target_option*) has_opt=yes; break;; esac; done; test $has_opt = yes); then \ failcom='fail=yes'; \ else \ failcom='exit 1'; \ fi; \ dot_seen=no; \ target=echo check-recursive | sed s/-recursive//; \ case "check-recursive" in \ distclean-* | maintainer-clean-*) list='. include src test doc platform' ;; \ *) list='. include src test doc platform' ;; \ esac; \ for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target check-recursive'

http://blog.intothesymmetry.com/2017/03/critical-vulnerability-in-json-web.html

This pull request is as relevant today as it was in 2016 when the author submitted it. It seems many other current github.com/cisco projects are using CMake now, and it would be preferable for many users. It doesn't look like anyone has even given any response to the author at all to the PR, as is the case for 5 other open PRs. Any response at all would be helpful to community users.

All the concatkdf unit tests will fail on big endian architectures. The failure occurs because one of the operations requires generating a 32-bit integer in big endian format as a length specifier. The code correctly used htonl() to produce the 32-bit big endian integer but then tried to further manipulate the result with bit shifting and octet indexing which was unnecessary. The bit shifting and octet indexing only worked on little endian architectures.

I will be submitting a pull request momentarily that fixes the issue, the commit comment tries to explain why the mistake occurred.

I see cjose_jws_sign does a lot of checks on the input, and returns an error, but if there is no alg field set in CJOSE, then the code SIGSEGV on strcmping the alg with various values...

Hi ,
I'm having problems with the encryption function.
Is it supported input the AAD when call cjose_jwe_encrypt function?

thank you,
Regards!

Looks like the use of ck_assert_uint_eq would require at least check-devel 0.10.0: libcheck/check@305371c

RHEL 7 version of check is 0.9.9

Error:

DEBUG util.py:490:  BUILDSTDERR: check_cjose-check_concatkdf.o: In function `test_cjose_concatkdf_otherinfo_noextra':
DEBUG util.py:490:  BUILDSTDERR: /builddir/build/BUILD/cjose-0.6.1/test/check_concatkdf.c:98: undefined reference to `ck_assert_uint_eq'
DEBUG util.py:490:  BUILDSTDERR: check_cjose-check_concatkdf.o: In function `test_cjose_concatkdf_otherinfo_apuapv':
DEBUG util.py:490:  BUILDSTDERR: /builddir/build/BUILD/cjose-0.6.1/test/check_concatkdf.c:123: undefined reference to `ck_assert_uint_eq'
DEBUG util.py:490:  BUILDSTDERR: collect2: error: ld returned 1 exit status

otherwise somebody should pick it up in a fork

The tests test_cjose_concatkdf_derive_* fail on big endian architectures like s390x, powerpc, ppc64, sparc64, ...:

check_concatkdf.c:159:F:concatkdf:test_cjose_concatkdf_derive_simple:0: Assertion 'derived==expected' failed: keylen==%, derived==0x20, expected==0x566eb950
check_concatkdf.c:190:F:concatkdf:test_cjose_concatkdf_derive_ikm:0: Assertion 'derived==expected' failed: keylen==%, derived==0x20, expected==0x566ebb80
check_concatkdf.c:224:F:concatkdf:test_cjose_concatkdf_derive_moreinfo:0: Assertion 'derived==expected' failed: keylen==%, derived==0x20, expected==0x566ebd50

Maybe this is something similar to #38 where some bad casts were the source of the problem that go unnoticed on little endian, but make it fail on big endian.
However, I did not find something at a quick glance (except from the fact that &err gets used in both function calls there, is not nulled inbetween and is not checked - maybe that would help debugging).

More details and complete build logs can be found on the respective Debian Buildd page:
https://buildd.debian.org/status/package.php?p=cjose

There is also a Debian bug report tracking the issue:
https://bugs.debian.org/890907