pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2024-02-17T17:35:37Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/3The image module is compiled with -fpic when it should be compiled with -fPIC...2024-02-17T17:35:37ZPeter BortasThe image module is compiled with -fpic when it should be compiled with -fPIC on Linux RH 6.2/sparc.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3
Reported by @grubba
```
From: Eric Doutreleau <Eric.Doutreleau@int-evry.fr>
Date: Fri, 7 Jul 2000 16:46:15 +0200 (CEST)
Subject: problems for compiling pikev7.0.36 on s...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3
Reported by @grubba
```
From: Eric Doutreleau <Eric.Doutreleau@int-evry.fr>
Date: Fri, 7 Jul 2000 16:46:15 +0200 (CEST)
Subject: problems for compiling pikev7.0.36 on sparc linux redhat 6.2
```
Hello
I'm trying to compile pike v7.0.36 on my sparc linux 6.2 and i got the
following message
```
make[3]: Leaving directory
`/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings'
linking Image
encodings/encodings.a(png.o): In function `img_png_decode':
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1380:
relocation
truncated to fit: R_SPARC_GOT13 LLC50
encodings/encodings.a(png.o): In function `image_png_encode':
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1432:
relocation
truncated to fit: R_SPARC_GOT13 LLC51
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1437:
relocation
truncated to fit: R_SPARC_GOT13 LLC52
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1440:
relocation
truncated to fit: R_SPARC_GOT13 LLC53
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1445:
relocation
truncated to fit: R_SPARC_GOT13 LLC54
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1454:
relocation
truncated to fit: R_SPARC_GOT13 LLC55
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1460:
relocation
truncated to fit: R_SPARC_GOT13 LLC56
[.....]
lots of similar messages
[...]
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/tim.c:339:
relocation
truncated to fit: R_SPARC_GOT13 LLC28
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/tim.c:339:
relocation
truncated to fit: R_SPARC_GOT13 image_tim_f_decode_header
collect2: ld returned 1 exit status
Linking failed:
/home/glopglop/Pike-v7.0.36/bin/smartlink
/home/glopglop/Pike-v7.0.36/src/smartlink gcc -shared -o module.so
image_module.o image.o font.o matrix.o blit.o pattern.o dct.o operator.o
colortable.o polyfill.o orient.o colors.o search.o layers.o default_font.o
poly.o encodings/encodings.a -R/usr/local/lib -L/usr/local/lib
-R/usr/X11R6/lib -L/usr/X11R6/lib
/usr/lib/gcc-lib/sparc-redhat-linux/egcs-2.91.66/libgcc.a -lc
/usr/lib/gcc-lib/sparc-redhat-linux/egcs-2.91.66/libgcc.a
cp: module.so: Aucun fichier ou répertoire de ce type
make[2]: *** [dummy] Error 1
make[2]: Leaving directory `/home/glopglop/Pike-v7.0.36/src/modules/Image'
make[1]: *** [Image] Error 1
make[1]: Leaving directory `/home/glopglop/Pike-v7.0.36/src/modules'
make: *** [module_objects] Error 1
```
The compiler i use is egcs 1.1.2
Has someone succeed in compiling this version of pike in a sparc
platform with redhat 6.2
Thanks in advance
--
Eric Doutreleau
I.N.T | Tel : +33 (0) 160764687
9 rue Charles Fourier | Fax : +33 (0) 160764321
91011 Evry France | email : Eric.Doutreleau@int-evry.frPike 7.0https://git.lysator.liu.se/pikelang/pike/-/issues/10137SHA256/SHA512 crypt_hash bug2024-01-26T13:03:11ZHenrik (Grubba) GrubbströmSHA256/SHA512 crypt_hash bugFrom the Pike developers mailinglist/LysLysKOM 26091551:
```
26091551 2023-11-23 13:38 /146 rader/ Ricard Garra Oronich <rgarra@lleida.net>
Sänt av: SRS0=5fN1=HE=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-11-...From the Pike developers mailinglist/LysLysKOM 26091551:
```
26091551 2023-11-23 13:38 /146 rader/ Ricard Garra Oronich <rgarra@lleida.net>
Sänt av: SRS0=5fN1=HE=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-11-23 13:38 av Brevbäraren
Extern mottagare: pike-devel@lists.lysator.liu.se <pike-devel@lists.lysator.liu.se>
Mottagare: Pike (-) developers forum <21443>
Ärende: SHA256/SHA512 crypt_hash bug
------------------------------------------------------------
```
Hello,
I have been looking into using the `SHA256`/`SHA512` `crypt_hash` functions, and during my testing, comparing the results with other implementations (Python's passlib, Openssl, MySQL and C), I found that for some passwords used, the resulting hash is different that the ones generated by other languages/implementations, and therefore would fail if a hash of these passwords done with Pike was then computed/verified with another system.
I don't know the reason of this, but it seems to fail with some passwords, regardless of the salt or number of rounds, and both `SHA256` and `SHA512` "fail", while for some other passwords it works well. A couple of values that fail are simply "pass" and "password".
Below I attach some examples, using the mentioned failing passwords, first in Pike, and then comparing the computation of the same hash, using the same password/salt/rounds in other implementations, and you can see that all the rest are the same among them, but different from Pike. This fails also using `Crypto.Password.hash()`, and letting it compute a random salt. I also tested the reference base C implementation cited in your documentation (https://akkadia.org/drepper/SHA-crypt.txt), and it gives the same result as the others (and thus, different than Pike's).
In addition, I also found that in some cases, the random salt contains the character `"+"`, which the Python library I tested doesn't 'allow' it seems, this is probably not a bug itself, but could be taken into account for future implementations when generating a salt, I attach here their explanation:
From Python's passlib docs: "Restricted salt string character set:
"The underlying algorithm can unambiguously handle salt strings which contain any possible byte value besides `\x00` and `$`. However, Passlib strictly limits salts to the `hash64` character set, as nearly all implementations of sha256-crypt generate and expect salts containing those characters, but may have unexpected behaviors for other character values."
The `hash64` character set is:
```
HASH64_CHARS = u("./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz")
```
I would like to know if this is really a bug, and if it is, if you would be able to maybe fix it in some revision, if that's the case, I would be interested in using the updated/corrected code ASAP, implementing it in a module of my own perhaps.
Code examples:
```
Pike v8.0 release 1116 running Hilfe v3.5 (Incremental Pike Frontend):
> Crypto.SHA512.crypt_hash("pass","salt",10000);
(1) Result: "gJkLS5cThyks4JXgQ8x3UNvwYLNW22AHZdM70xoRvEma//RJfeBOC/Ik0EddD7DLI9Sau9pYCV29OLzxxVFph1"
> Crypto.Password.hash("pass","6",10000);
(2) Result: "$6$rounds=10000$UrtM9r9XUEqEp1H3$X.OaL5Jp8PNtjkgKPUdGv7hxFg.jjF0U0dqLnscH3F45socUKOP6jWK2hDtvZAj2f1/I1u7Sgc3n3U7MMJDIi1"
> Crypto.SHA512.crypt_hash("password","salt",10000);
(3) Result: "aaSSVStpZx9F9OYvj2130N4GR9uJcP/A10FvDYjBQWbs2RAYN.9iCJb9GvREy9Huz7H6Bp6u5SlHEEcrxaDPi0"
> Crypto.Password.hash("password","6",10000);
(4) Result: "$6$rounds=10000$CfcWNrK0SB8eROnk$a/agNPy2AKOVf4qNTHRXw16nUSjHeINZCTxgw5PjLlRBFnxJ6DDI/rebM3I8LD8pubgOji7ps70JddbFUWo190"
> Crypto.SHA256.crypt_hash("pass","salt",10000);
(5) Result: "s2.jgIPueybkP3hvZqjt3ql5emK9LDBUGvrNc8Cfq3B"
> Crypto.Password.hash("pass","5",10000);
(6) Result: "$5$rounds=10000$Pjj07C7RqLD+ydig$Heqa8mVcO6ttpcXxxtmYoRF6kuPDbieJgy8YPkNNpl."
> Crypto.Password.hash("pass","5",10000);
(7) Result: "$5$rounds=10000$PKoyOiOCTDQTwjBS$jgKXglMIaloY8JPEz/Zp14q1S6qrG2DShYeEUuO4YC4"
```
-----------------
Python:
```
>>> from passlib.hash import sha512_crypt
>>> sha512_crypt.hash("pass", salt="salt",rounds=10000)
'$6$rounds=10000$salt$OSEwMhCIwtjyui53YYIYdyKYKKMcnmS2EbioMYM3/7ya4jWlyYim8VJvMW4cVEgVkO.a.YBgUKiMtpAGUQSXf.'
>>> sha512_crypt.hash("pass", salt="UrtM9r9XUEqEp1H3",rounds=10000)
'$6$rounds=10000$UrtM9r9XUEqEp1H3$IazyuGXF.YEWCnYtarD5BGYduUW2zzydYZXN3xa5QfHx5wvE.lQyU2rPnqMSiSLMvXR0En2Suo/2805nGp1FU.'
>>> sha512_crypt.hash("password", salt="salt",rounds=10000)
'$6$rounds=10000$salt$dE5fLfpn2uXfkz.eouwYK/BjrHRu.piovQPjwlE06fDJHwMlg2l.IqEBUIfWBzf7YPXOAddB3FM7rnXHHKVNt.'
>>> sha512_crypt.hash("password", salt="CfcWNrK0SB8eROnk",rounds=10000)
'$6$rounds=10000$CfcWNrK0SB8eROnk$wuB7fFzyIokmn5WLk2theKXOpBbIkuyRqtUNTtwPWdEI7eKi.dnvcPtrM337BUXvgUXwrBPYWjKFl.r0i39Yz0'
>>> pike_hash = "$6$rounds=10000$UrtM9r9XUEqEp1H3$X.OaL5Jp8PNtjkgKPUdGv7hxFg.jjF0U0dqLnscH3F45socUKOP6jWK2hDtvZAj2f1/I1u7Sgc3n3U7MMJDIi1"
>>> sha512_crypt.verify("pass",pike_hash)
False
>>> pike_hash2="$6$rounds=10000$CfcWNrK0SB8eROnk$a/agNPy2AKOVf4qNTHRXw16nUSjHeINZCTxgw5PjLlRBFnxJ6DDI/rebM3I8LD8pubgOji7ps70JddbFUWo190"
>>> sha512_crypt.verify("password",pike_hash2)
False
>>> sha256_crypt.hash("pass", salt="salt",rounds=10000)
'$5$rounds=10000$salt$Lffn09CeAx2gukDdao1thbgNhgpn41BG4JJNh0Nk6C/'
>>> pike_hash3 = '$5$rounds=10000$Pjj07C7RqLD+ydig$Heqa8mVcO6ttpcXxxtmYoRF6kuPDbieJgy8YPkNNpl.'
>>> sha256_crypt.verify("pass",pike_hash3)
Traceback (most recent call last):
(...)
raise ValueError("invalid characters in %s salt" % cls.name)
ValueError: invalid characters in sha256_crypt salt
>>> sha256_crypt.hash("pass", salt="Pjj07C7RqLD+ydig",rounds=10000)
Traceback (most recent call last):
(...)
raise ValueError("invalid characters in %s salt" % cls.name)
ValueError: invalid characters in sha256_crypt salt
>>> pike_hash4 = "$5$rounds=10000$PKoyOiOCTDQTwjBS$jgKXglMIaloY8JPEz/Zp14q1S6qrG2DShYeEUuO4YC4"
>>> sha256_crypt.verify("pass",pike_hash4)
False
```
------------------
Openssl:
```
$ openssl passwd -6 -salt 'rounds=10000$salt' 'pass'
$6$rounds=10000$salt$OSEwMhCIwtjyui53YYIYdyKYKKMcnmS2EbioMYM3/7ya4jWlyYim8VJvMW4cVEgVkO.a.YBgUKiMtpAGUQSXf.
$ openssl passwd -6 -salt 'rounds=10000$salt' 'password'
$6$rounds=10000$salt$dE5fLfpn2uXfkz.eouwYK/BjrHRu.piovQPjwlE06fDJHwMlg2l.IqEBUIfWBzf7YPXOAddB3FM7rnXHHKVNt.
$ openssl passwd -5 -salt 'rounds=10000$salt' 'pass'
$5$rounds=10000$salt$Lffn09CeAx2gukDdao1thbgNhgpn41BG4JJNh0Nk6C/
$ openssl passwd -5 -salt 'rounds=10000$Pjj07C7RqLD+ydig' 'pass'
$5$rounds=10000$Pjj07C7RqLD+ydig$56R7PRLYPMhN07ZhnoGFCKkNK5.N0ZDY0hViH4yG19/
```
-----------------
MySQL:
```
SELECT ENCRYPT('pass', '$6$rounds=10000$salt');
$6$rounds=10000$salt$OSEwMhCIwtjyui53YYIYdyKYKKMcnmS2EbioMYM3/7ya4jWlyYim8VJvMW4cVEgVkO.a.YBgUKiMtpAGUQSXf.
SELECT ENCRYPT('password', '$6$rounds=10000$salt');
$6$rounds=10000$salt$dE5fLfpn2uXfkz.eouwYK/BjrHRu.piovQPjwlE06fDJHwMlg2l.IqEBUIfWBzf7YPXOAddB3FM7rnXHHKVNt.
SELECT ENCRYPT('pass', '$5$rounds=10000$salt');
$5$rounds=10000$salt$Lffn09CeAx2gukDdao1thbgNhgpn41BG4JJNh0Nk6C/
SELECT ENCRYPT('pass', '$5$rounds=10000$Pjj07C7RqLD+ydig');
$5$rounds=10000$Pjj07C7RqLD+ydig$56R7PRLYPMhN07ZhnoGFCKkNK5.N0ZDY0hViH4yG19/
```
-----------------
I await your response, thank you for your time.
Yours truthfully,
Ricard Garra Oronich
Desarollador de Núcleo | Core Developer
rgarra@lleida.net
(+34) 680 423 701
[http://www.lleida.net/mailing/fires/signatura.png]
Parc Científic i Tecnològic Agroalimentari de Lleida
Edifici H1 2a planta B | 25003 Lleida (Spain)
Tel. (+34) 973 282 300
Fax (+34) 973 282 195
www.lleida.net<http://www.lleida.net>
Política de privacidad<http://www.lleida.net/es/privacy.html>
```
(26091551) /Ricard Garra Oronich <rgarra@lleida.net>/
```Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10134Crypto.DSA et al verify messages with various incorrect signatures.2024-01-26T13:03:11ZJoshua RogersCrypto.DSA et al verify messages with various incorrect signatures.Hi there,
I've started to take a look at the latest master branch of Pike and [updated my script](https://github.com/operasoftware/nettle-wycheproof-testsuite) to support the newer version of Pike. A few new issues have been found.
`Cr...Hi there,
I've started to take a look at the latest master branch of Pike and [updated my script](https://github.com/operasoftware/nettle-wycheproof-testsuite) to support the newer version of Pike. A few new issues have been found.
`Crypto.DSA.State->pkcs_verify` successfully verifies a msg,sig pair with `Crypto.SHA256` and `Crypto.SHA224` which:
1. use long form encoding for the length of `r` and/or `s`.,
2. uses a length of sequence `r` and/or `s` contains a leading `0`.
Here, we see two different string representation of the signature verify as the same (both should be rejected):
```pike
int main() {
mapping(string:string) key = ([
"g" : "16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde",
"keySize" : 2048,
"p" : "008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667",
"q" : "00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d",
"type" : "DsaPublicKey",
"y" : "1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931"
]);
string msg;
string sig;
string siq;
msg = "313233343030";
sig = "30813d021d00a545d62d6e336775fb6a9b8495721646a54bd8c6173fc0a2295a1b7b021c3be6bae0e8763818840a9151ad8ed2b3b348e4a2c488d3fbdbbca844"; //use long form encoding for the length of [r, s],
siq = "3082003d021d00a545d62d6e336775fb6a9b8495721646a54bd8c6173fc0a2295a1b7b021c3be6bae0e8763818840a9151ad8ed2b3b348e4a2c488d3fbdbbca844"; //length of sequence [r, s] contains a leading 0
msg = String.hex2string(msg);
sig = String.hex2string(sig);
mixed state = Crypto.DSA.State();
state->set_public_key(Gmp.mpz(key["p"], 16), Gmp.mpz(key["q"], 16), Gmp.mpz(key["g"], 16), Gmp.mpz(key["y"], 16));
bool res = state->pkcs_verify(msg, Crypto.SHA256, sig);
if(res)
write("success!\n");
sig = String.hex2string(siq);
res = state->pkcs_verify(msg, Crypto.SHA256, sig);
if(res)
write("success!\n");
return 0;
}
```
This seems similar to https://git.lysator.liu.se/pikelang/pike/-/issues/10077, and I'm not sure why I didn't pick it up ealier.
Cheers,
JoshPike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10139RSA PKCS1 v1.5 decryption implementation does not detect ciphertext modificat...2024-01-26T13:03:11ZJoshua RogersRSA PKCS1 v1.5 decryption implementation does not detect ciphertext modification by prepending \0-bytes to ciphertextsHi there,
Another issue in RSA PKCS1 v1.5. Pike does not bork on ciphertexts that have been modified with prepended 0-bytes in their ciphertext.
A small test-case:
```
int main() {
string key = "30820943020100300d06092a864886f70d010...Hi there,
Another issue in RSA PKCS1 v1.5. Pike does not bork on ciphertexts that have been modified with prepended 0-bytes in their ciphertext.
A small test-case:
```
int main() {
string key = "30820943020100300d06092a864886f70d01010105000482092d308209290201000282020100f601be0dccd04aa40b12f3f191ae17c1f9c8c0b68e7a77e14be25c3c7907cb1d33a6ef418ef41852f32c98392bc5c9aed91c1a1501c503eab89b3ee6f4f8eb2e0fcfc41bd03609cf6a8eb3aa6f0fbe23187b33db4d34b66d128a8aba0a2abf40bb9d13d8e2554569a57ab1d8c61b8cad2dc88599ae0da5346e15dace1bac7bf69737c22f083be9b46bb8b1eab5957b2da740275e96c87195b96fe11452159dafcfd916cee5d749a77bc3905a5ebd387ae445e8fe70f16e9a086639779ceffbfd41557bd99aea6a371a6b4b160615a1a12bc6958d34bce0c85adcbd8392fa10ceca52209d56196ba3d273ce228f1f111192aa92de2a039798a17bcecb4dc6100e6f8ae8c2643f2ae768b2255f082c978e95ca551555f10608231cf8003bbf807969fff1e51914b9a8c9b8f4564645b9e5d705ffad29663f5dae3d76652b422e43f13e6c1491090805c2d1268a74a251177427e33a9a91175c3670b91746008bce1fd231e6e4f2ad70cb43aca5f07600a6d31dd02915243dfdd943a02165da367a6b7e4dae1dd2e8b836903080795d2585076cc1c15dd9e8d2e5e047526569b1bfd395d957eb9fde325d342d14426e71efdc1887515e53cdea5834921f928629e748eed097ac4024e2bf255d70411f87373948cf8e8aa7effa2b0ab47d5166091e1aedec60568b155bd9c27bc55f3ece35f83d636dbcd5abf4853a051db94d5045020301000102820200065028224431ca35e87f82d97302c9384b4d341385ecd8510f4df94e51facf0dbfa01694139e3f00e34859db09bd087e74b2e1c1229652e73df7e49c2fb2dd9cda7f5b49d81a32e9403e4b97b6eeebfdb6e89e7d8fbf27b95282fca9668e649c68297bf367bcdc21a86dfc22132a177e4591024b5dd49ad091775271fc9d7cb6e8cd8a5858f93f4cf280bf0c1b69d675e6f760ab443fa8ee8ddf89a2a85d46a52c367c27db6d1ec6435e52eb86c7e0ab02b05543865423cc4f25346f55e1db6675e69832e43a04ccc78af3abd68477ed37698ab7f61facbdbcdb32552de5e89d8342aa9f445b8afac81bfc5bc05981ea20b340e948f710f7b3ee85f18b5c3c5832f2336706c5e9c9bd8e43d202e73a0f62776df4b715975eddd31aa643b14145057b4995556de614c57b33297bda0e05a8b8882a29563bf21686ce34c3960f905de73911987eb696e07eac0a63857e2894c3b4629477ecbf1fc76eafbb2ce4a0f00f8cdb6fbd6169e399151460522cf5b365d9bbb9587d07dac8c438982adea9ff243a86bbdf128eaa0d3a88871d8cdf081854258a651ff4226ee9749b4a6add090c159ccea06b9a10804e5fe15120cc63a5972eab0e43980dedaff321fadeea3ca60c3ba1c2980bb597ea783b80ab6eba87feb5754fd1d65d7cad6f81cf52c1a6bfebf9a75e9a316cb364d8cf467d96370871df2ee66ee1c1694a02239583910282010100fc21b855c5ad4ca2b6970516406f71c6e79efc4126e6598772db1e082de6b0dddaaa2a2951f04148e86e0bde28213b7f600f987308301eacea134062bb0c3ddf628da9abf93ef1ce3e75b0953a484dbd3554bd5c0649933dd77e527563e90f05a8013fddac958c329378e94303b304be5f9df1fe5b043a7fdd94700a3f0b1cbbd0516b7cd94c57ca96d9fd2a8ca973991218cba33a1c23d810f7519d1f7702ab72affdb3f84a1b2a88116e4033bc4d0cfc7989c657e0fe94e964476ae58bae6b7876f36c09d32b1a63f8c47c94a74c92eedf75fc27cffe0f8452363e4bc8f7653f3cb55eaf693cec70d13c875de935a8b20439ab7e93f76981c5957fc5bb44d90282010100f9c7f748a505d23ecef9a85f8097c8cf7d7028ef6c90e22a336511582d2cc3636e34ead37204dbd22f142a3fb1d5f857b0310c7a433f51ae14d4608b01b43aa8c7ae67835f7fbe0b9d97948b39e9ba2d3a1687edb8b56ee70ff0536dab4d0551f71ed0daee9e412449f5f099bcc15e4ef0554dc79f87fec5a0dea717c7054392bf444613937401bbef3c22fbf7e738c58779b981609a1f9c11dd6f0bbe9996e2773459e4cef247b02a9fc21296ac57a5b10561824310cfbdecc90e06598370e3698713fdbe2528ec4ef3dccaae701eedc3e54ad6e7af4e68e3b39bd2e97ac9119936c647a503511cb283df984cfd7c07f0f56aa8ae3166948ef3f41b0859934d0282010100815486aab0a0896bf97f13e3eb1f7f5c49195b49cc3b6277412a3688798b18f46422df479cb941b3b54e25964a3d69b897bcc8355160e58b4af29f1745dd2cabb670f634b9c058e6b3514947f2c27de5ed424f73b1e1f1be4a188911a0333f3a6688658b3ee8e3265a512e4deacadc470ee304ebb5224123afb461984fe8524fe0b6b30d32a59f6ed2dc74a96bc7cbfd1bb44e58a7092235c5d6272e12a2c862cb8c8cf5d109aa4fb1c6472875a14460c1ed5207c4b22bc494c7947eb7ca63a8cafd31361d000ddf16a2d79f13dd9140d979149b488cbf44945a5b6aaf13221bf4491ebbb7fca27ca20e221f49c3c37b89fcf2dc0e2cb63f8f8a9b7a142250590282010100b61d84ff934a4e437b16ee1b4b9fdf4ae13370b5385bde7a5464a123c0343df575f9e128ef9df944230d39cc9cf5dc0edb28b7e740b69ef024c1bfee39fcd5340ffaea0010160c535dc0920e7cd81be533d00fa554a1fc4d3e02c461569f5e7ca787f1515edf45b196b759884de652c38d5934cf92524e807b4d3b590bc39bc417ee4885a761d28ddadce6c8fdb3b961d3e7fd48064df9340a967f8b79997438841f48579a476ddb55088c308f68f2b29d01c6597a5a7c8d066284f63e37a68c3879c32aa3836675fd0eb2719883a91944561e9dd7e8aa6bb17157f08c48f8e6fae5c3e5a2bb6b5d580eec6c97ddcd9be0a49ef283a7031ad7aba8d438df4e950282010022fb8e5fcd9b767104e71244db53058c18061e1b0d1f63b73e2d59a95e2a10cd87426a33da13c287cdef8136e5e47e93fb9b30ad92628a7b543f48eb011a86356ab3cb480f27e391b018ca187d97af3d82e31861ecafa663db78aa89c3bd468e6aadefb3a43f78bc00b8014c95db54e9d21a017e8f21f671545edde9a965ea32dfff45cda37fca1aa5132f6c8eed222bd01fed5a6e7d639580c5955777a86544c2c4c939bdb8b4c486dda53072861a0334359bdb3758475e49d90d0539944e78cfcfd8fff55bb31a1cebc65b28f51e790701b2f7912188984f034e6e96e1c5251e33fe38fb221bce7a90a86857c5f56b6ca77307c45d5290b1f088ade082b349";
string privateKeyPkcs8 = String.hex2string(key);
mixed state = Standards.PKCS.parse_private_key(privateKeyPkcs8);
string ret;
string ct = String.hex2string("e4b9d12b1519d15af3a10fef8ed37f918e998c56b7d89fad34cecd08ecb9ae9b3213f1e9686be7ea525882a5f28a594963b4c16ed9207210646d0d5cac26920f92edd61b262a39f0f9a9f889da6f583c6fce47a08b0fd575b4bbd33e64da0eb390703e341ae3c4392b39360a1a623b8701ad51801e63df43237df4e816f2a1e4312099f1070c528fc10803879321e99e76104b2440cb4ca788c2eeda15a673e418ff247f8556a2c5be47bc016fc6a2a6caf4080d6004f4d8d17dae33e23c8bb4046fd91ea85560f9d68949da790ea662e32c3c44538d4a8bd555338ddbf4009a9d8b2cb42337ab138b6841c0f1d34f585ecb9c8be41a037fd79c3db489909da1328a170a4d676d62359166ba641d4ab0e6d56f26903e41dd4307742d6e76c67b88ac2f835a9d5b45de31a5e4b479e76b82b08c184a67f2b917c2f76ba8ebfe98b0071eee383de77cb5b06050eb058a5194eb8170b000b47862bf40c1baacb0e4c58210284556aee1ba1006f25618bece2e9578fb73fd389914db94343b41c407c7778e49b3aa3062c92c63e83d79aac7c7f3d1334f197b8660432f29504c6f1477f9d00a3cf56b6bba97ffbcbb5c68cd60972982bdc910419ec69bcc1cde7cdb1516706e7a51fb23da821754fc2385ccbc85ced7c7a32b9a0fd7fa71b9829a86247d1a0942546b25109079a7be7b2bff81803cd96102cdeead406b2446077b6e00");
array err = catch { ret = state->decrypt(ct); };
if(ret)
write("%s\n", ret);
}
```
This issue is similar to CVE 2020-14967, which also allowed for the prepending of \0-bytes to the ciphertext (which resulted in a buffer overflow due to difference in the expected and real length of the ct).
Cheers,
JoshPike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10135Preprocessor hides doubles variable assignment in macro on Debian2023-11-17T10:15:21ZJoshua RogersPreprocessor hides doubles variable assignment in macro on DebianHi there,
I've encountered a strange bug where a newer version of Pike (commit 7303bc4ccce6ac86e2fc7ca53a71365edaa61475) is swallowing up some variable assignments. Specifically, when two variable assignments are used in combination wit...Hi there,
I've encountered a strange bug where a newer version of Pike (commit 7303bc4ccce6ac86e2fc7ca53a71365edaa61475) is swallowing up some variable assignments. Specifically, when two variable assignments are used in combination with a macro.
I have the following code:
```pike
#define ERR_CONT(TYPE,CARR,FMT,ARGS ...) write(FMT, ARGS); write("\n");
int main() {
ERR_CONT(1, 1, "%s", "one");
ERR_CONT(1, 1, "%s %s", "one", "two");
ERR_CONT(1, 1, "%s %s %s", "one", "two", "three");
ERR_CONT(1, 1, "%s %d", "one", 2);
ERR_CONT(1, 1, "%s %d %d", "one", 2, 3);
ERR_CONT(1, 1, "%s %d %s", "one", 2, "three");
}
```
which when preprocessed using Pike v8.0 release 1116 on Debian 11, provides the expected result:
```pike
$ pike -E test2.pike
#line 1 "test2.pike"
int main() {
write( "%s" , "one" ); write("\n");;
write( "%s %s" , "one", "two" ); write("\n");;
write( "%s %s %s" , "one", "two", "three" ); write("\n");;
write( "%s %d" , "one", 2 ); write("\n");;
write( "%s %d %d" , "one", 2, 3 ); write("\n");;
write( "%s %d %s" , "one", 2, "three" ); write("\n");;
}
```
However, using the version compiled from 7303bc4ccce6ac86e2fc7ca53a71365edaa61475, the assignments with two variables do not compile as intended:
```pike
$ ~/pike/build/linux-5.10.0-26-amd64-x86_64/pike -E test2.pike
#line 1 "test2.pike"
int main() {
write( "%s" , "one" ); write("\n");;
write( "%s %s" , ); write("\n");;
write( "%s %s %s" , "one","two","three" ); write("\n");;
write( "%s %d" , ); write("\n");;
write( "%s %d %d" , "one",2,3 ); write("\n");;
write( "%s %d %s" , "one",2,"three" ); write("\n");;
}
```
As we can see, ` write( "%s %s" , ); write("\n");;` and ` write( "%s %d" , ); write("\n");;` are completely missing their variables.
Unfortunately I have no clue as to why.
I also went back to commit 43680aa756ae3f5bfd60843785ff6f076eeb4ee8 and compiled from there, and same issue occurs.
Cheers,
JoshPike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10136Private getter not marked as used.2023-11-16T12:02:24ZHenrik (Grubba) GrubbströmPrivate getter not marked as used.Reported by Pontus Östlund:
```
$ cat bug-private-getter.pike
class Test {
private string `property_accessor() {
return "I'm private";
}
private string `unused_getter() {
return "Unused private getter";
}
public void...Reported by Pontus Östlund:
```
$ cat bug-private-getter.pike
class Test {
private string `property_accessor() {
return "I'm private";
}
private string `unused_getter() {
return "Unused private getter";
}
public void log() {
werror("Log: %s\n", property_accessor);
}
}
int main() {
Test t = Test();
t->log();
}
```
In current Pike 8.0:
```
$ ./pike bug-private-getter.pike
bug-private-getter.pike:2: Warning: Modifier mismatch for variable property_accessor.
bug-private-getter.pike:6: Warning: Modifier mismatch for variable unused_getter.
bug-private-getter.pike:13: Warning: `property_accessor is private but not used anywhere.
bug-private-getter.pike:13: Warning: unused_getter is private but not used anywhere.
bug-private-getter.pike:13: Warning: `unused_getter is private but not used anywhere.
Log: I'm private
```
In current Pike master:
```
$ ./pike bug-private-getter.pike
bug-private-getter.pike:13: Warning: `property_accessor is private but not used anywhere.
bug-private-getter.pike:13: Warning: unused_getter is private but not used anywhere.
bug-private-getter.pike:13: Warning: `unused_getter is private but not used anywhere.
Log: I'm private
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10077Crypto.DSA verifies signature with modified R/S values2023-11-06T12:25:25ZJoshua RogersCrypto.DSA verifies signature with modified R/S valuesHi,
While conducting some tests based on [Wycheproof](https://github.com/google/wycheproof), Crypto.DSA fails one (out of ~70) test for "Modified r or s, e.g. by adding or subtracting the group order".
The following test should fail, b...Hi,
While conducting some tests based on [Wycheproof](https://github.com/google/wycheproof), Crypto.DSA fails one (out of ~70) test for "Modified r or s, e.g. by adding or subtracting the group order".
The following test should fail, but is verified as a legitimate signature:
```
int main() {
mapping(string:string) key = ([
"g" : "16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde",
"p" : "008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667",
"q" : "00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d",
"y" : "1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931",
]);
string msg = String.hex2string("313233343030");
string sig = String.hex2string("303e021d00a545d62d6e336775fb6a9b8495721646a54bd8c6173fc0a2295a1b7b021d00c178f07615a75535ca0ee2274e824a59fef7f79ef575a73a1e040e05");
mixed state = Crypto.DSA.State();
state->set_public_key(Gmp.mpz(key["p"], 16), Gmp.mpz(key["q"], 16), Gmp.mpz(key["g"], 16), Gmp.mpz(key["y"], 16));
bool res = state->pkcs_verify(msg, Crypto.SHA224, sig);
if(res)
write("success!\n");
return 0;
}
```
Unfortunately I cannot offer more support on this, but if you have any questions, please let me know.
Cheers,
Joshhttps://git.lysator.liu.se/pikelang/pike/-/issues/1694Parse errors when using typedef2023-11-05T11:25:28ZPeter BortasParse errors when using typedefImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1694
Reported by Jonas Wallden <jonasw@roxen.com>
The following program generates a "parse error" on line 3. Using the
commented declaration works fine, though.
```
ty...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1694
Reported by Jonas Wallden <jonasw@roxen.com>
The following program generates a "parse error" on line 3. Using the
commented declaration works fine, though.
```
typedef string MyString;
constant str = (MyString) 4711;
//constant str = (string) 4711;
int main()
{
werror("str: %O\n", str);
return 0;
}
```
Same thing happens with variables instead of constants, by the way.Pike 9.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/10037Dumping failure of 7.8::SSL.session2023-11-05T09:31:19ZMarcus ComstedtDumping failure of 7.8::SSL.sessionI noticed this dumping failure in the pikefarm builds of bahamut, but it can be reproduced on any system. Presumably the dump works if 8.0::Crypto has been dumped first, since most pikefarm systems do not hit the issue...
``` shell
hak...I noticed this dumping failure in the pikefarm builds of bahamut, but it can be reproduced on any system. Presumably the dump works if 8.0::Crypto has been dumped first, since most pikefarm systems do not hit the issue...
``` shell
hakua:~/Pike/8.1/build/linux-5.4.41-ppc64% /home/marcus/Pike/8.1/build/linux-5.4.41-ppc64/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/marcus/Pike/8.1/build/linux-5.4.41-ppc64/master.pike -x dump -t /tmp/dumptest ../../lib/7.8/modules/SSL.pmod/session.pike
#### ../../lib/7.8/modules/SSL.pmod/session.pike:
Cannot find 8.0::Crypto.CompatProxy() in 8.0::Crypto.
master.pike:5697:
master()->Encoder()->find_index(8.0::Crypto,8.0::Crypto.CompatProxy(),({0}),UNDEFINED)
master.pike:5924:
master()->Encoder()->nameof(@0=8.0::Crypto.CompatProxy(),@1=({0}))
master.pike:5916:
master()->Encoder()->nameof(8.0::Crypto.CompatProxy()->Buffer,({0}))
master.pike:5965:
master()->Encoder()->nameof(8.0::Crypto.CompatProxy()->Buffer->State,UNDEFINED)
/home/marcus/Pike/8.1/lib/modules/Tools.pmod/Standalone.pmod/dump.pike:221:
Tools.Standalone.dump()->dumpit("../../lib/7.8/modules/SSL.pmod/session.pike","/tmp/dumptest/session.pike")
/home/marcus/Pike/8.1/lib/modules/Tools.pmod/Standalone.pmod/dump.pike:355:
Tools.Standalone.dump()->dump_files()
-:1: Pike.Backend(0)->`()(3600.0)
hakua:~/Pike/8.1/build/linux-5.4.41-ppc64%
```
The failure in nameof() can be reproduced separately, although I'm not sure if this is supposed to work or not (CompatProxy is protected in 8.0::Crypto):
```
Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
> 8.0::Crypto.Buffer;
(1) Result: 8.0::Crypto.CompatProxy()->Buffer->State
> master()->nameof(8.0::Crypto.Buffer);
Cannot find 8.0::Crypto.CompatProxy() in 8.0::Crypto.
master.pike:5697:
master()->find_index(8.0::Crypto,8.0::Crypto.CompatProxy(),({0}),UNDEFINED)
master.pike:5924: master()->nameof(@0=8.0::Crypto.CompatProxy(),@1=({0}))
master.pike:5916: master()->nameof(8.0::Crypto.CompatProxy()->Buffer,({0}))
master.pike:5965:
master()->nameof(8.0::Crypto.CompatProxy()->Buffer->State,UNDEFINED)
>
```Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://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/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/10131Fix for #10130 is not sufficient in Pike master.2023-11-01T08:21:13ZHenrik (Grubba) GrubbströmFix for #10130 is not sufficient in Pike master.The testsuite test for #10130 crashes Pike master.
```
test_any([[
Stdio.write_file("testsuite_test.pmod",
#"
// Bug 10130.
// This crashed pike due to broken error recovery.
class Bang(pang) {
void bang() {}
}
");
// Compilation h...The testsuite test for #10130 crashes Pike master.
```
test_any([[
Stdio.write_file("testsuite_test.pmod",
#"
// Bug 10130.
// This crashed pike due to broken error recovery.
class Bang(pang) {
void bang() {}
}
");
// Compilation handler that hides compilation errors.
class handler
{
void compile_error(string file, int line, string err)
{
// log_msg("file: %O, line: %O, err: %O\n", file, line, err);
}
};
catch {
compile_string(".testsuite_test.Bang bang;\n", "testsuite_test", handler());
};
return 0;
]],0);
```Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10132Fix stack alignment issue with getxattr()2023-11-01T08:21:13ZHenrik (Grubba) GrubbströmFix stack alignment issue with getxattr()Apply [GitHub pull-request #42](https://github.com/pikelang/Pike/pull/42) for `src/modules/_Stdio/efuns.c`.
The issue applies to Pike 7.8 and later.Apply [GitHub pull-request #42](https://github.com/pikelang/Pike/pull/42) for `src/modules/_Stdio/efuns.c`.
The issue applies to Pike 7.8 and later.Pike 7.8https://git.lysator.liu.se/pikelang/pike/-/issues/10133__ARGS__ broken in recent Pike master2023-10-31T09:34:40ZHenrik (Grubba) Grubbström__ARGS__ broken in recent Pike masterPike developers mailinglist/LysLysKOM 26044077:
```
26047339 2023-10-30 00:48 /21 rader/ Chris Angelico <rosuav@gmail.com>
Sänt av: SRS0=Zs/b=GL=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-10-30 00:48 av Brevb...Pike developers mailinglist/LysLysKOM 26044077:
```
26047339 2023-10-30 00:48 /21 rader/ Chris Angelico <rosuav@gmail.com>
Sänt av: SRS0=Zs/b=GL=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-10-30 00:48 av Brevbäraren
Extern mottagare: Pike Developers <pike-devel@lists.lysator.liu.se>
Mottagare: Pike (-) developers forum <21435>
Ärende: Pike 9.0 quirk with implicit lambda
```
------------------------------------------------------------
```
void call(function cb) {cb(42);}
int main() {
werror("Pike version %O:\n", __VERSION__);
call() {
werror("Args: %O\n", __ARGS__);
mixed value = 1234;
werror("%O\n", lambda() {werror("%O\n", value);});
};
return 0;
}
```
In Pike 8 (tested on 8.1.15), the implicit lambda correctly receives
its `__ARGS__`, and will happily provide those as closure variables. In
Pike 9 (tested with current master, 235eb5), the inner function
somehow causes `__ARGS__` to be 0 instead of an array.
Any ideas as to what's going on here? Am I misusing implicit lambdas?
ChrisA
```
(26047339) /Chris Angelico <rosuav@gmail.com>/------
```Pike 9.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/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/10128switch with mapping lookup table broken on several 32-bit architectures.2023-07-04T08:48:38ZHenrik (Grubba) Grubbströmswitch with mapping lookup table broken on several 32-bit architectures.The fix for #10125 seems to have broken the `switch`-statement in `Locale.Language.nld.snumber()` several architectures fail the testsuite for `Web.RDF` with an infinite loop where `snumber(1)` appears to trigger the `default`-case.The fix for #10125 seems to have broken the `switch`-statement in `Locale.Language.nld.snumber()` several architectures fail the testsuite for `Web.RDF` with an infinite loop where `snumber(1)` appears to trigger the `default`-case.Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10125Consider using a mapping lookup in F_SWITCH when case ranges are not in use.2023-06-28T13:06:04ZHenrik (Grubba) GrubbströmConsider using a mapping lookup in F_SWITCH when case ranges are not in use.`array.c:switch_lookup()` currently uses binary search to perform the lookup. In the common case where no `F_CASE_RANGE`s are used it would be possible to just use a mapping lookup instead.
This would require a slight API change for `sw...`array.c:switch_lookup()` currently uses binary search to perform the lookup. In the common case where no `F_CASE_RANGE`s are used it would be possible to just use a mapping lookup instead.
This would require a slight API change for `switch_lookup()` in that the first argument would need to be a `struct svalue *` (instead of the current `struct array *`).Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10122Support Nettle 3.92023-05-17T14:30:55ZHenrik (Grubba) GrubbströmSupport Nettle 3.9Pike 8.0 and master trigger SIGSEGVs in Nettle 3.9. These are likely due to bugs in Nettle 3.9.
Consider adding (runtime-?) detection of Nettle 3.9.
Check with Nisse to see if there are work-arounds.Pike 8.0 and master trigger SIGSEGVs in Nettle 3.9. These are likely due to bugs in Nettle 3.9.
Consider adding (runtime-?) detection of Nettle 3.9.
Check with Nisse to see if there are work-arounds.