pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2023-11-28T13:44:10Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/10138gethrvtime() overflow on netbsd2023-11-28T13:44:10ZHenrik (Grubba) Grubbströmgethrvtime() overflow on netbsdFrom the Pike developers mailinglist/LysLysKOM 26092611:
```
26092611 2023-11-24 04:29 /35 rader/ <william@welliver.org>
Sänt av: SRS0=LsSK=HF=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-11-24 04:29 av Brevbär...From the Pike developers mailinglist/LysLysKOM 26092611:
```
26092611 2023-11-24 04:29 /35 rader/ <william@welliver.org>
Sänt av: SRS0=LsSK=HF=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-11-24 04:29 av Brevbäraren
Extern mottagare: pike-devel@lists.lysator.liu.se
Mottagare: Pike (-) developers forum <21444>
Ärende: gethrvtime() overflow on netbsd
------------------------------------------------------------
```
Hello all,
I've been working on a new stable release and in the course of the usual
checks, I noticed that pike farm builds are failing on netbsd (9.3). A
little investigation shows that the benchmark is effectively timing out.
I think this failure is caused by the code that limits a test to a given
amount of time.
Basically, the elapsed time is calculated as final_time - start_time as
returned by `gethrvtime()`, and it appears that on netbsd, there's (I'm
assuming) an overflow that causes the elapsed time to become negative.
It happens often enough that the total amount of time spent on a given
set of test runs becomes increasingly negative, essentially running any
test forever.
I"m sure that there's a better solution but I'd like to suggest that in
the interim, a simple check be added to ignore any negative times:
In `Tools.Shoot.run_sub()`:
From:
```
tg += (hrt - start_cpu) / 1000000.0;
```
To:
```
int te = hrt - start_cpu;
if(te < 0 ) te = 0;
tg += te / 1000000.0;
```
Does anyone have any objection to me making this change in 9.0 and 8.0?
Bill
```
(26092611) /<william@welliver.org>/-----------------
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10130Internal compiler error triggered by syntax error in implicit create argument...2023-11-01T08:21:13ZHenrik (Grubba) GrubbströmInternal compiler error triggered by syntax error in implicit create argument listObserved in the wild:
```
$ cat Bang.pmod
class Bang(pang) {
void bang() {}
}
$ pike -M.
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Bang;
Bang.pmod:1:syntax error, unexpected ')', expecting TOK_IDENTIFIER
...Observed in the wild:
```
$ cat Bang.pmod
class Bang(pang) {
void bang() {}
}
$ pike -M.
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Bang;
Bang.pmod:1:syntax error, unexpected ')', expecting TOK_IDENTIFIER
Bang.pmod:2:Missing ';'.
Bang.pmod:3:Missing ';'.
/var/tmp/portage/dev-lang/pike-8.0.1738-r3/work/Pike-v8.0.1738/src/block_allocator.c:311: Fatal error:
ptr 0x55a2c30fd730 not in any page.
Backtrace at time of fatal:
-:1:
PikeCompiler("", Tools.Hilfe.StdinHilfe()->HilfeCompileHandler(), -1, -1, UNDEFINED, UNDEFINED)->compile()
-:1:
DefaultCompilerEnvironment->compile(PikeCompiler("", Tools.Hilfe.StdinHilfe()->HilfeCompileHandler(), -1, -1, UNDEFINED, UNDEFINED))
/usr/lib64/pike/master.pike:743:
compile_string("mapping(string:mixed) ___hilfe = ___Hilfe->variables;\n# 1\nmixed ___HilfeWrapper() { return Bang; ; }\n","HilfeInput",Tools.Hilfe.StdinHilfe()->HilfeCompileHandler(),UNDEFINED,UNDEFINED,UNDEFINED)
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:2311:
Tools.Hilfe.StdinHilfe()->hilfe_compile("mixed ___HilfeWrapper() { return Bang; ; }",UNDEFINED)
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:2352:
Tools.Hilfe.StdinHilfe()->evaluate("mixed ___HilfeWrapper() { return Bang; ; }",1)
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:2097:
Tools.Hilfe.StdinHilfe()->parse_expression(Tools.Hilfe.Expression(({ /* 2 elements */
"Bang",
";"
})))
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:1651:
Tools.Hilfe.StdinHilfe()->add_buffer("Bang;")
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:1598:
Tools.Hilfe.StdinHilfe()->add_input_line("Bang;")
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:2562:
Tools.Hilfe.StdinHilfe()->create(UNDEFINED)
/usr/lib64/pike/modules/Tools.pmod/Hilfe.pmod:2481: Tools.Hilfe.StdinHilfe()
Aborted
```
The crash seems to be due to the nested program not being popped correctly.Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10129System.TM timezone confusion2023-11-04T09:09:09ZHenrik (Grubba) GrubbströmSystem.TM timezone confusionFrom LysLysKOM 26017901:
```
26017901 2023-10-12 17:13 /39 rader/ ceder (-) Per Cederqvist
Mottagare: Pike (-) developers forum <21425>
Ärende: System.TM timezone confusion
------------------------------------------------------------
``...From LysLysKOM 26017901:
```
26017901 2023-10-12 17:13 /39 rader/ ceder (-) Per Cederqvist
Mottagare: Pike (-) developers forum <21425>
Ärende: System.TM timezone confusion
------------------------------------------------------------
```
System.TM does not work as advertised. The documentation says that
the timezone will be UTC when you supply a number to the constructor,
but that does not appear to be the case. Note how the timezone is
CEST no matter how I initialize the TM object, but the reported hours
differ:
```
$ pike
Pike v9.0 release 1 running Hilfe v3.5 (Incremental Pike Frontend)
> mixed t = System.TM(1697121800);
> t;
(1) Result: System.TM(Thu Oct 12 15:43:20 2023 CEST)
> t->gmtime(1697121800);
(2) Result: 1
> t;
(3) Result: System.TM(Thu Oct 12 15:43:20 2023 CEST)
> t->localtime(1697121800);
(4) Result: 1
> t;
(5) Result: System.TM(Thu Oct 12 16:43:20 2023 CEST)
```
The result (5) makes sense: it matches what I would expect. But
the hour should be set to 14, not 15:
```
> mixed c = Calendar.ISO.Second(1697121800);
> c->set_timezone("UTC");
> c;
(5) Result: Second(Thu 12 Oct 2023 16:43:20 CEST)
> mixed u = c->set_timezone("UTC");
> u;
(6) Result: Second(Thu 12 Oct 2023 14:43:20 UTC)
```
This also agrees with my private utility for converting a time_t value
to the local timezone and UTC (this one is written in Python):
```
$ time_t2date 1697121800
2023-10-12 16:43:20 CEST
2023-10-12 14:43:20 GMT
```
Tested on the current master, and a few older Pike versions.
```
(26017901) /ceder (-) Per Cederqvist/---------------
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10123Overloading of getter/setters with plain variables seems broken2023-05-16T16:06:23ZHenrik (Grubba) GrubbströmOverloading of getter/setters with plain variables seems brokenFrom `jonasw` @ Roxen Slack:
```
class Op
{
object `data() {}
string _sprintf() {
return sprintf("%s(%O)",
function_name(object_program(this)),
data || "-");
}
}
class Op1(object mupp)
{
...From `jonasw` @ Roxen Slack:
```
class Op
{
object `data() {}
string _sprintf() {
return sprintf("%s(%O)",
function_name(object_program(this)),
data || "-");
}
}
class Op1(object mupp)
{
inherit Op;
object `data() { return mupp; }
}
class Op2(object data)
{
inherit Op;
// object `data() { return this::data; }
}
class Data()
{
string _sprintf() { return "DATA"; }
}
void main()
{
object data = Data();
werror("op1: %O, op2: %O\n", Op1(data), Op2(data));
}
```
When the above is run (Pike 8.0.1832 or 9.0.1), the following is output:
```
op1: Op1(DATA), op2: Op2("-")
```
The comment in `Op2` triggers a compilation error due to the name clash between the variable `data` and the getter of the same name.
It looks like the reference to `data` in `Op()->_sprintf()` has a `local`/`inline` scope even though `data` has not been declared as such.Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10121Filesystem.System()->find() is broken.2023-08-22T10:59:14ZHenrik (Grubba) GrubbströmFilesystem.System()->find() is broken.The filtering of in `find()` attempts to call the value `1` (if there are any subdirectories). This seems to be code that was missed in 9ae59318485754881ba0798de5dfac12c1abede9:
```
array find(void|function(Filesystem.Stat, __unknown__.....The filtering of in `find()` attempts to call the value `1` (if there are any subdirectories). This seems to be code that was missed in 9ae59318485754881ba0798de5dfac12c1abede9:
```
array find(void|function(Filesystem.Stat, __unknown__...:int) mask,
mixed ... extra)
{
array(Filesystem.Stat) res = ({});
array(Filesystem.Stat) d = get_stats() || ({});
array(Filesystem.Stat) r = filter(d, "isdir");
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10111Calendar module in Pike 8.0 is broken near 1900-01-01T00:00:00 in some timezo...2023-08-22T10:59:14ZHenrik (Grubba) GrubbströmCalendar module in Pike 8.0 is broken near 1900-01-01T00:00:00 in some timezones.```
$ TZ=UTC pike
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 UTC)
$ TZ=Europe/Stockholm pike
Pike v8.0 release 1738 running Hil...```
$ TZ=UTC pike
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 UTC)
$ TZ=Europe/Stockholm pike
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
Failed to dwim time from "19000101T000000"
/usr/lib64/pike/modules/Calendar.pmod/YMD.pike:3303:
ISO.dwim_time("19000101T000000",UNDEFINED)
> Calendar.dwim_time("19000101T000013");
Failed to dwim time from "19000101T000013"
/usr/lib64/pike/modules/Calendar.pmod/YMD.pike:3303:
ISO.dwim_time("19000101T000013",UNDEFINED)
> Calendar.dwim_time("19000101T000014");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 CET)
> Calendar.dwim_time("18991231T23:59:59");
(2) Result: Second(Sun 31 Dec 1899 23:59:59 SET)
> Calendar.dwim_time("19000101T000015");
(3) Result: Second(Mon 1 Jan 1900 0:00:01 CET)
```
Note that when the parsing succeeds, the resulting seconds count is off by 14 seconds.
The above works fine in Pike 9.0 (aka master):
```
$ TZ=Europe/Stockholm ./pike
Pike v9.0 release 0 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 CET)
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10094Standards.IIM.get_information() returns ([]) for some files that have IPTC-II...2022-11-16T10:16:08ZHenrik (Grubba) GrubbströmStandards.IIM.get_information() returns ([]) for some files that have IPTC-IIM metadata.```
Pike v8.0 release 1783 running Hilfe v3.5 (Incremental Pike Frontend)
> Stdio.File fd = Stdio.File("iim.jpg", "rb");
> Standards.IIM.get_information(fd);
(1) Result: ([ ])
```
Enabling the `werrors` in `decode_photoshop_data()` gives...```
Pike v8.0 release 1783 running Hilfe v3.5 (Incremental Pike Frontend)
> Stdio.File fd = Stdio.File("iim.jpg", "rb");
> Standards.IIM.get_information(fd);
(1) Result: ([ ])
```
Enabling the `werrors` in `decode_photoshop_data()` gives:
```
> Standards.IIM.get_information(fd);
blocks: ({ /* 1 element */
"\4iptc\0\0\0\1\265\34\2\5\0.Britain Scotland Ukraine Nations League Soccer\34\2\n"
"\0\1""5\34\2\17\0\1S\34\2\24\0\bSOC WSOC\34\2""7\0\b20220921\34\2<\0\v152917+0000\34\2P\0\rScott Heppell\34\2U\0\3STR\34\2Z\0\aGlasgow\34\2e\0\3GBR\34\2n\0\2AP\34\2s\0\2AP\34\2t\0""8Copyright 2022 The Associated Press. All rights reserved\34\2x\0\307Ukrainian fans cheer prior to the star of the UEFA Nations League soccer match between Scotland and Ukraine, at Hampden Park, in Glasgow, Scotland, Wednesday, Sept. 21, 2022. (AP Photo/Scott Heppell)\34\2z\0\2HA\0"
})
block: "046970746300000001b51c0205002e4272697461696e2053636f746c616e6420556b7261696e65204e6174696f6e73204c656167756520536f636365721c020a0001351c020f0001531c02140008534f432057534f431c0237000832303232303932311c023c000b3135323931372b303030301c0250000d53636f74742048657070656c6c1c025500035354521c025a0007476c6173676f771c026500034742521c026e000241501c0273000241501c02740038436f70797269676874203230323220546865204173736f6369617465642050726573732e20416c6c207269676874732072657365727665641c027800c7556b7261696e69616e2066616e73206368656572207072696f7220746f207468652073746172206f66207468652055454641204e6174696f6e73204c656167756520736f63636572206d61746368206265747765656e2053636f746c616e6420616e6420556b7261696e652c2061742048616d7064656e205061726b2c20696e20476c6173676f772c2053636f746c616e642c205765646e65736461792c20536570742e2032312c20323032322e202841502050686f746f2f53636f74742048657070656c6c291c027a0002484100"
dsclen: 4
block_length: 1
actual length: 1
info: "\265"
Short info "\265"
(1) Result: ([ ])
```
The cause seems to be that there is an extra byte of NUL-padding after the Photoshop 6.0 header description text ("iptc"). https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/ says that the pascal string should be padded to an even length (ie including the length byte).Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10090Hilfe does not like anonymous classes with implicit create().2022-09-06T08:56:08ZHenrik (Grubba) GrubbströmHilfe does not like anonymous classes with implicit create().```
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> class (string bar){}("foo")->bar;
Compiler Error: 2: syntax error, unexpected ';'
Compiler Error: 2: Missing ')'.
Compiler Error: 3: Missing ';'.
Compiler Error:...```
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> class (string bar){}("foo")->bar;
Compiler Error: 2: syntax error, unexpected ';'
Compiler Error: 2: Missing ')'.
Compiler Error: 3: Missing ';'.
Compiler Error: 3: Unexpected end of file.
Compiler Error: 3: Missing '}'.
Compiler Error: 3: Opening '{' was here.
Compiler Error: 3: Unexpected end of file.
Compiler Error: 1: Got : string(102..111).
Compiler Error: 1: Index : string(97..114).
> dump wrapper
Last compiled wrapper:
001: mapping(string:mixed) ___hilfe = ___Hilfe->variables;
002: # 1
003: mixed ___HilfeWrapper() { return ("foo")->bar; ; }
004:
```
The same code wrapped in a lambda works fine:
```
> lambda() { return class (string bar){}("foo")->bar; }();
(1) Result: "foo"
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10075Crypto.DSA infinite loop in pkcs_verify()2022-03-01T13:41:06ZJoshua RogersCrypto.DSA infinite loop in pkcs_verify()Hi there,
While doing some tests of Crypto.DSA, I've come across two (likely related) cases of a call to `Crypto.DSA.State()->pkcs_verify()` resulting in an infinite loop in Gmp.
I have two test-cases. One is where `sign` is empty:
```...Hi there,
While doing some tests of Crypto.DSA, I've come across two (likely related) cases of a call to `Crypto.DSA.State()->pkcs_verify()` resulting in an infinite loop in Gmp.
I have two test-cases. One is where `sign` is empty:
```
int main() {
mixed state1 = Crypto.DSA.State();
state1->set_public_key(Gmp.mpz("008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667", 16), Gmp.mpz("00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d", 16), Gmp.mpz("16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde", 16), Gmp.mpz("1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931", 16));
state1->pkcs_verify(String.hex2string("313233343030"), Crypto.SHA224, "");
}
```
and the other is when it is non-empty:
```
int main() {
mixed state1 = Crypto.DSA.State();
state1->set_public_key(Gmp.mpz("008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667", 16), Gmp.mpz("00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d", 16), Gmp.mpz("16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde", 16), Gmp.mpz("1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931", 16));
state1->pkcs_verify(String.hex2string("3130353336323835353638"), Crypto.SHA256, String.hex2string("a2184515521e4c5d26f05590543c696ca2bd04b7754a18107d7f62744fbcb3a52ee80de3dca53339c3f6b2196afe3c540adfeb92686029f2"));
}
```
Unfortunately, I'm not able to offer any suggestions as to why this happens, but please let me know if you have any questions.
Cheers,
JoshPike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10074Crypto.AES.CCM produces incorrect results2021-12-09T09:35:17ZJoshua RogersCrypto.AES.CCM produces incorrect resultsHi there,
While performing some unit tests with Pike's Crypto.AES.CCM, I've run into an issue of the digest function producing "incorrect" results.
During my tests, I'm using two unit tests.
The first test is:
```
key: 1a44f3550688fddb...Hi there,
While performing some unit tests with Pike's Crypto.AES.CCM, I've run into an issue of the digest function producing "incorrect" results.
During my tests, I'm using two unit tests.
The first test is:
```
key: 1a44f3550688fddbc1e5041dc98952c0
iv: 5d2904298f668ba95eaa1797
aad: d55908958b70abee81054cdf3d3df5
msg:
expected digest: 5c71b4f069cfa13b7634db4b13e7be7d
```
And the second test is:
```
key: 439fd5c3b76587d5a601ba6ef8fad214
iv: ed1d316d0834d174c1b5b438
aad: eae252f42d2c71
msg:
expected digest: e8530426cbabf63633ff373159247e38
```
The **second** test results in the the digest value of "e8530426cbabf63633ff373159247e38". This is the same value as seen in openssl using the following C source code (`gcc test.c -lcrypto`):
```
#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>
void str2hex(char *, char*, int);
void printBytes(unsigned char *, size_t );
int main() {
unsigned char *aad, *pt, *key, *nonce;
int Klen, Alen, Nlen, Plen, Tlen, Clen;
int outl = 0;
key = "439fd5c3b76587d5a601ba6ef8fad214";
aad = "eae252f42d2c71";
nonce = "ed1d316d0834d174c1b5b438";
pt = "";
Klen = strlen(key) / 2;
Alen = strlen(aad) / 2;
Nlen = strlen(nonce) / 2;
Plen = strlen(pt) / 2;
Tlen = 16;
Clen = Plen + Tlen;
unsigned char keyy[Klen], aadd[Alen], noncee[Nlen], ptt[Plen];
unsigned char ct[Clen], dt[Plen];
str2hex(key, keyy, Klen);
str2hex(pt, ptt, Plen);
str2hex(aad, aadd, Alen);
str2hex(nonce, noncee, Nlen);
EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new();
EVP_CIPHER_CTX_init(ctx);
EVP_EncryptInit(ctx, EVP_aes_128_ccm(), 0, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, Nlen, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG, Tlen, 0);
EVP_EncryptInit(ctx, 0, keyy, noncee);
EVP_EncryptUpdate(ctx, 0, &outl, 0, Plen);
EVP_EncryptUpdate(ctx, 0, &outl, aadd, Alen);
EVP_EncryptUpdate(ctx, ct, &outl, ptt, Plen);
EVP_EncryptFinal(ctx, &ct[outl], &outl);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_GET_TAG, Tlen, ct + Plen);
printf("plaintext' = %s", pt);
printf("\n");
printf("\nciphertext : ");
printBytes(ct, Clen);
EVP_DecryptInit(ctx, EVP_aes_128_ccm(), 0, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, Nlen, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG, Tlen, ct + Plen);
EVP_DecryptInit(ctx, 0, keyy, noncee);
EVP_DecryptUpdate(ctx, 0, &outl, 0, Plen);
EVP_DecryptUpdate(ctx, 0, &outl, aadd, Alen);
EVP_DecryptUpdate(ctx, dt, &outl, ct, Plen);
EVP_DecryptFinal(ctx, &dt[outl], &outl);
printf("plaintext : ");
printBytes(dt, Plen);
return 0;
}
void str2hex(char *str, char *hex, int len) {
int tt, ss;
unsigned char temp[4];
for (tt = 0, ss = 0; tt < len, ss < 2 * len; tt++, ss += 2) {
temp[0] = '0';
temp[1] = 'x';
temp[2] = str[ss];
temp[3] = str[ss + 1];
hex[tt] = (int) strtol(temp, NULL, 0);
}
}
void printBytes(unsigned char *buf, size_t len) {
int i;
for (i = 0; i < len; i++) {
printf("%02x", buf[i]);
}
printf("\n");
}
```
However, the **first** test does not succeed. Pike produces the digest "7a627cad3a11cb4192566a040d801fa8", while the C code (edited accordingly) produces the expected result, "5c71b4f069cfa13b7634db4b13e7be7d".
The following Pike code annotates my concerns:
```
int main() {
mixed state1 = Crypto.AES.CCM.State();
state1->set_encrypt_key(String.hex2string("1a44f3550688fddbc1e5041dc98952c0"));
state1->set_iv(String.hex2string("5d2904298f668ba95eaa1797"));
state1->update(String.hex2string("d55908958b70abee81054cdf3d3df5"));
string ct1 = state1->crypt(String.hex2string(""));
string dig1 = state1->digest();
if(String.string2hex(dig1) != "5c71b4f069cfa13b7634db4b13e7be7d")
write("First one did not match. Got %s, expected %s.\n", String.string2hex(dig1), "5c71b4f069cfa13b7634db4b13e7be7d");
mixed state2 = Crypto.AES.CCM.State();
state2->set_encrypt_key(String.hex2string("439fd5c3b76587d5a601ba6ef8fad214"));
state2->set_iv(String.hex2string("ed1d316d0834d174c1b5b438"));
state2->update(String.hex2string("eae252f42d2c71"));
string ct2 = state2->crypt(String.hex2string(""));
string dig2 = state2->digest();
if(String.string2hex(dig2) != "e8530426cbabf63633ff373159247e38")
write("Second one did not match. Got %s, expected %s.\n", String.string2hex(dig2), "e8530426cbabf63633ff373159247e38");
}
```
I have no explanation for the incorrect results, unfortunately.
Any support is welcome.
Thank you.Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10072SIGSEGV in Crypto.AES.CCM2021-12-03T17:43:18ZHenrik (Grubba) GrubbströmSIGSEGV in Crypto.AES.CCMFrom LysLysKOM
```
25080935 igår 21:18 /27 rader/ Niels Möller (entering a radioactive zone)
Mottagare: Pike (-) developers forum <21270>
Mottagare: Niels Möller (entering a radioactive zone) <104958>
Mottaget: igår 21:18
Ärende: Bu...From LysLysKOM
```
25080935 igår 21:18 /27 rader/ Niels Möller (entering a radioactive zone)
Mottagare: Pike (-) developers forum <21270>
Mottagare: Niels Möller (entering a radioactive zone) <104958>
Mottaget: igår 21:18
Ärende: Bug in ccm glue?
```
------------------------------------------------------------
Hi, I've received a bug report (from someone at Opera) about a crash
when using Crypto.AES.CCM. Example
```
int main() {
mixed state1 = Crypto.AES.CCM.State();
state1->set_encrypt_key(String.hex2string("bedcfb5a011ebc84600fcb296c15af0d"));
state1->set_iv(String.hex2string("438a547a94ea88dce46c6c85"));
state1->update(String.hex2string(""));
string ct = state1->crypt(String.hex2string(""));
state1->digest();
return 0;
}
```
When I try it (with Pike v8.0, installed as a debian package on
x86_64) it segfaults in nettle_memxor3. As far as I can tell from 5
minutes of printf debugging, crash is inside the call to ->digest().
The set_iv method looks a bit suspicious to me, it doesn't include the
required arguments for the nettle function ccm_set_nonce (and ccm is
generally a bit messier to setup than most other modes). See
http://www.lysator.liu.se/~nisse/nettle/nettle.html#index-ccm_005fset_005fnonce
There may of course be some problem in the nettle library too, in
particular, I would be happier if api misuse resulted in an assert
failure rather than a segfault.
```
(25080935) /Niels Möller (entering a radioactive zone)/
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10070pthread_cond_timedwait() does not normalize tv_nsec2021-11-26T17:10:22ZHenrik (Grubba) Grubbströmpthread_cond_timedwait() does not normalize tv_nsec`pthread_cond_timedwait()` on several OSes (including Linux and MacOS X) apparently does not normalize `tv_nsec`. A timeout with a `tv_sec` of `0` and a `tv_nsec` value above `1000000000` seems to give a zero timeout.
Make `co_wait_time...`pthread_cond_timedwait()` on several OSes (including Linux and MacOS X) apparently does not normalize `tv_nsec`. A timeout with a `tv_sec` of `0` and a `tv_nsec` value above `1000000000` seems to give a zero timeout.
Make `co_wait_timeout()` normalize `tv_nsec`.Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10057Improve error handling in Protocols.DNS2021-03-04T15:07:09ZHenrik (Grubba) GrubbströmImprove error handling in Protocols.DNS`Protocols.DNS` complains the following if the originator has gone away:
```
18:01:07 : DNS: Failed to read UDP packet. Connection refused?
18:01:07 29m28.8s : Attempt to call the NULL-value
18:01:07 : Unknown pro...`Protocols.DNS` complains the following if the originator has gone away:
```
18:01:07 : DNS: Failed to read UDP packet. Connection refused?
18:01:07 29m28.8s : Attempt to call the NULL-value
18:01:07 : Unknown program: 0("foo.example.coms","127.0.0.1",0,80)
18:01:07 : pike/lib/modules/Protocols.pmod/DNS.pmod:2028: Protocols.DNS.global_async_client->generic_get("foo.example.com",mapping[21],-1,0,1,"a","foo.example.com",0,0,80)
18:01:07 : pike/lib/modules/Protocols.pmod/DNS.pmod:1991: Protocols.DNS.global_async_client->rec_data(mapping[3])
18:01:07 : pike/lib/modules/Stdio.pmod/module.pmod:3671: Protocols.DNS.global_async_client->_read_callback()
18:01:07 29m28.8s : -:1: Pike.Backend(0)->`()(3600.0)
```
More reasonable would be to ignore the callback if it is NULL, and to complain about a broken callback if the call fails.Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10055Race-condition in Concurrent.Promise()->finalise()2020-10-26T13:49:08ZHenrik (Grubba) GrubbströmRace-condition in Concurrent.Promise()->finalise()Callbacks may get lost due to a race condition.
```mermaid
sequenceDiagram
participant T1 as Thread 1
participant P as Promise
participant T2 as Thread 2
T2->>P: success()
Note right of P: success_cbs read.
T1->>P: on_su...Callbacks may get lost due to a race condition.
```mermaid
sequenceDiagram
participant T1 as Thread 1
participant P as Promise
participant T2 as Thread 2
T2->>P: success()
Note right of P: success_cbs read.
T1->>P: on_success()
activate P
Note right of P: success_cbs updated.
P->>T1: returns
deactivate P
T2->>P: success() calls finalise()
activate P
Note right of P: Old success_cbs called.
Note right of P: success_cbs cleared.
P->>T2: returns
deactivate P
Note right of P: The callback installed by Thread 1 has been lost.
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10051Protocols.DNS.async_client does not like when the callback function has been ...2020-08-18T11:50:09ZHenrik (Grubba) GrubbströmProtocols.DNS.async_client does not like when the callback function has been destructed.Seen in the wild (Pike 8.0.354 patched to 5cf5f2a4b8ededbb0bc03f3eabc9bc97a71d61b9 (aka `rxnpatch/2020-03-25T110609`)):
```
Internal server error: Attempt to call the NULL-value
Unknown program: 0("foo.examle.com",0,0,80)
pike/lib/module...Seen in the wild (Pike 8.0.354 patched to 5cf5f2a4b8ededbb0bc03f3eabc9bc97a71d61b9 (aka `rxnpatch/2020-03-25T110609`)):
```
Internal server error: Attempt to call the NULL-value
Unknown program: 0("foo.examle.com",0,0,80)
pike/lib/modules/Protocols.pmod/DNS.pmod:2014: Protocols.DNS.global_async_client
->generic_get("foo.example.com",0,-1,0,1,"a","foo.example.com",0,0,80)
pike/lib/modules/Protocols.pmod/DNS.pmod:1909: Protocols.DNS.global_async_client
->remove(Protocols.DNS.global_async_client->Request())
base_server/roxenloader.pike (53ed4390):269: Protocols.DNS.global_async_client->
remove->`()(@0=Protocols.DNS.global_async_client->Request())
-:1: Pike.Backend(0)->`()(3600.0)
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10050Crypto.Password.verify() fails intermittently with EINVAL on RHEL 8.2020-08-14T09:38:59ZHenrik (Grubba) GrubbströmCrypto.Password.verify() fails intermittently with EINVAL on RHEL 8.Pike 8.0.1050
`Crypto.Password.verify()` (or rather `predef::crypt()`) fails intermittently with `EINVAL` (22) on RedHat Enterprise Linux 8:
```
Running test etc/test/tests/rxml/RoxenTest_RXMLTags.xml
Enabling Tags: HTML washer
########...Pike 8.0.1050
`Crypto.Password.verify()` (or rather `predef::crypt()`) fails intermittently with `EINVAL` (22) on RedHat Enterprise Linux 8:
```
Running test etc/test/tests/rxml/RoxenTest_RXMLTags.xml
Enabling Tags: HTML washer
################ Background failure
| ################ Error at line 393:
| <eval><maketag type='tag' name='set'><attrib name='variable'>var.i</attrib><attrib name='value'><crypt>foobar</crypt></attrib></maketag></eval><eval><maketag name='crypt' type='container'><attrib name='compare'>&var.i;</attrib>foobar</maketag></eval><then>1</then><else>0</else>
| [Pass 2 (p-code)] Failed (backtrace): Unsupported salt (22).
| RXML frame backtrace:
| | <crypt compare="$6$f+08ZlzC/fNPECMh$s5yICn952nJoDP.oejYEjHz5RyNsCl6L6L9QubTUVlWe4Zi50camGWSk4gtduWaNkYRbq5suLoYANr1DL.qac0">
| | <eval>
| pike/lib/modules/Crypto.pmod/Password.pmod:144: verify_password("foobar","$6$f+08ZlzC/fNPECMh$s5yICn952nJoDP.oejYEjHz5RyNsCl6L6L9QubTUVlWe4Zi50camGWSk4gtduWaNkYRbq5suLoYANr1DL.qac0")
| modules/tags/rxmltags.pike (417e8bbe):3022: Frame(crypt)->do_return(InternalRequestID(conf=Configuration(Test server 1); not_query="/index.html"))
| etc/modules/RXML.pmod/module.pmod (ef58bd29):4974: Frame(crypt)->_eval(Context(),RXML.PXml(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set)),RXML.t_html(text/html, xml))
| etc/modules/RXML.pmod/module.pmod (ef58bd29):485: TagCrypt(crypt)->_p_xml_handle_tag(@0=RXML.PXml(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set)),mapping[1],"foobar")
| pike/lib/modules/Parser.pmod/_parser.so:1: RXML.PXml(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set))->finish("<crypt compare=\"$6$f+08ZlzC/fNPECMh$s5yICn952nJoDP.oejYEjHz5RyNsCl6L6L9QubTUVlWe4Zi50camGWSk4gtduWaNkYRbq5suLoYANr1DL.qac0\">foobar</crypt>")
| etc/modules/RXML.pmod/PXml.pike (8ce553d4):396: RXML.PXml(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set))->finish("<crypt compare=\"$6$f+08ZlzC/fNPECMh$s5yICn952nJoDP.oejYEjHz5RyNsCl6L6L9QubTUVlWe4Zi50camGWSk4gtduWaNkYRbq5suLoYANr1DL.qac0\">foobar</crypt>")
| etc/modules/RXML.pmod/module.pmod (ef58bd29):3886: Frame(eval)->_exec_array(@1=Context(),RXML.PCode(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set)),,,1)
| etc/modules/RXML.pmod/module.pmod (ef58bd29):4978: Frame(eval)->_eval(@2=Context(),@3=RXML.PCode(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set)),@4=RXML.t_html(text/html, xml))
| etc/modules/RXML.pmod/module.pmod (ef58bd29):9393: RXML.PCode(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set))->_eval(@2,0)
| etc/modules/RXML.pmod/module.pmod (ef58bd29):8788: RXML.PCode(RXML.t_html(text/html, xml),RXMLTagSet(Test server 1,rxml_tag_set))->eval(@2,UNDEFINED)
| modules/configuration/roxen_test.pike (2563376c):392: RoxenModule(Test server 1/roxen_test#0)->__lambda_66927_7_line_359(Parser._parser.HTML(),([]),"<eval><maketag type='tag' name='set'><attrib name='variable'>var.i</attrib><attrib name='value'><crypt>foobar</crypt></attrib><"+[111]+"etag></eval><then>1</then><else>0</else>")
| pike/lib/modules/Parser.pmod/_parser.so:1: Parser._parser.HTML()->finish("\n<rxml><eval><maketag type='tag' name='set'><attrib name='variable'>var.i</attrib><attrib name='value'><crypt>foobar</crypt></attrib></maketag></e"+[120]+"then><else>0</else></rxml>\n<result>1</result>\n")
| modules/configuration/roxen_test.pike (2563376c):612: RoxenModule(Test server 1/roxen_test#0)->xml_test(Parser._parser.HTML(),([]),"\n<rxml><eval><maketag type='tag' name='set'><attrib name='variable'>var.i</attrib><attrib name='value'><crypt>foobar</"+[157]+"e>0</else></rxml>\n<result>1</result>\n",mapping[392])
| pike/lib/modules/Parser.pmod/_parser.so:1: Parser._parser.HTML()->finish("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<!--\n All <add-module> statements must precede the p-code tests since\n altering the configura"+[104329]+"le. -->\n\n<drop-module>html_wash</drop-module>\n")
| modules/configuration/roxen_test.pike (2563376c):739: RoxenModule(Test server 1/roxen_test#0)->run_xml_tests("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<!--\n All <add-module> statements must precede the p-code tests since\n altering the configura"+[104329]+"le. -->\n\n<drop-module>html_wash</drop-module>\n")
| modules/configuration/roxen_test.pike (2563376c):114: RoxenModule(Test server 1/roxen_test#0)->__lambda_66927_0_line_108(RoxenModule(Test server 1/roxen_test#0)->run_xml_tests,({"<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n\n<!--\n All <add-module> statements must precede the p-co"+[104385]+"-module>html_wash</drop-module>\n"}))
| base_server/roxen.pike (a66e1c68):774: roxen()->handler_thread(11)
|
Disabling Tags: HTML washer
Did 784 tests, failed on 1, skipped 0, detected 1 background failures.
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10020Search.Filter.HTML prefers the title from embedded SVG.2023-01-01T12:59:12ZHenrik (Grubba) GrubbströmSearch.Filter.HTML prefers the title from embedded SVG.[RT#33534](http://rt.roxen.com/rt3/Ticket/Display.html?id=33534)
The SVG tag has several sub tags. One is `<title>` which isn't correctly indexed, but instead interpreted as page title (if not overridden by other `<title>` tags).
Examp...[RT#33534](http://rt.roxen.com/rt3/Ticket/Display.html?id=33534)
The SVG tag has several sub tags. One is `<title>` which isn't correctly indexed, but instead interpreted as page title (if not overridden by other `<title>` tags).
Example:
```
<svg viewBox="0 0 20 10" xmlns="http://www.w3.org/2000/svg">
<circle cx="5" cy="5" r="4">
<title>I'm a circle</title>
</circle>
<rect x="11" y="1" width="8" height="8">
<title>I'm a square</title>
</rect>
</svg>
```
If set in a html page the search phrase _"circle"_ will not generate a hit, but _"square"_ will (the last `<title>` will be interpreted as the page title). In a CMS Page Editor page none of the `<title>` words will be indexed, since the page title is set elsewhere.
See also [CMS-698](https://youtrack.roxen.com/issue/CMS-698).Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10016Stdio.Buffer.RewindKey has LFUNs that are declared private.2020-03-09T18:56:40ZHenrik (Grubba) GrubbströmStdio.Buffer.RewindKey has LFUNs that are declared private.Having `create()` and `_destruct()` being private is not a good idea. Change them to protected.Having `create()` and `_destruct()` being private is not a good idea. Change them to protected.Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/8010Pike.identify_cycle doesn't handle declared-only __hash member2023-11-05T10:13:18ZPeter BortasPike.identify_cycle doesn't handle declared-only __hash memberImported from https://youtrack.roxen.com/issue/PIKE-10
Reported by Martin Karlgren <marty@roxen.com>
Pike.identify_cycle throws when a class has a declared, but not defined, __hash member. (Not sure if the problem really is in hash_sva...Imported from https://youtrack.roxen.com/issue/PIKE-10
Reported by Martin Karlgren <marty@roxen.com>
Pike.identify_cycle throws when a class has a declared, but not defined, __hash member. (Not sure if the problem really is in hash_svalue?)
```
> class Foo { mixed bar; int __hash(); }
> class Bar { mixed foo; }
> Foo foo = Foo();
> Bar bar = Bar();
> foo->bar = bar;
(1) Result: HilfeInput()->Bar()
> bar->foo = foo;
(2) Result: HilfeInput()->Foo()
> Pike.identify_cycle(foo);
Calling undefined function.
HilfeInput:1: HilfeInput()->Foo()->__hash()
-:1: __builtin.identify_cycle(HilfeInput()->Foo())
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10005The fdlib changes in Pike 8.0.606 broke support for sprshd on NT.2023-01-01T13:02:07ZHenrik (Grubba) GrubbströmThe fdlib changes in Pike 8.0.606 broke support for sprshd on NT.`sprshd` works as usual with Pike 8.0.604.
In Pike 8.0.606 and later it hangs when spawning the first external binary.`sprshd` works as usual with Pike 8.0.604.
In Pike 8.0.606 and later it hangs when spawning the first external binary.Pike 8.0