gh-libtom/libtomcrypt
Watch
1
0
Fork
You've already forked libtomcrypt
 0
Code Issues 42 Pull requests 17 Releases 9 Wiki Activity

New relese? #568

New issue
Open
opened 2021-04-19 06:48:30 -05:00 by kloczek · 34 comments
kloczek commented 2021-04-19 06:48:30 -05:00 (Migrated from github.com)

Is it possible to make new release soon?
I'm asking because lat latest perl CryptX seems is using featires which are not included in 1.18.2 and are only available in commits added after last release.
Here is build fail log on building perl CryptX against libtomcrypt 1.18.2.

/usr/bin/gcc -c   -D_REENTRANT -D_GNU_SOURCE -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin   -DVERSION=\"0.071\" -DXS_VERSION=\"0.071\" -fPIC "-I/usr/lib64/perl5/CORE"   CryptX.c
CryptX.xs:35:9: error: unknown type name 'salsa20_state'
   35 | typedef salsa20_state           *Crypt__Stream__Salsa20;
      |         ^~~~~~~~~~~~~
CryptX.xs:36:9: error: unknown type name 'sosemanuk_state'
   36 | typedef sosemanuk_state         *Crypt__Stream__Sosemanuk;
      |         ^~~~~~~~~~~~~~~
CryptX.xs:37:9: error: unknown type name 'rabbit_state'
   37 | typedef rabbit_state            *Crypt__Stream__Rabbit;
      |         ^~~~~~~~~~~~
CryptX.xs:154:3: error: unknown type name 'curve25519_key'
  154 |   curve25519_key key;
      |   ^~~~~~~~~~~~~~
CryptX.xs:161:3: error: unknown type name 'curve25519_key'
  161 |   curve25519_key key;
      |   ^~~~~~~~~~~~~~
CryptX.xs: In function 'mp_tohex_with_leading_zero':
CryptX.xs:173:3: warning: 'mp_toradix_n' is deprecated: replaced by mp_to_radix [-Wdeprecated-declarations]
  173 |   rv = mp_toradix_n(a, str, 16, maxlen);
      |   ^~
In file included from CryptX.xs:23:
/usr/include/tommath.h:751:35: note: declared here
  751 | MP_DEPRECATED(mp_to_radix) mp_err mp_toradix_n(const mp_int *a, char *str, int radix, int maxlen) MP_WUR;
      |                                   ^~~~~~~~~~~~
CryptX.xs: In function '_ecc_oid_lookup':
CryptX.xs:260:10: error: unknown type name 'ltc_ecc_curve'
  260 |    const ltc_ecc_curve *cu;
      |          ^~~~~~~~~~~~~
CryptX.xs:262:11: error: 'key->dp' is a pointer; did you mean to use '->'?
  262 |    key->dp.oidlen = 0;
      |           ^
      |           ->
CryptX.xs:264:14: error: 'ltc_ecc_curves' undeclared (first use in this function)
  264 |    for (cu = ltc_ecc_curves; cu->prime != NULL; cu++) {
      |              ^~~~~~~~~~~~~~
CryptX.xs:264:14: note: each undeclared identifier is reported only once for each function it appears in
CryptX.xs:264:32: error: request for member 'prime' in something not a structure or union
  264 |    for (cu = ltc_ecc_curves; cu->prime != NULL; cu++) {
      |                                ^~
CryptX.xs:265:39: error: request for member 'prime' in something not a structure or union
  265 |       if ((err = mp_read_radix(tmp, cu->prime, 16)) != CRYPT_OK) continue;
      |                                       ^~
CryptX.xs:266:31: error: 'key->dp' is a pointer; did you mean to use '->'?
  266 |       if ((mp_cmp(tmp, key->dp.prime) != LTC_MP_EQ))             continue;
      |                               ^
      |                               ->
CryptX.xs:267:39: error: request for member 'order' in something not a structure or union
  267 |       if ((err = mp_read_radix(tmp, cu->order, 16)) != CRYPT_OK) continue;
      |                                       ^~
CryptX.xs:268:31: error: 'key->dp' is a pointer; did you mean to use '->'?
  268 |       if ((mp_cmp(tmp, key->dp.order) != LTC_MP_EQ))             continue;
      |                               ^
      |                               ->
CryptX.xs:269:39: error: request for member 'A' in something not a structure or union
  269 |       if ((err = mp_read_radix(tmp, cu->A,     16)) != CRYPT_OK) continue;
      |                                       ^~
CryptX.xs:270:31: error: 'key->dp' is a pointer; did you mean to use '->'?
  270 |       if ((mp_cmp(tmp, key->dp.A) != LTC_MP_EQ))                 continue;
      |                               ^
      |                               ->
CryptX.xs:271:39: error: request for member 'B' in something not a structure or union
  271 |       if ((err = mp_read_radix(tmp, cu->B,     16)) != CRYPT_OK) continue;
      |                                       ^~
CryptX.xs:272:31: error: 'key->dp' is a pointer; did you mean to use '->'?
  272 |       if ((mp_cmp(tmp, key->dp.B) != LTC_MP_EQ))                 continue;
      |                               ^
      |                               ->
CryptX.xs:273:39: error: request for member 'Gx' in something not a structure or union
  273 |       if ((err = mp_read_radix(tmp, cu->Gx,    16)) != CRYPT_OK) continue;
      |                                       ^~
CryptX.xs:274:31: error: 'key->dp' is a pointer; did you mean to use '->'?
  274 |       if ((mp_cmp(tmp, key->dp.base.x) != LTC_MP_EQ))            continue;
      |                               ^
      |                               ->
CryptX.xs:275:39: error: request for member 'Gy' in something not a structure or union
  275 |       if ((err = mp_read_radix(tmp, cu->Gy,    16)) != CRYPT_OK) continue;
      |                                       ^~
CryptX.xs:276:31: error: 'key->dp' is a pointer; did you mean to use '->'?
  276 |       if ((mp_cmp(tmp, key->dp.base.y) != LTC_MP_EQ))            continue;
      |                               ^
      |                               ->
CryptX.xs:277:18: error: 'key->dp' is a pointer; did you mean to use '->'?
  277 |       if (key->dp.cofactor != cu->cofactor)                      continue;
      |                  ^
      |                  ->
CryptX.xs:277:33: error: request for member 'cofactor' in something not a structure or union
  277 |       if (key->dp.cofactor != cu->cofactor)                      continue;
      |                                 ^~
CryptX.xs:281:10: error: request for member 'prime' in something not a structure or union
  281 |    if (cu->prime && cu->OID) {
      |          ^~
CryptX.xs:281:23: error: request for member 'OID' in something not a structure or union
  281 |    if (cu->prime && cu->OID) {
      |                       ^~
CryptX.xs:282:38: error: 'key->dp' is a pointer; did you mean to use '->'?
  282 |      for (i = 0; i < 16; i++) key->dp.oid[i] = 0;
      |                                      ^
      |                                      ->
CryptX.xs:283:38: error: request for member 'OID' in something not a structure or union
  283 |      for (i = 0, j = 0; i < strlen(cu->OID); i++) {
      |                                      ^~
CryptX.xs:284:14: error: request for member 'OID' in something not a structure or union
  284 |        if (cu->OID[i] == '.') {
      |              ^~
CryptX.xs:287:18: error: request for member 'OID' in something not a structure or union
  287 |        else if(cu->OID[i] >= '0' && cu->OID[i] <= '9') {
      |                  ^~
CryptX.xs:287:39: error: request for member 'OID' in something not a structure or union
  287 |        else if(cu->OID[i] >= '0' && cu->OID[i] <= '9') {
      |                                       ^~
CryptX.xs:288:17: error: 'key->dp' is a pointer; did you mean to use '->'?
  288 |          key->dp.oid[j] = key->dp.oid[j] * 10 + (cu->OID[i] - '0');
      |                 ^
      |                 ->
CryptX.xs:288:34: error: 'key->dp' is a pointer; did you mean to use '->'?
  288 |          key->dp.oid[j] = key->dp.oid[j] * 10 + (cu->OID[i] - '0');
      |                                  ^
      |                                  ->
CryptX.xs:288:52: error: request for member 'OID' in something not a structure or union
  288 |          key->dp.oid[j] = key->dp.oid[j] * 10 + (cu->OID[i] - '0');
      |                                                    ^~
CryptX.xs:294:13: error: 'key->dp' is a pointer; did you mean to use '->'?
  294 |      key->dp.oidlen = j + 1;
      |             ^
      |             ->
CryptX.xs: In function '_ecc_set_curve_from_SV':
CryptX.xs:332:11: error: unknown type name 'ltc_ecc_curve'
  332 |     const ltc_ecc_curve *cu;
      |           ^~~~~~~~~~~~~
CryptX.xs:334:9: warning: implicit declaration of function 'ecc_find_curve' [-Wimplicit-function-declaration]
  334 |     if (ecc_find_curve(ptr_crv, &cu) != CRYPT_OK) croak("FATAL: ecparams: unknown curve '%s'", ptr_crv);
      |         ^~~~~~~~~~~~~~
CryptX.xs:335:12: warning: implicit declaration of function 'ecc_set_curve' [-Wimplicit-function-declaration]
  335 |     return ecc_set_curve(cu, key);
      |            ^~~~~~~~~~~~~
CryptX.xs:339:5: error: unknown type name 'ltc_ecc_curve'
  339 |     ltc_ecc_curve cu = { 0 };
      |     ^~~~~~~~~~~~~
CryptX.xs:360:7: error: request for member 'OID' in something not a structure or union
  360 |     cu.OID = (sv_oid && SvOK(*sv_oid)) ? SvPV_nolen(*sv_oid) : NULL;
      |       ^
CryptX.xs:362:7: error: request for member 'prime' in something not a structure or union
  362 |     cu.prime    = SvPV_nolen(*sv_prime);
      |       ^
CryptX.xs:363:7: error: request for member 'A' in something not a structure or union
  363 |     cu.A        = SvPV_nolen(*sv_A);
      |       ^
CryptX.xs:364:7: error: request for member 'B' in something not a structure or union
  364 |     cu.B        = SvPV_nolen(*sv_B);
      |       ^
CryptX.xs:365:7: error: request for member 'order' in something not a structure or union
  365 |     cu.order    = SvPV_nolen(*sv_order);
      |       ^
CryptX.xs:366:7: error: request for member 'Gx' in something not a structure or union
  366 |     cu.Gx       = SvPV_nolen(*sv_Gx);
      |       ^
CryptX.xs:367:7: error: request for member 'Gy' in something not a structure or union
  367 |     cu.Gy       = SvPV_nolen(*sv_Gy);
      |       ^
CryptX.xs:368:7: error: request for member 'cofactor' in something not a structure or union
  368 |     cu.cofactor = (unsigned long)SvUV(*sv_cofactor);
      |       ^
CryptX.xs:371:16: error: 'key->dp' is a pointer; did you mean to use '->'?
  371 |     if (key->dp.oidlen == 0) _ecc_oid_lookup(key);
      |                ^
      |                ->
CryptX.xs: In function 'XS_Crypt__Misc__radix_to_bin':
CryptX.xs:425:11: warning: 'mp_unsigned_bin_size' is deprecated: replaced by mp_ubin_size [-Wdeprecated-declarations]
  425 |           len = mp_unsigned_bin_size(&mpi);
      |           ^~~
In file included from CryptX.xs:23:
/usr/include/tommath.h:731:33: note: declared here
  731 | MP_DEPRECATED(mp_ubin_size) int mp_unsigned_bin_size(const mp_int *a) MP_WUR;
      |                                 ^~~~~~~~~~~~~~~~~~~~
CryptX.xs:434:13: warning: 'mp_to_unsigned_bin' is deprecated: replaced by mp_to_ubin [-Wdeprecated-declarations]
  434 |             if (mp_to_unsigned_bin(&mpi, out_data) != MP_OKAY) {
      |             ^~
In file included from CryptX.xs:23:
/usr/include/tommath.h:733:34: note: declared here
  733 | MP_DEPRECATED(mp_to_ubin) mp_err mp_to_unsigned_bin(const mp_int *a, unsigned char *b) MP_WUR;
      |                                  ^~~~~~~~~~~~~~~~~~
CryptX.xs: In function 'XS_Crypt__Misc__bin_to_radix':
CryptX.xs:467:11: warning: 'mp_read_unsigned_bin' is deprecated: replaced by mp_from_ubin [-Wdeprecated-declarations]
  467 |           if (mp_read_unsigned_bin(&mpi, in_data, (unsigned long)len) == CRYPT_OK) {
      |           ^~
In file included from CryptX.xs:23:
/usr/include/tommath.h:732:36: note: declared here
  732 | MP_DEPRECATED(mp_from_ubin) mp_err mp_read_unsigned_bin(mp_int *a, const unsigned char *b, int c) MP_WUR;
      |                                    ^~~~~~~~~~~~~~~~~~~~
CryptX.xs:483:15: warning: 'mp_toradix' is deprecated: replaced by mp_to_radix [-Wdeprecated-declarations]
  483 |               if (mp_toradix(&mpi, out_data, radix) == MP_OKAY) {
      |               ^~
In file included from CryptX.xs:23:
/usr/include/tommath.h:750:35: note: declared here
  750 | MP_DEPRECATED(mp_to_radix) mp_err mp_toradix(const mp_int *a, char *str, int radix) MP_WUR;
      |                                   ^~~~~~~~~~
CryptX.xs: In function 'XS_Crypt__Misc_encode_b64':
CryptX.xs:524:67: warning: pointer targets in passing argument 3 of 'base64url_encode' differ in signedness [-Wpointer-sign]
  524 |             rv = base64url_encode(in_data, (unsigned long)in_len, out_data, &out_len);
      |                                                                   ^~~~~~~~
      |                                                                   |
      |                                                                   char *
In file included from /usr/include/tomcrypt.h:92,
                 from CryptX.xs:22:
/usr/include/tomcrypt_misc.h:23:40: note: expected 'unsigned char *' but argument is of type 'char *'
   23 |                         unsigned char *out, unsigned long *outlen);
      |                         ~~~~~~~~~~~~~~~^~~
CryptX.xs:526:64: warning: pointer targets in passing argument 3 of 'base64_encode' differ in signedness [-Wpointer-sign]
  526 |             rv = base64_encode(in_data, (unsigned long)in_len, out_data, &out_len);
      |                                                                ^~~~~~~~
      |                                                                |
      |                                                                char *
In file included from /usr/include/tomcrypt.h:92,
                 from CryptX.xs:22:
/usr/include/tomcrypt_misc.h:13:40: note: expected 'unsigned char *' but argument is of type 'char *'
   13 |                         unsigned char *out, unsigned long *outlen);
      |                         ~~~~~~~~~~~~~~~^~~
CryptX.xs: In function 'XS_Crypt__Misc_decode_b64':
CryptX.xs:560:18: warning: implicit declaration of function 'base64url_sane_decode'; did you mean 'base64url_strict_decode'? [-Wimplicit-function-declaration]
  560 |             rv = base64url_sane_decode(in_data, (unsigned long)in_len, out_data, &out_len);
      |                  ^~~~~~~~~~~~~~~~~~~~~
      |                  base64url_strict_decode
CryptX.xs:562:18: warning: implicit declaration of function 'base64_sane_decode'; did you mean 'base64url_decode'? [-Wimplicit-function-declaration]
  562 |             rv = base64_sane_decode(in_data, (unsigned long)in_len, out_data, &out_len);
      |                  ^~~~~~~~~~~~~~~~~~
      |                  base64url_decode
CryptX.xs: In function 'XS_Crypt__Misc_encode_b32r':
CryptX.xs:588:27: error: 'BASE32_RFC4648' undeclared (first use in this function)
  588 |         if (ix == 0) id = BASE32_RFC4648;
      |                           ^~~~~~~~~~~~~~
CryptX.xs:589:27: error: 'BASE32_BASE32HEX' undeclared (first use in this function)
  589 |         if (ix == 1) id = BASE32_BASE32HEX;
      |                           ^~~~~~~~~~~~~~~~
CryptX.xs:590:27: error: 'BASE32_ZBASE32' undeclared (first use in this function)
  590 |         if (ix == 2) id = BASE32_ZBASE32;
      |                           ^~~~~~~~~~~~~~
CryptX.xs:591:27: error: 'BASE32_CROCKFORD' undeclared (first use in this function)
  591 |         if (ix == 3) id = BASE32_CROCKFORD;
      |                           ^~~~~~~~~~~~~~~~
CryptX.xs:602:17: warning: implicit declaration of function 'base32_encode'; did you mean 'base64_encode'? [-Wimplicit-function-declaration]
  602 |           err = base32_encode(in_data, (unsigned long)in_len, out_data, &out_len, id);
      |                 ^~~~~~~~~~~~~
      |                 base64_encode
CryptX.xs: In function 'XS_Crypt__Misc_decode_b32r':
CryptX.xs:628:27: error: 'BASE32_RFC4648' undeclared (first use in this function)
  628 |         if (ix == 0) id = BASE32_RFC4648;
      |                           ^~~~~~~~~~~~~~
CryptX.xs:629:27: error: 'BASE32_BASE32HEX' undeclared (first use in this function)
  629 |         if (ix == 1) id = BASE32_BASE32HEX;
      |                           ^~~~~~~~~~~~~~~~
CryptX.xs:630:27: error: 'BASE32_ZBASE32' undeclared (first use in this function)
  630 |         if (ix == 2) id = BASE32_ZBASE32;
      |                           ^~~~~~~~~~~~~~
CryptX.xs:631:27: error: 'BASE32_CROCKFORD' undeclared (first use in this function)
  631 |         if (ix == 3) id = BASE32_CROCKFORD;
      |                           ^~~~~~~~~~~~~~~~
CryptX.xs:642:17: warning: implicit declaration of function 'base32_decode'; did you mean 'base64_decode'? [-Wimplicit-function-declaration]
  642 |           err = base32_decode(in_data, (unsigned long)in_len, out_data, &out_len, id);
      |                 ^~~~~~~~~~~~~
      |                 base64_decode

[..]
Is it possible to make new release soon? I'm asking because lat latest perl CryptX seems is using featires which are not included in 1.18.2 and are only available in commits added after last release. Here is build fail log on building perl CryptX against libtomcrypt 1.18.2. ```console /usr/bin/gcc -c -D_REENTRANT -D_GNU_SOURCE -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -DVERSION=\"0.071\" -DXS_VERSION=\"0.071\" -fPIC "-I/usr/lib64/perl5/CORE" CryptX.c CryptX.xs:35:9: error: unknown type name 'salsa20_state' 35 | typedef salsa20_state *Crypt__Stream__Salsa20; | ^~~~~~~~~~~~~ CryptX.xs:36:9: error: unknown type name 'sosemanuk_state' 36 | typedef sosemanuk_state *Crypt__Stream__Sosemanuk; | ^~~~~~~~~~~~~~~ CryptX.xs:37:9: error: unknown type name 'rabbit_state' 37 | typedef rabbit_state *Crypt__Stream__Rabbit; | ^~~~~~~~~~~~ CryptX.xs:154:3: error: unknown type name 'curve25519_key' 154 | curve25519_key key; | ^~~~~~~~~~~~~~ CryptX.xs:161:3: error: unknown type name 'curve25519_key' 161 | curve25519_key key; | ^~~~~~~~~~~~~~ CryptX.xs: In function 'mp_tohex_with_leading_zero': CryptX.xs:173:3: warning: 'mp_toradix_n' is deprecated: replaced by mp_to_radix [-Wdeprecated-declarations] 173 | rv = mp_toradix_n(a, str, 16, maxlen); | ^~ In file included from CryptX.xs:23: /usr/include/tommath.h:751:35: note: declared here 751 | MP_DEPRECATED(mp_to_radix) mp_err mp_toradix_n(const mp_int *a, char *str, int radix, int maxlen) MP_WUR; | ^~~~~~~~~~~~ CryptX.xs: In function '_ecc_oid_lookup': CryptX.xs:260:10: error: unknown type name 'ltc_ecc_curve' 260 | const ltc_ecc_curve *cu; | ^~~~~~~~~~~~~ CryptX.xs:262:11: error: 'key->dp' is a pointer; did you mean to use '->'? 262 | key->dp.oidlen = 0; | ^ | -> CryptX.xs:264:14: error: 'ltc_ecc_curves' undeclared (first use in this function) 264 | for (cu = ltc_ecc_curves; cu->prime != NULL; cu++) { | ^~~~~~~~~~~~~~ CryptX.xs:264:14: note: each undeclared identifier is reported only once for each function it appears in CryptX.xs:264:32: error: request for member 'prime' in something not a structure or union 264 | for (cu = ltc_ecc_curves; cu->prime != NULL; cu++) { | ^~ CryptX.xs:265:39: error: request for member 'prime' in something not a structure or union 265 | if ((err = mp_read_radix(tmp, cu->prime, 16)) != CRYPT_OK) continue; | ^~ CryptX.xs:266:31: error: 'key->dp' is a pointer; did you mean to use '->'? 266 | if ((mp_cmp(tmp, key->dp.prime) != LTC_MP_EQ)) continue; | ^ | -> CryptX.xs:267:39: error: request for member 'order' in something not a structure or union 267 | if ((err = mp_read_radix(tmp, cu->order, 16)) != CRYPT_OK) continue; | ^~ CryptX.xs:268:31: error: 'key->dp' is a pointer; did you mean to use '->'? 268 | if ((mp_cmp(tmp, key->dp.order) != LTC_MP_EQ)) continue; | ^ | -> CryptX.xs:269:39: error: request for member 'A' in something not a structure or union 269 | if ((err = mp_read_radix(tmp, cu->A, 16)) != CRYPT_OK) continue; | ^~ CryptX.xs:270:31: error: 'key->dp' is a pointer; did you mean to use '->'? 270 | if ((mp_cmp(tmp, key->dp.A) != LTC_MP_EQ)) continue; | ^ | -> CryptX.xs:271:39: error: request for member 'B' in something not a structure or union 271 | if ((err = mp_read_radix(tmp, cu->B, 16)) != CRYPT_OK) continue; | ^~ CryptX.xs:272:31: error: 'key->dp' is a pointer; did you mean to use '->'? 272 | if ((mp_cmp(tmp, key->dp.B) != LTC_MP_EQ)) continue; | ^ | -> CryptX.xs:273:39: error: request for member 'Gx' in something not a structure or union 273 | if ((err = mp_read_radix(tmp, cu->Gx, 16)) != CRYPT_OK) continue; | ^~ CryptX.xs:274:31: error: 'key->dp' is a pointer; did you mean to use '->'? 274 | if ((mp_cmp(tmp, key->dp.base.x) != LTC_MP_EQ)) continue; | ^ | -> CryptX.xs:275:39: error: request for member 'Gy' in something not a structure or union 275 | if ((err = mp_read_radix(tmp, cu->Gy, 16)) != CRYPT_OK) continue; | ^~ CryptX.xs:276:31: error: 'key->dp' is a pointer; did you mean to use '->'? 276 | if ((mp_cmp(tmp, key->dp.base.y) != LTC_MP_EQ)) continue; | ^ | -> CryptX.xs:277:18: error: 'key->dp' is a pointer; did you mean to use '->'? 277 | if (key->dp.cofactor != cu->cofactor) continue; | ^ | -> CryptX.xs:277:33: error: request for member 'cofactor' in something not a structure or union 277 | if (key->dp.cofactor != cu->cofactor) continue; | ^~ CryptX.xs:281:10: error: request for member 'prime' in something not a structure or union 281 | if (cu->prime && cu->OID) { | ^~ CryptX.xs:281:23: error: request for member 'OID' in something not a structure or union 281 | if (cu->prime && cu->OID) { | ^~ CryptX.xs:282:38: error: 'key->dp' is a pointer; did you mean to use '->'? 282 | for (i = 0; i < 16; i++) key->dp.oid[i] = 0; | ^ | -> CryptX.xs:283:38: error: request for member 'OID' in something not a structure or union 283 | for (i = 0, j = 0; i < strlen(cu->OID); i++) { | ^~ CryptX.xs:284:14: error: request for member 'OID' in something not a structure or union 284 | if (cu->OID[i] == '.') { | ^~ CryptX.xs:287:18: error: request for member 'OID' in something not a structure or union 287 | else if(cu->OID[i] >= '0' && cu->OID[i] <= '9') { | ^~ CryptX.xs:287:39: error: request for member 'OID' in something not a structure or union 287 | else if(cu->OID[i] >= '0' && cu->OID[i] <= '9') { | ^~ CryptX.xs:288:17: error: 'key->dp' is a pointer; did you mean to use '->'? 288 | key->dp.oid[j] = key->dp.oid[j] * 10 + (cu->OID[i] - '0'); | ^ | -> CryptX.xs:288:34: error: 'key->dp' is a pointer; did you mean to use '->'? 288 | key->dp.oid[j] = key->dp.oid[j] * 10 + (cu->OID[i] - '0'); | ^ | -> CryptX.xs:288:52: error: request for member 'OID' in something not a structure or union 288 | key->dp.oid[j] = key->dp.oid[j] * 10 + (cu->OID[i] - '0'); | ^~ CryptX.xs:294:13: error: 'key->dp' is a pointer; did you mean to use '->'? 294 | key->dp.oidlen = j + 1; | ^ | -> CryptX.xs: In function '_ecc_set_curve_from_SV': CryptX.xs:332:11: error: unknown type name 'ltc_ecc_curve' 332 | const ltc_ecc_curve *cu; | ^~~~~~~~~~~~~ CryptX.xs:334:9: warning: implicit declaration of function 'ecc_find_curve' [-Wimplicit-function-declaration] 334 | if (ecc_find_curve(ptr_crv, &cu) != CRYPT_OK) croak("FATAL: ecparams: unknown curve '%s'", ptr_crv); | ^~~~~~~~~~~~~~ CryptX.xs:335:12: warning: implicit declaration of function 'ecc_set_curve' [-Wimplicit-function-declaration] 335 | return ecc_set_curve(cu, key); | ^~~~~~~~~~~~~ CryptX.xs:339:5: error: unknown type name 'ltc_ecc_curve' 339 | ltc_ecc_curve cu = { 0 }; | ^~~~~~~~~~~~~ CryptX.xs:360:7: error: request for member 'OID' in something not a structure or union 360 | cu.OID = (sv_oid && SvOK(*sv_oid)) ? SvPV_nolen(*sv_oid) : NULL; | ^ CryptX.xs:362:7: error: request for member 'prime' in something not a structure or union 362 | cu.prime = SvPV_nolen(*sv_prime); | ^ CryptX.xs:363:7: error: request for member 'A' in something not a structure or union 363 | cu.A = SvPV_nolen(*sv_A); | ^ CryptX.xs:364:7: error: request for member 'B' in something not a structure or union 364 | cu.B = SvPV_nolen(*sv_B); | ^ CryptX.xs:365:7: error: request for member 'order' in something not a structure or union 365 | cu.order = SvPV_nolen(*sv_order); | ^ CryptX.xs:366:7: error: request for member 'Gx' in something not a structure or union 366 | cu.Gx = SvPV_nolen(*sv_Gx); | ^ CryptX.xs:367:7: error: request for member 'Gy' in something not a structure or union 367 | cu.Gy = SvPV_nolen(*sv_Gy); | ^ CryptX.xs:368:7: error: request for member 'cofactor' in something not a structure or union 368 | cu.cofactor = (unsigned long)SvUV(*sv_cofactor); | ^ CryptX.xs:371:16: error: 'key->dp' is a pointer; did you mean to use '->'? 371 | if (key->dp.oidlen == 0) _ecc_oid_lookup(key); | ^ | -> CryptX.xs: In function 'XS_Crypt__Misc__radix_to_bin': CryptX.xs:425:11: warning: 'mp_unsigned_bin_size' is deprecated: replaced by mp_ubin_size [-Wdeprecated-declarations] 425 | len = mp_unsigned_bin_size(&mpi); | ^~~ In file included from CryptX.xs:23: /usr/include/tommath.h:731:33: note: declared here 731 | MP_DEPRECATED(mp_ubin_size) int mp_unsigned_bin_size(const mp_int *a) MP_WUR; | ^~~~~~~~~~~~~~~~~~~~ CryptX.xs:434:13: warning: 'mp_to_unsigned_bin' is deprecated: replaced by mp_to_ubin [-Wdeprecated-declarations] 434 | if (mp_to_unsigned_bin(&mpi, out_data) != MP_OKAY) { | ^~ In file included from CryptX.xs:23: /usr/include/tommath.h:733:34: note: declared here 733 | MP_DEPRECATED(mp_to_ubin) mp_err mp_to_unsigned_bin(const mp_int *a, unsigned char *b) MP_WUR; | ^~~~~~~~~~~~~~~~~~ CryptX.xs: In function 'XS_Crypt__Misc__bin_to_radix': CryptX.xs:467:11: warning: 'mp_read_unsigned_bin' is deprecated: replaced by mp_from_ubin [-Wdeprecated-declarations] 467 | if (mp_read_unsigned_bin(&mpi, in_data, (unsigned long)len) == CRYPT_OK) { | ^~ In file included from CryptX.xs:23: /usr/include/tommath.h:732:36: note: declared here 732 | MP_DEPRECATED(mp_from_ubin) mp_err mp_read_unsigned_bin(mp_int *a, const unsigned char *b, int c) MP_WUR; | ^~~~~~~~~~~~~~~~~~~~ CryptX.xs:483:15: warning: 'mp_toradix' is deprecated: replaced by mp_to_radix [-Wdeprecated-declarations] 483 | if (mp_toradix(&mpi, out_data, radix) == MP_OKAY) { | ^~ In file included from CryptX.xs:23: /usr/include/tommath.h:750:35: note: declared here 750 | MP_DEPRECATED(mp_to_radix) mp_err mp_toradix(const mp_int *a, char *str, int radix) MP_WUR; | ^~~~~~~~~~ CryptX.xs: In function 'XS_Crypt__Misc_encode_b64': CryptX.xs:524:67: warning: pointer targets in passing argument 3 of 'base64url_encode' differ in signedness [-Wpointer-sign] 524 | rv = base64url_encode(in_data, (unsigned long)in_len, out_data, &out_len); | ^~~~~~~~ | | | char * In file included from /usr/include/tomcrypt.h:92, from CryptX.xs:22: /usr/include/tomcrypt_misc.h:23:40: note: expected 'unsigned char *' but argument is of type 'char *' 23 | unsigned char *out, unsigned long *outlen); | ~~~~~~~~~~~~~~~^~~ CryptX.xs:526:64: warning: pointer targets in passing argument 3 of 'base64_encode' differ in signedness [-Wpointer-sign] 526 | rv = base64_encode(in_data, (unsigned long)in_len, out_data, &out_len); | ^~~~~~~~ | | | char * In file included from /usr/include/tomcrypt.h:92, from CryptX.xs:22: /usr/include/tomcrypt_misc.h:13:40: note: expected 'unsigned char *' but argument is of type 'char *' 13 | unsigned char *out, unsigned long *outlen); | ~~~~~~~~~~~~~~~^~~ CryptX.xs: In function 'XS_Crypt__Misc_decode_b64': CryptX.xs:560:18: warning: implicit declaration of function 'base64url_sane_decode'; did you mean 'base64url_strict_decode'? [-Wimplicit-function-declaration] 560 | rv = base64url_sane_decode(in_data, (unsigned long)in_len, out_data, &out_len); | ^~~~~~~~~~~~~~~~~~~~~ | base64url_strict_decode CryptX.xs:562:18: warning: implicit declaration of function 'base64_sane_decode'; did you mean 'base64url_decode'? [-Wimplicit-function-declaration] 562 | rv = base64_sane_decode(in_data, (unsigned long)in_len, out_data, &out_len); | ^~~~~~~~~~~~~~~~~~ | base64url_decode CryptX.xs: In function 'XS_Crypt__Misc_encode_b32r': CryptX.xs:588:27: error: 'BASE32_RFC4648' undeclared (first use in this function) 588 | if (ix == 0) id = BASE32_RFC4648; | ^~~~~~~~~~~~~~ CryptX.xs:589:27: error: 'BASE32_BASE32HEX' undeclared (first use in this function) 589 | if (ix == 1) id = BASE32_BASE32HEX; | ^~~~~~~~~~~~~~~~ CryptX.xs:590:27: error: 'BASE32_ZBASE32' undeclared (first use in this function) 590 | if (ix == 2) id = BASE32_ZBASE32; | ^~~~~~~~~~~~~~ CryptX.xs:591:27: error: 'BASE32_CROCKFORD' undeclared (first use in this function) 591 | if (ix == 3) id = BASE32_CROCKFORD; | ^~~~~~~~~~~~~~~~ CryptX.xs:602:17: warning: implicit declaration of function 'base32_encode'; did you mean 'base64_encode'? [-Wimplicit-function-declaration] 602 | err = base32_encode(in_data, (unsigned long)in_len, out_data, &out_len, id); | ^~~~~~~~~~~~~ | base64_encode CryptX.xs: In function 'XS_Crypt__Misc_decode_b32r': CryptX.xs:628:27: error: 'BASE32_RFC4648' undeclared (first use in this function) 628 | if (ix == 0) id = BASE32_RFC4648; | ^~~~~~~~~~~~~~ CryptX.xs:629:27: error: 'BASE32_BASE32HEX' undeclared (first use in this function) 629 | if (ix == 1) id = BASE32_BASE32HEX; | ^~~~~~~~~~~~~~~~ CryptX.xs:630:27: error: 'BASE32_ZBASE32' undeclared (first use in this function) 630 | if (ix == 2) id = BASE32_ZBASE32; | ^~~~~~~~~~~~~~ CryptX.xs:631:27: error: 'BASE32_CROCKFORD' undeclared (first use in this function) 631 | if (ix == 3) id = BASE32_CROCKFORD; | ^~~~~~~~~~~~~~~~ CryptX.xs:642:17: warning: implicit declaration of function 'base32_decode'; did you mean 'base64_decode'? [-Wimplicit-function-declaration] 642 | err = base32_decode(in_data, (unsigned long)in_len, out_data, &out_len, id); | ^~~~~~~~~~~~~ | base64_decode [..] ```
👍 2
xavierba commented 2021-05-31 02:35:28 -05:00 (Migrated from github.com)

I second this request, for the same reason.
I've been talking with @sjaeckel on irc about this already quite some time ago and afaiu some steps toward a release have been made, but it did not materialized yet.

I second this request, for the same reason. I've been talking with @sjaeckel on irc about this already quite some time ago and afaiu some steps toward a release have been made, but it did not materialized yet.
zqyzsj commented 2021-10-17 21:14:16 -05:00 (Migrated from github.com)

we also need a new release.

we also need a new release.
ahmedibrahim6 commented 2022-07-10 17:18:04 -05:00 (Migrated from github.com)

Hello all,

Is there a current development for the library or it stopped by the last release in 2018?
I hope @sjaeckel gives a current status for development. Thanks

Hello all, Is there a current development for the library or it stopped by the last release in 2018? I hope @sjaeckel gives a current status for development. Thanks
sjaeckel commented 2023-01-03 14:53:39 -06:00 (Migrated from github.com)

@babelouest could you please check whether we could still make it for debian 12 if we tagged either

I don't think so, but still asking whether it'd maybe be worth the effort...

@babelouest could you please check whether we could still make it for debian 12 if we tagged either * develop as it is? or * the https://github.com/libtom/libtomcrypt/tree/add-pem-support branch? I don't think so, but still asking whether it'd maybe be worth the effort...
babelouest commented 2023-01-03 17:39:34 -06:00 (Migrated from github.com)

Hello @sjaeckel ,

I've tested both branches master and add-pem-support. They both build and package fine, and the autopkgtests pass too.

In the branch add-pem-support, I have some warnings but they don't make the build to fail since there seem to be the compile flag -Werror -Wall not present.

Both branches are in the salsa repo:

Do you want to run other tests with the debian package?

Hello @sjaeckel , I've tested both branches master and `add-pem-support`. They both build and package fine, and the autopkgtests pass too. In the branch `add-pem-support`, I have some warnings but they don't make the build to fail since there seem to be the compile flag `-Werror -Wall` not present. Both branches are in the salsa repo: - https://salsa.debian.org/debian/libtomcrypt/-/tree/1.18.3.pem - https://salsa.debian.org/debian/libtomcrypt/-/tree/1.18.3.dev Do you want to run other tests with the debian package?
sjaeckel commented 2023-01-04 02:12:14 -06:00 (Migrated from github.com)

I've tested both branches master and add-pem-support. They both build and package fine, and the autopkgtests pass too.

Cool, thanks.

Could you please check https://github.com/libtom/libtommath/issues/418#issuecomment-1369023525 and recreate what @dod38fr did with the two library versions? I'm nearly certain that ltc would also need an ABI major bump, which in turn would also mean that we won't be able to bring it to Bookworm!?

> I've tested both branches master and `add-pem-support`. They both build and package fine, and the autopkgtests pass too. Cool, thanks. Could you please check https://github.com/libtom/libtommath/issues/418#issuecomment-1369023525 and recreate what @dod38fr did with the two library versions? I'm nearly certain that ltc would also need an ABI major bump, which in turn would also mean that we won't be able to bring it to Bookworm!?
babelouest commented 2023-01-04 07:12:06 -06:00 (Migrated from github.com)

Indeed, the symbols file will have a huge change, I haven't seen it yesterday. The library will probably need a transition process before migrating to testing.

Due to the timing, I'm not sure the new version will be available in Bookworm though, because it requires a new release, then the new package will need to go through the NEW queue process.

Indeed, the symbols file will have a huge change, I haven't seen it yesterday. The library will probably need a transition process before migrating to testing. Due to the timing, I'm not sure the new version will be available in Bookworm though, because it requires a new release, then the new package will need to go through the NEW queue process.
dod38fr commented 2023-01-05 10:20:14 -06:00 (Migrated from github.com)

And no new transition will be possible after jan 12th due to first stage of freeze.

And no new transition will be possible after jan 12th due to first stage of freeze.
mohamed-gradient commented 2023-10-05 09:51:14 -05:00 (Migrated from github.com)

@sjaeckel is there an upcoming release for libtomcrypt in the near future?

@sjaeckel is there an upcoming release for libtomcrypt in the near future?
0-wiz-0 commented 2024-07-27 01:06:08 -05:00 (Migrated from github.com)

I'm also looking for a new release that includes the fix for CVE-2019-17362
(see https://github.com/libtom/libtomcrypt/issues/507)

I'm also looking for a new release that includes the fix for CVE-2019-17362 (see https://github.com/libtom/libtomcrypt/issues/507)
sjaeckel commented 2024-07-27 02:50:32 -05:00 (Migrated from github.com)

I will have a look next week.

I will have a look next week.
Neustradamus commented 2024-08-26 23:44:26 -05:00 (Migrated from github.com)

Dear @libtom team,

We are in 2024, the latest release build is 1.18.2 (2018-07-02) - 6 years, 2 moths soon:

It is time to create a new release build with CVE-2019-17362 fix!

Thanks in advance.

PS: Thanks to @kloczek for this ticket from 2021-04-19 - 3 years, 4 months already.

Dear @libtom team, We are in 2024, the latest release build is 1.18.2 (2018-07-02) - 6 years, 2 moths soon: - https://github.com/libtom/libtomcrypt/releases It is time to create a new release build with CVE-2019-17362 fix! Thanks in advance. PS: Thanks to @kloczek for this ticket from 2021-04-19 - 3 years, 4 months already.
sjaeckel commented 2024-08-30 03:17:12 -05:00 (Migrated from github.com)

FTR: even though @kloczek is right and this library should get a new release - I've blocked @Neustradamus from this organisation and all the others I have access to.

A short version of why: https://github.com/sjaeckel/sjaeckel.github.io/issues/1

FTR: even though @kloczek is right and this library should get a new release - I've blocked @Neustradamus from this organisation and all the others I have access to. A short version of why: https://github.com/sjaeckel/sjaeckel.github.io/issues/1
👍 3 👀 1
Ankit-rana commented 2025-01-08 01:15:34 -06:00 (Migrated from github.com)

are we going to create new release that includes the fix for CVE-2019-17362? is there a workaround we can use in meantime.

are we going to create new release that includes the fix for [CVE-2019-17362](https://github.com/advisories/GHSA-x32c-6j92-4hp9)? is there a workaround we can use in meantime.
levitte commented 2025-01-09 03:44:10 -06:00 (Migrated from github.com)

are we going to create new release that includes the fix for CVE-2019-17362? is there a workaround we can use in meantime.

The obvious workaround is to take the patch from #508 and apply it on the 1.18.2 source, then build and install / package. Most package managers have methods to include this sort of patch. For example, the Debian package (Debian version 1.18.2+dfsg-7+b2) already includes this very patch.

> are we going to create new release that includes the fix for [CVE-2019-17362](https://github.com/advisories/GHSA-x32c-6j92-4hp9)? is there a workaround we can use in meantime. The obvious workaround is to take the patch from #508 and apply it on the 1.18.2 source, then build and install / package. Most package managers have methods to include this sort of patch. For example, the Debian package (Debian version 1.18.2+dfsg-7+b2) already includes this very patch.
👍 1
levitte commented 2025-01-09 03:47:58 -06:00 (Migrated from github.com)

In fact, re the Debian package, the patch has been part of it for a while, according to their changelog:

libtomcrypt (1.18.2-3) unstable; urgency=medium

  * d/control: Add package texlive-latex-extra as build-dependency
    (Closes: #952246)
  * Update Standards-Version to 4.5.0 (No change)
  * Fix CVE-2019-17362 based on upstream patch #508

 -- Nicolas Mora <nicolas@babelouest.org>  Sun, 23 Feb 2020 12:51:31 -0500
In fact, re the Debian package, the patch has been part of it for a while, according to their changelog: ``` libtomcrypt (1.18.2-3) unstable; urgency=medium * d/control: Add package texlive-latex-extra as build-dependency (Closes: #952246) * Update Standards-Version to 4.5.0 (No change) * Fix CVE-2019-17362 based on upstream patch #508 -- Nicolas Mora <nicolas@babelouest.org> Sun, 23 Feb 2020 12:51:31 -0500 ```
levitte commented 2025-01-09 03:53:09 -06:00 (Migrated from github.com)

@sjaeckel, I'm not familiar with libtomcrypt's release procedures, but if can I help make it happen in some way, I'm perfectly willing.

@sjaeckel, I'm not familiar with libtomcrypt's release procedures, but if can I help make it happen in some way, I'm perfectly willing.
sjaeckel commented 2025-01-09 09:17:43 -06:00 (Migrated from github.com)

I'm not familiar with libtomcrypt's release procedures

"There's not much to it" ... :-D

We "just" need to go through the history since the last release and pick all bugfixes + maybe improvements which don't break backwards compatibility (without adding new features/APIs) + check that the documentation is updated according to the modifications ... That should then be 1.18.3-rc1

Then we trigger the distro maintainers to testbuild it, [fix potential issues, make a new rc, goto trigger,] and after we got their OK we're done.

if can I help make it happen in some way, I'm perfectly willing.

Cool, that'd be great. Do you need any more info?

> I'm not familiar with libtomcrypt's release procedures "There's not much to it" ... :-D We "just" need to go through the history since the last release and pick all bugfixes + maybe improvements which don't break backwards compatibility (without adding new features/APIs) + check that the documentation is updated according to the modifications ... That should then be 1.18.3-rc1 Then we `trigger` the distro maintainers to testbuild it, [fix potential issues, make a new rc, goto `trigger`,] and after we got their OK we're done. > if can I help make it happen in some way, I'm perfectly willing. Cool, that'd be great. Do you need any more info?
babelouest commented 2025-01-09 15:06:02 -06:00 (Migrated from github.com)

Hello,

About the Debian package, the problem will be the same as 2 years ago, the package transition can take time.

The next release Debian Trixie isn't scheduled yet but will most likely happen in the next months, so I don't know if it will happen in time...

Hello, About the Debian package, the problem will be the same as [2 years ago](#issuecomment-1370913585), the package transition can take time. The next release Debian Trixie isn't scheduled yet but will most likely happen in the next months, so I don't know if it will happen in time...
👀 1
sjaeckel commented 2025-01-09 15:34:53 -06:00 (Migrated from github.com)

Thanks for the hint.

Did I understand correctly that 1.18.3 would be less of a problem, but 2.0.0 would fall into this rule that it'd be required to be released before the transition period?

"Next months" as in 2 or 10?

Thanks for the hint. Did I understand correctly that 1.18.3 would be less of a problem, but 2.0.0 would fall into this rule that it'd be required to be released before the transition period? "Next months" as in 2 or 10?
babelouest commented 2025-01-09 15:46:50 -06:00 (Migrated from github.com)

According to this comment, even if it's a minor release, there are major ABI changes, so the transition should take time.

If it's a major release, the transition will also include a package name change, which will be forbidden after freeze. But I'm more concerned about the ABI changes at this point.

"Next months" as in 2 or 10?

We have no indication at the moment but my guess is closer to 2 months than 10...

According to [this comment](#issuecomment-1370600159), even if it's a minor release, there are major ABI changes, so the transition should take time. If it's a major release, the transition will also include a package name change, which will be forbidden after freeze. But I'm more concerned about the ABI changes at this point. > "Next months" as in 2 or 10? We have no indication at the moment but my guess is closer to 2 months than 10...
👍 1
sjaeckel commented 2025-01-10 02:39:52 -06:00 (Migrated from github.com)

Maybe we'll also have a point release first, w/o ABI changes, only fixes on top of the last release.

Maybe we'll also have a point release first, w/o ABI changes, only fixes on top of the last release.
👍 5
enginelesscc commented 2025-09-10 08:38:53 -05:00 (Migrated from github.com)

To no offense of debian or anyone maintaining the packages, but why does that distro control what libtom can do or not do?
Especially if debian can just lock to an older release for abi and call it a day.
Imagine openssl stayed on 0.9 because debian just never had the time to update.

This is like a chicken or egg problem:

  • There have been 3 full releases of Debian since 2018
  • libtom cannot release a new version because Debian 12/13/14/... cant have an abi break.
    -> In return, packages releasing on debian are locked to some old version of libtom, while the developers assumed a newer version since 2018, cycling the abi.

If someone makes a gh release now of ref/develop, would debian suddenly implode, or would it be fine as any clear minded dependency would be locked to a specific major version?

To no offense of debian or anyone maintaining the packages, but why does that distro control what libtom can do or not do? Especially if debian can just lock to an older release for abi and call it a day. Imagine openssl stayed on 0.9 because debian just never had the time to update. This is like a chicken or egg problem: - There have been 3 full releases of Debian since 2018 - libtom cannot release a new version because Debian 12/13/14/... cant have an abi break. -> In return, packages releasing on debian are locked to some old version of libtom, while the developers assumed a newer version since 2018, cycling the abi. If someone makes a gh release now of ref/develop, would debian suddenly implode, or would it be fine as any clear minded dependency would be locked to a specific major version?
sjaeckel commented 2025-09-10 08:57:00 -05:00 (Migrated from github.com)

To no offense of debian or anyone maintaining the packages, but why does that distro control what libtom can do or not do? Especially if debian can just lock to an older release for abi and call it a day. Imagine openssl stayed on 0.9 because debian just never had the time to update.

This is like a chicken or egg problem:

* There have been 3 full releases of Debian since 2018

* libtom cannot release a new version because Debian 12/13/14/... cant have an abi break.
  -> In return, packages releasing on debian are locked to some old version of libtom, while the developers assumed a newer version since 2018, cycling the abi.

You misunderstood something there. Debian is responsible for nothing.

If someone makes a gh release now of ref/develop, would debian suddenly implode, or would it be fine as any clear minded dependency would be locked to a specific major version?

Sure Debian can have an ABI break, currently the libtomcrypt shared library is packaged as libtomcrypt1, this would then become libtomcrypt2.

Debian only packages releases, but I didn't do a new release. Sure, if someone takes develop, and publishes this somewhere as libtomcrypt 2.0 they would only have to persuade the Debian maintainers that they're the new maintainers of the library.

Why didn't I make a new release? Because time, motivation, and open issues that should IMO be fixed before a new release.

> To no offense of debian or anyone maintaining the packages, but why does that distro control what libtom can do or not do? Especially if debian can just lock to an older release for abi and call it a day. Imagine openssl stayed on 0.9 because debian just never had the time to update. > > This is like a chicken or egg problem: > > * There have been 3 full releases of Debian since 2018 > > * libtom cannot release a new version because Debian 12/13/14/... cant have an abi break. > -> In return, packages releasing on debian are locked to some old version of libtom, while the developers assumed a newer version since 2018, cycling the abi. You misunderstood something there. Debian is responsible for nothing. > If someone makes a gh release now of ref/develop, would debian suddenly implode, or would it be fine as any clear minded dependency would be locked to a specific major version? Sure Debian can have an ABI break, currently the libtomcrypt shared library is packaged as libtomcrypt1, this would then become libtomcrypt2. Debian only packages releases, but I didn't do a new release. Sure, if someone takes develop, and publishes this somewhere as libtomcrypt 2.0 they would only have to persuade the Debian maintainers that they're the new maintainers of the library. Why didn't I make a new release? Because time, motivation, and open issues that should IMO be fixed before a new release.
👍 1
enginelesscc commented 2025-09-10 09:10:11 -05:00 (Migrated from github.com)

You misunderstood something there. Debian is responsible for nothing.

Reading the conversations, it does appear as if a 1.19 would not work due to abi break requiring more work at debian-- backreferenced to be used as an excuse to focus on getting more changes so a 2.0 can be made.

My point was not fingerpointing, but that such tiny things seemed to make a new release a bigger inconvenience.

Why didn't I make a new release? Because time, motivation, and open issues that should IMO be fixed before a new release.

Libtom* including *crypt are a wonderful collection of libraries, but due to the last release steming from 2018- and growing list of "I pulled some random commit of libtomcrypt because the last release is ancient and outdated" or "libtomcrypt was not maintained since 2018, therefore it must be insecure, therefore your project consuming it is insecure" will cause more collisions and messes (arguably, more abi/sourcecompat concerns) over time :/

Personally, i don't mind if its a 1.19 or 2.0, if there is an abi break or not, the actual value would come from being able to access a libtom release containing newer code--especially for a baseline so projects consuming libtom have something to work with, while also not having to worry these "scares" of "oh this is from 2018"

It is-- of course-- in your hands to take abi or other concerns as a reason to not make a release, personally I think a lot of libtom would be wasted because sometimes life can take a long time, and if some code is unstable, it could be removed from the release and addressed in the future, or be ifdeffed-- if it is a performance concern, it can be addressed in the future.

> You misunderstood something there. Debian is responsible for nothing. Reading the conversations, it does appear as if a 1.19 would not work due to abi break requiring more work at debian-- backreferenced to be used as an excuse to focus on getting more changes so a 2.0 can be made. My point was not fingerpointing, but that such tiny things seemed to make a new release a bigger inconvenience. > Why didn't I make a new release? Because time, motivation, and open issues that should IMO be fixed before a new release. Libtom* including *crypt are a wonderful collection of libraries, but due to the last release steming from 2018- and growing list of "I pulled some random commit of libtomcrypt because the last release is ancient and outdated" or "libtomcrypt was not maintained since 2018, therefore it must be insecure, therefore *your* project consuming it is insecure" will cause more collisions and messes (arguably, more abi/sourcecompat concerns) over time :/ Personally, i don't mind if its a 1.19 or 2.0, if there is an abi break or not, the actual value would come from being able to access a libtom release containing newer code--especially for a baseline so projects consuming libtom have something to work with, while also not having to worry these "scares" of "oh this is from 2018" It is-- of course-- in your hands to take abi or other concerns as a reason to not make a release, personally I think a lot of libtom would be wasted because sometimes life can take a long time, and if some code is unstable, it could be removed from the release and addressed in the future, or be ifdeffed-- if it is a performance concern, it can be addressed in the future.
dod38fr commented 2025-09-10 09:53:15 -05:00 (Migrated from github.com)

Debian maintainer here.

ABI breakage would be indeed handled by creating libtomcrypt2 package, which is Debian responsibility. However, we do not want library version to be different from upstream, which means that libtomcrypt so version of the library must also be increased to 2. This is upstream responsibility.

All the best

Debian maintainer here. ABI breakage would be indeed handled by creating libtomcrypt2 package, which is Debian responsibility. However, we do not want library version to be different from upstream, which means that libtomcrypt so version of the library must also be increased to 2. This is upstream responsibility. All the best
👍 1
jblu42 commented 2025-09-17 08:10:55 -05:00 (Migrated from github.com)

Libtom* including *crypt are a wonderful collection of libraries, but due to the last release steming from 2018- and growing list of "I pulled some random commit of libtomcrypt because the last release is ancient and outdated" or "libtomcrypt was not maintained since 2018, therefore it must be insecure, therefore your project consuming it is insecure" will cause more collisions and messes (arguably, more abi/sourcecompat concerns) over time :/

Just to support this argument, libtomcrypt has been flagged EOL in a certification we are currently doing because the last release is from 2018 are we are trying to argue our way out of this.

> Libtom* including *crypt are a wonderful collection of libraries, but due to the last release steming from 2018- and growing list of "I pulled some random commit of libtomcrypt because the last release is ancient and outdated" or "libtomcrypt was not maintained since 2018, therefore it must be insecure, therefore _your_ project consuming it is insecure" will cause more collisions and messes (arguably, more abi/sourcecompat concerns) over time :/ Just to support this argument, libtomcrypt has been flagged EOL in a certification we are currently doing because the last release is from 2018 are we are trying to argue our way out of this.
😕 3
sjaeckel commented 2025-09-17 08:26:22 -05:00 (Migrated from github.com)

Just to support this argument, libtomcrypt has been flagged EOL in a certification we are currently doing because the last release is from 2018 are we are trying to argue our way out of this.

That's sad to hear.

If you have budget for some certification, you could maybe also sponsor the necessary development for the next release!?

> Just to support this argument, libtomcrypt has been flagged EOL in a certification we are currently doing because the last release is from 2018 are we are trying to argue our way out of this. That's sad to hear. If you have budget for some certification, you could maybe also sponsor the necessary development for the next release!?
jblu42 commented 2025-09-17 08:57:34 -05:00 (Migrated from github.com)

I know, this is the usual OpenSource problem, we all benefit from your work, but there is no value given back. Unfortunately I have no control over any budget, just executing, and I am not sure if I will be able to convince my company to contribute. But if sponsoring is the problem, maybe you should put up a call for help / sponsoring in general, if more people are interested, then maybe there is support possible. I also have no idea what your target for sponsoring would be.

I know, this is the usual OpenSource problem, we all benefit from your work, but there is no value given back. Unfortunately I have no control over any budget, just executing, and I am not sure if I will be able to convince my company to contribute. But if sponsoring is the problem, maybe you should put up a call for help / sponsoring in general, if more people are interested, then maybe there is support possible. I also have no idea what your target for sponsoring would be.
enginelesscc commented 2025-09-17 08:59:11 -05:00 (Migrated from github.com)

Agreed, setting up donation info on the repo would make it easier :)

Agreed, setting up donation info on the repo would make it easier :)
uilianries commented 2026-02-25 04:45:52 -06:00 (Migrated from github.com)

Hello! Do you have any updates about giving a new release? So far, from version 1.8.2 to develop, there are +900 files changed: https://github.com/libtom/libtomcrypt/compare/v1.18.2...develop. I understand it should be hard to generate a changelog and prepare all artifacts. Regards

Hello! Do you have any updates about giving a new release? So far, from version 1.8.2 to develop, there are +900 files changed: https://github.com/libtom/libtomcrypt/compare/v1.18.2...develop. I understand it should be hard to generate a changelog and prepare all artifacts. Regards
PatrickvL commented 2026-04-16 01:56:32 -05:00 (Migrated from github.com)

@sjaeckel Good to see you're still (again?) actively contributing. As @uilianries above, it would be good to know if a release would be imminent, as https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/2510 would like to use it too. TIA

@sjaeckel Good to see you're still (again?) actively contributing. As @uilianries above, it would be good to know if a release would be imminent, as https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/pull/2510 would like to use it too. TIA
sjaeckel commented 2026-04-16 02:21:31 -05:00 (Migrated from github.com)

Yes, we're going to have a point release soon and sometime after that a 2.0 from develop.

Yes, we're going to have a point release soon and sometime after that a 2.0 from develop.
👍 3 🚀 2
chwalap commented 2026-08-26 05:09:58 -05:00 (Migrated from github.com)

@sjaeckel
When can we expect the point release?

@sjaeckel When can we expect the point release?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
archive/20260923T145428Z-rescue/illiliti/static
archive/20260923T145428Z-rescue/afonsojanu/fix/pss-decode-siglen-check
archive/20260923T145428Z-rescue/joshbuddy/win64
pr/pqc1
archive/20260923T151904Z-recovered/pr/pqc1
archive/20260923T151904Z-recovered-3/pr/pqc1
archive/20260923T151904Z-recovered-2/pr/pqc1
archive/20260923T145428Z-rescue/MarekKnapek/serpent-accelerated
pr/sm2
pr/xsalsa20-hsalsa20
no-struct-padding
archive/20260923T145428Z-rescue/tags/actions/runs/24841441691
archive/20260923T145428Z-rescue/tags/actions/runs/24821326727
archive/20260923T145428Z-rescue/tags/actions/runs/24769074231
archive/20260923T145428Z-rescue/tags/actions/runs/24762001029
archive/20260923T145428Z-rescue/tags/actions/runs/24646701081
archive/20260923T145428Z-rescue/tags/actions/runs/24646842340
archive/20260923T145428Z-rescue/tags/actions/runs/24595690628
archive/20260923T145428Z-rescue/tags/actions/runs/24590716227
archive/20260923T145428Z-rescue/tags/actions/runs/24590979385
x509_import
appveyor/sha-ni
ci/develop
debug-wycheproof-failures
turboshake
appveyor/aesni
ci/x509_import
wip/pr/477
remove-prng-registry
pr/macro-LTC_NO_WIN32_BCRYPT
fix-perl-cryptx-99
appveyor/msvc2012
fix-alignment
archive/20260923T145428Z-rescue/assarbad/premake4-vs-project-generation
fix-622
regression-test-for-546
archive/20260923T145428Z-rescue/cntrump/pr_swiftpm_support
timing-benchmark
fix-b64-zero-length-array
openssh-privkey
archive/20260923T145428Z-rescue/FredeJ/visualstudio_solution
travis-test
streams-functions_in_separate_files
streams-enforce-call-policy
pr/autotools
master
feature/gcm_file
feature/eccAddA
v1.18.2
v1.18.1
v1.18.0
v1.18.0-rc5
v1.18.0-rc4
v1.18.0-rc3
v1.18.0-rc2
v1.18.0-rc1
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.09
1.08
1.07
1.06
1.05
1.04
1.03
1.02
1.01
1.00
0.99
0.98
0.97b
0.97a
0.97
0.96
0.95
0.94
0.93
0.92
0.91
0.90
0.89
0.88
0.87
0.86
0.85
0.84
0.83
0.82
0.81
0.80
0.79
0.78
0.77
0.76
0.75
Labels
Clear labels   
bug

   
duplicate

   
enhancement

   
feature

   
help wanted

   
improve API

   
invalid

   
needs documentation

   
not-planned
This ticket is not planned to be implemented and/or fixed from the core team.

  
rtfm

   
stale

   
support

   
wishlist
No labels
bug
duplicate
enhancement
feature
help wanted
improve API
invalid
needs documentation
not-planned
rtfm
stale
support
wishlist
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-libtom/libtomcrypt#568
No description provided.