<Guest867>
I didn't have a chance to work on it yesterday. Only had a little time this morning. I suspect that this solution will break if -lcrypt version changes. But it works on OpenBSD.
<Guest867>
I'm not quite sure why it works only like this, with calling the exe itself. I had to compile picolisp with -lcrypt option. Otherwise picolisp again complains about Bad Ffi, even if I gave him full path to library.
<abu[7]>
I see. So a simple 'native' call is different? I ses no reason why it should be so ...
<Guest867>
Looks like it. I'll try to dig into it today
<abu[7]>
OK
<abu[7]>
nasty stuff :)
<Guest867>
That's how we learn! :)
<abu[7]>
true
<Guest867>
Just wild guess. May be OpenBSD somehow protects me from loading external libs at runtime. All those pledge and unveil. Just how to test this hypothesis?
<abu[7]>
This would be a permission issue? I cannot really imagine.
<abu[7]>
I suspect the problem to be sure to really access the right *.so file
<abu[7]>
-lcrypt vs. LD_LIBRARY_PATH
<Guest867>
yes and yes and yes. Now I have an idea how to test it.
<abu[7]>
It is confusing that there are so many crypt libraries
<Guest867>
sure is
Guest867 has quit [Quit: Client closed]
tankf33der has joined #picolisp
z4k4ri4 has quit [Ping timeout: 268 seconds]
z4k4ri4 has joined #picolisp
corecheckno has quit [Remote host closed the connection]
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #picolisp
rob_w has quit [Remote host closed the connection]
<taleon>
Pledge and unveil shouln't be a problem. PicoLisp wasn't compiled with these syscalls.
bjorkintosh has joined #picolisp
<taleon>
However, wxallowed is missing from the file system permissions for $HOME. By default, /usr/local is the only file system with wxallowed. Copy your picolisp code somewhere under /usr local and then test again to see if it works.
<taleon>
Most programs on OpenBSD aren't allowed to map memory with Write AND Execution bit at the same time (W^X means Write XOR Exec), this can prevents an interpreter to have its memory modified and executed. Some packages aren't compliant to this and must be linked with a specific library to bypass this restriction AND must be run from a partition with the "wxallowed" option.
<taleon>
However, I have no idea whether that is really the problem here.
aelius has joined #picolisp
bjorkintosh has quit [Ping timeout: 276 seconds]
bjorkintosh has joined #picolisp
Guest867 has joined #picolisp
<Guest867>
I still didn't dig into picolisp's native calls -lcrypt vs. LD_LIBRARY_PATH.
<Guest867>
Just had an idea. There is openssl everywhere. And it knows how to do sha256. Which is irreversible and uncrackable. Why don't we just use it from cmd line. Without all that native calls, etc.
<bjorkintosh>
is there a reason it wouldn't have worked in OpenBSD?
<abu[7]>
that's the question
<Guest867>
Oh. Just few days ago I hit a real true insanity with those newhash/checkhash passwords. Everybody doing it different way. And solution I found for OpenBSD refused to work in termux.
<bjorkintosh>
maybe termux was the problem.
<Guest867>
I mean. There's ports of OpenBSD ways of doing things to linux and such. And I clearly lack the knowledge which way is better.
<bjorkintosh>
a little man here and googling there and a stackoverflow will get you to where you need to be.
<Guest867>
Honestly, so far, this chat and mail archive was the most useful
<bjorkintosh>
+ irc
Guest867 has quit [Quit: Client closed]
f[x] has joined #picolisp
<beneroth>
well there is a big difference between "hashing to compare files/stuff" (optimized for speed) vs. "hashing to not store clear-text passwords" (optimized for more work, against speed and against scaling effects of better HW and parallelism)