beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
Guest867 has joined #picolisp
<Guest867> Hi, All!
<Guest867> To keep going with my journey on picolisp correctly working on openbsd, now I had a problem with (passwd) and (auth) functions in @lib/adm.l. So wiki doesn't work. At some point in my struggle I decided just compile and link
<Guest867>  crypt library with picolisp and call it from exe itself. And even there, I'm actually not sure what library it wants to use -lcrypt,-lcrypto,-lgcrypt. I'm not a cryptographer and don't know any difference. So I opened manp
<Guest867> age. And it told me that "crypt" and other functions are deprecated in favor of crypt_checkpass(3) and crypt_newhash(3).
<Guest867> Ok. Let's see how those functions work. I compiled picolisp with -lcrypt flag. And basically googled example of using those funcs in c. Than ported them to picolisp. It seems to be working correct, but your guess could be be
<Guest867> tter than mine.
<Guest867> Now I'm still confused. Should I try to integrate those new funcs in @lib/adm.l? Should I try to fix what's already working everywhere else, except my OpenBSD. On the other hand there was a reason for deprecating those funcs
<Guest867> . I'm actually not sure if they were deprecated anywhere elese except OpenBSD. Right now I'm just messing around. And not convinced that picolisp's @lib/adm.l needs change.
<Guest867> And by the way. I think yestarday I tried to subsbcribe to mailing list. Not sure if I was successfull. My thinking was that in a mail I can attach files with code without clobbering the text. Anyway here's the link to my at
<Guest867> temt.
<abu[7]> Hi Guest567! Great that you investigate all this!
<abu[7]> Compiling should not be necessary though
<abu[7]> Why not call the lib via 'native' as before?
<abu[7]> You could simply 'patch' the .l functions
<abu[7]> Is your email mayor84... ?
<Guest867> yes
<abu[7]> subscribed yesterday
<Guest867> correct
<abu[7]> so it was successful
<Guest867> Thank you!
<Guest867> I just tried to describe what I did. When I used flag -lcrypt It seem to be working so I just left it in my Makefile.
<abu[7]> ok
<Guest867> MAIN = -rdynamic -lc -lutil -lm -lereadline -L/usr/local/lib -lffi -lncursesw -Wl,-z,nobtcfi -lcrypt
<abu[7]> I see
<abu[7]> just added at the end
<abu[7]> Still, why not keep it 'native'?
<Guest867> I had some weird problem in finding /usr/local/lib/crypt.so when I call the (passwd). Right now I'm looking through my notes
<Guest867> So I decided to link it to exe so would be sure what I'm calling. Something like that. I still didn't find my notes.
<abu[7]> Probably needs to set LD_LIBRARY_PATH
<abu[7]> (sys "LD_LIBRARY_PATH" "/...")
<abu[7]> or, yes, just an absolute path
<Guest867> So when I was calling (native "libcrypt.so" "crypt" 'S Str (or Salt (salt)))
<Guest867> It gave me an error that it cant find "libcrypt.so". I made a symlink but It gave me an error about hm wrong function call or something.
<Guest867> lap1$ pwd "libcrypt.so"
<Guest867> lap1$ ls -l libcrypt*
<Guest867> lrwxr-xr-x 1 root wheel 17 May 6 18:54 libcrypt.so -> libcrypto.so.56.0
<Guest867> -r--r--r-- 1 root bin 14176684 May 4 07:06 libcrypto.a
<Guest867> -r--r--r-- 1 root bin 7535704 May 11 06:07 libcrypto.so.56.0
<Guest867> -r--r--r-- 1 root bin 13298844 May 4 07:06 libcrypto_p.a
<Guest867> Anyway, my notes weren't very helpful, I'm going to try to run wiki again, may be I'll catch it.
<abu[7]> What if you call natiwe mith an absolute path?
<Guest867> Yes. I'll try it too. Right now, I want to get back to Makefile without my changes (from <taleon>) and try to run wiki again.
<Guest867> So. The pil21 and wiki is just downloaded and tar xzf -ed. Than I copied Makefile from <taleon>. Than gmake-ed it.
<Guest867> lap1$ ../pil -version -bye
<Guest867> 25.4.24
<Guest867> lap1$ ./pil21/pil wiki/main.l -main -go +
<Guest867> [wiki/init.l:18] !? (native "libcrypt.so" "crypt" 'S Str (or Salt (salt)))
<Guest867> Bad ffi
<Guest867> ?
<Guest867> That's how I started digging into @lib/adm.l and "crypt" functions.
<abu[7]> "Bad ffi" is if the symbol is not in the lib
<abu[7]> hmm
<abu[7]> maybe other reasons too
<abu[7]> but if the syntax of args is correct, it is the result of dlsym()
<abu[7]> Can you look with 'nm' if 'crypt is there?
<abu[7]> or 'strings'?
<Guest867> At first I suspected possible difference in function definition in OpenBSD and Linux. So I tried different libraries. And pretty much got the same result. So I decided to compile/link it to the exe. And now I'm here. :D
<Guest867> I have to find that library again, first. I'll do strings on it
<Guest867> So I have log list of strings with the word 'crypt' in it. I'm not sure what exactly I have to find
<Guest867> strings /usr/lib/libcrypt.so | grep -i 'crypt'
<abu[7]> Or perhaps nm -gD /usr/lib/libcrypt.so
<Guest867> I stil have a very long list
<Guest867> lap1$ nm -gD /usr/lib/libcrypt.so | grep -i 'crypt'
<Guest867> 00133ce0 T AES_cbc_encrypt
<Guest867> 00133cf0 T AES_cfb128_encrypt
<Guest867> 00133d40 T AES_cfb1_encrypt
<Guest867> 00133d90 T AES_cfb8_encrypt
<Guest867> 00133de0 T AES_ctr128_encrypt
<Guest867> ...
<Guest867> And I have to mention that
<Guest867> lap1$ file /usr/lib/libcrypt.so
<Guest867> lap1$ file /usr/lib/libcrypt.so
<Guest867> "/usr/lib/libcrypt.so: symbolic link to '/usr/lib/libcrypto.so.56.0'
<Guest867> Maybe I just made the wrong symlink
<abu[7]> hmm
<Guest867> I have another, gnu crypt library. But It looks like it doesn't have 'crypt' function either
<Guest867> lap1$ nm -gD /usr/local/lib/libgcrypt.so.21.2 | grep -i 'crypt'
<Guest867> 000e2050 T _gcry_3des_amd64_crypt_block
<Guest867> 000e8660 T _gcry_aes_amd64_decrypt_block
<Guest867> 000e76a0 T _gcry_aes_amd64_encrypt_block
<Guest867> 000ea380 T _gcry_aes_ssse3_decrypt_core
<Guest867> 000ea220 T _gcry_aes_ssse3_encrypt_core
<Guest867> 00144690 T _gcry_aria_aesni_avx2_ctr_crypt_blk32
<Guest867> 00144050 T _gcry_aria_aesni_avx2_ecb_crypt_blk32
<Guest867> 00140a80 T _gcry_aria_aesni_avx_ctr_crypt_blk16
<Guest867> 00140520 T _gcry_aria_aesni_avx_ecb_crypt_blk1_16
<Guest867> 00147750 T _gcry_aria_gfni_avx2_ctr_crypt_blk32
<Guest867> 00147620 T _gcry_aria_gfni_avx2_ecb_crypt_blk32
<Guest867> 00148fc0 T _gcry_aria_gfni_avx512_ctr_crypt_blk64
<Guest867> 00148a80 T _gcry_aria_gfni_avx512_ecb_crypt_blk64
<Guest867> 00142280 T _gcry_aria_gfni_avx_ctr_crypt_blk16
<Guest867> 00141fb0 T _gcry_aria_gfni_avx_ecb_crypt_blk1_16
<Guest867> 00146150 T _gcry_aria_vaes_avx2_ctr_crypt_blk32
corecheckno has joined #picolisp
Guest867 has quit [Ping timeout: 240 seconds]
Guest867 has joined #picolisp
<Guest867> >>>abu[7] 13:41:44 What if you call natiwe mith an absolute path?
<Guest867> native call with absolute path gives me the same result:
<Guest867> : (pp 'foo)
<Guest867> (de foo (Str)
<Guest867>    (native "libcrypt.so" "crypt" 'S Str (or Salt (salt))) )
<Guest867> -> foo
<Guest867> : (foo "pass")
<Guest867> !? (native "libcrypt.so" "crypt" 'S Str (or Salt (salt)))
<Guest867> Bad ffi
<Guest867> ?
<abu[7]> I meant  (native "/us /lib/libcrypt.so" or so
<abu[7]> "/usr/..."
<Guest867> Oh. I copied wrong note
<abu[7]> to be sure to get the right one
<Guest867> : (pp 'foo)
<Guest867> (de foo (Str)
<Guest867>    (native "/usr/lib/libcrypto.so.56.0" "crypt" 'S Str (salt)) )
<Guest867> -> foo
<Guest867> : (foo "pass")
<Guest867> !? (native "/usr/lib/libcrypto.so.56.0" "crypt" 'S Str (salt))
<Guest867> Bad ffi
<Guest867> ?
<abu[7]> ok :)
<abu[7]> Does it contain "crypt" ?
<Guest867> Looks like no. I greped the nm output and didn't find it. My guess it was deprecated and removed in OpenBSD
<abu[7]> I see
<abu[7]> But in C it worked?
<Guest867> In C i tryed only new funcs: crypt_checkpass, crypt_newhash. I can try to call "crypt" from C. I'll try it now
<abu[7]> Then also use a new func with native
<abu[7]> Probably the new funcs are better for some reason
<Guest867> # man crypt
<Guest867> # These functions are deprecated in favor of crypt_checkpass(3) and crypt_newhash(3).
<Guest867> # int crypt_checkpass(const char *password, const char *hash);
<Guest867> # int crypt_newhash(const char *password, const char *pref, char *hash, size_t hashsize);
<Guest867> (de PASSWORD_LEN . 128) #<pwd.h> _PASSWORD_LEN 128
<Guest867> (de error (Str) (println Str))
<Guest867> (de newhash (Pass)
<Guest867>    (buf Ptr PASSWORD_LEN
<Guest867>       (setq Ret (%@ "crypt_newhash" 'I Pass "bcrypt,a" Ptr PASSWORD_LEN))
<Guest867>       (ifn (=0 Ret)
<Guest867>          (error "crypt_newhash")
<Guest867>          (struct Ptr 'S))))
<Guest867> (de checkpass (Pass Hash)
<Guest867>    (setq Ret (%@ "crypt_checkpass" 'I Pass Hash))
<Guest867>    (ifn (=0 Ret)
<Guest867>       (error "crypt_checkpass")
<Guest867>       Hash))
<Guest867> (setq Pass "my-secret-password"
<Guest867> The new funcs are working fine. Or I didn't understand the difference between (%@ func ...) and (native @ func ...)
<abu[7]> It's the same
<abu[7]> just a shortcut
<Guest867> Oh! I get it. You're talking about calling them from /usr/lib/libcrypto.so.56.0". I'll try it now
<abu[7]> Instead of 'error' better use 'quit'
<Guest867> ok. Give me a minute
<abu[7]> Yes, "@" is the running binary itself
<Guest867> So, new funcs are working fine, even from full path lib. Only "crypt" doesn't
<Guest867> (de PASSWORD_LEN . 128) #<pwd.h> _PASSWORD_LEN 128
<Guest867> (de newhash (Pass)
<Guest867>    (buf Ptr PASSWORD_LEN
<Guest867>       (setq Ret (native "/usr/lib/libcrypto.so.56.0" "crypt_newhash" 'I Pass "bcrypt,a" Ptr PASSWORD_LEN))
<Guest867>       (ifn (=0 Ret)
<Guest867>          (quit "crypt_newhash")
<Guest867>          (struct Ptr 'S))))
<Guest867> (de checkpass (Pass Hash)
<Guest867>    (setq Ret (native "/usr/lib/libcrypto.so.56.0" "crypt_checkpass" 'I Pass Hash))
<Guest867>    (ifn (=0 Ret)
<Guest867>       (quit "crypt_checkpass")
<Guest867>       Hash))
<Guest867> (setq Pass "my-secret-password"
<Guest867>       Hash (newhash Pass))
<Guest867> (checkpass Pass Hash)
<abu[7]> cool
<Guest867> Does this code works on Linux? Is "crypt" deprecated on linux as well, but wasn't removed?
<abu[7]> The pathes are different on Linux, and crypt is replaced with a newer version I think
<Guest867> Not sure if I can trust it. But wiki says
<Guest867> he crypt() library function is also included in the Perl,[5] PHP,[6] Pike,[7] Python[8] (although it is now deprecated as of 3.11), and Ruby[9] programming languages.
<abu[7]> The algo used can be controlled via Salt
<abu[7]> (setq *Salt (16 . "$6$@1$"))
<Guest867> : *Salt
<Guest867> -> (16 . "$6$@1$")
<Guest867> : (pp 'foo)
<Guest867> (de foo (Str)
<Guest867>    (native "/usr/lib/libcrypto.so.56.0" "crypt" 'S Str *Salt) )
<Guest867> -> foo
<Guest867> : (foo "pass")
<Guest867> (16 . "$6$@1$") -- Bad argument
<Guest867> ?
<abu[7]> So is "$6$@1$" Linux-only?
<Guest867> Tricky question, I don't have anything with Linux. I can try it in termux
<abu[7]> try (salt)
<abu[7]> (pp 'passwd)
<abu[7]> ... (or Salt (salt))
<abu[7]> : (native "libcrypt.so" "crypt" 'S "pass" (salt))
<abu[7]> -> "$6$ShwIIjUCf17e6Kq/$eYNZcbLUWlHFgMeOVLkKKIWEzPGzCRjt1J38UmExJ.wwHOEDhHvxMqqw.Cs9mOmdiE71mOIZc1/jPBEiYlNHy/"
<abu[7]> As I said before, simply 'patch' the 'passwd' function
<abu[7]> : (patch passwd "libcrypt.so" "/usr/lib/libcrypto.so.56.0")
<abu[7]> : (pp 'passwd)
<abu[7]> (de passwd (Str Salt)
<abu[7]> (if *Salt
<abu[7]> (native "/usr/lib/libcrypto.so.56.0" "crypt" 'S Str (or Salt (salt)))
<abu[7]> Str ) )
<abu[7]> -> passwd
<Guest867> I see. I'll try it in a minute
<Guest867> here's my results from termux
<Guest867> : (pp 'foo)
<Guest867> (de foo (Str)
<Guest867>    (native "libcrypt.so" "crypt" 'S Str *Salt) )
<Guest867> -> foo
<Guest867> : *Salt
<Guest867> -> (16 . "$6$@1$")
<Guest867> : (foo "pass")
<Guest867> (16 . "$6$@1$") -- Bad argument
<Guest867> ?
<Guest867> : (call 'termux-info)
<Guest867> Termux Variables:
<Guest867> TERMUX_API_VERSION=0.51.0
<Guest867> TERMUX_APK_RELEASE=F_DROID
<Guest867> TERMUX_APP_PACKAGE_MANAGER=apt
<Guest867> TERMUX_APP_PID=32288
<Guest867> TERMUX_APP__BUILD_DATA_DIR=/data/data/com.termux
<Guest867> TERMUX_APP__DATA_DIR=/data/user/0/com.termux
<Guest867> TERMUX_APP__LEGACY_DATA_DIR=/data/data/com.termux
<abu[7]> In Termux it works with the standard Pil disto's version
<Guest867> In termux this works
<Guest867> (native "libcrypt.so" "crypt" 'S "pass" (salt))
<abu[7]> T
<Guest867> lap1$ ../pil21/pil @lib/adm.l hash3.l +
<Guest867> [hash3.l:31] (16 . "$6$@1$") -- Bad argument
<Guest867> ?
<Guest867> : : (native "libcrypt.so" "crypt" 'S "pass" (salt))
<Guest867> -> NIL
<Guest867> : -> "$6$ZYfP8DT7lgPHDZLb$ypiGmKkw3RpOZFKYWhMF8HPkIeNL4cxY1gDYpq2l8d/frCAMuN/EXvAvU1yAXDbhmuhsCJCDICUPq6m2DXMmA/"
<Guest867> I'm confused now. This works in OpenBSD as well
<abu[7]> T
<abu[7]> just *Salt does not work. I forgot the details.
<Guest867> No, it doesn't. It returns NIL
<Guest867> : (native "libcrypt.so" "crypt" 'S "pass" (salt))
<Guest867> -> NIL
<Guest867> In OpenBSD
<Guest867> I'm getting tired. Hopefully I'll get back to it tomorrow in the evening. Thanks a lot, now I have much better understanding of the problem.
<abu[7]> Thanks for investigation!
<Guest867> No problem. I enjoyed it!
<abu[7]> :)
Guest867 has quit [Ping timeout: 240 seconds]
Guest867 has joined #picolisp
chexum has quit [Ping timeout: 264 seconds]
chexum_ has joined #picolisp
Guest867 has quit [Quit: Client closed]
Guest867 has joined #picolisp
<Guest867> Just for reference. That's how others solve that compatibility issue.
ygrek has joined #picolisp
<abu[7]> uh .. lengthy ;)
beneroth has quit [Ping timeout: 244 seconds]
beneroth has joined #picolisp
Guest867 has quit [Ping timeout: 240 seconds]
ygrek has quit [Remote host closed the connection]
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp