<cruxbot>
[opt.git/3.6]: imagemagick: update to 7.1.0-32
<cruxbot>
[opt.git/3.6]: mdadm: fix build to include mdadm.static, FS#1909
<cruxbot>
[opt.git/3.6]: freetype: update to 2.12.1
<cruxbot>
[opt.git/3.6]: mutt: update to 2.2.4
hsan has quit [Quit: Leaving]
ocb has quit [Remote host closed the connection]
ocb has joined #crux
_moth_ has quit [Quit: _moth_]
_moth_ has joined #crux
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
<cruxbot>
[opt.git/3.6]: postfix: updated to version 3.7.2
<cruxbot>
[contrib.git/3.6]: postfix-pgsql: updated to version 3.7.2
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
<stenur>
Anyone an idea: i call "$2 open --type plain $PART_SWAP p_swap --key-file -" where $2=cryptsetup.static from my "first boot level", and it does say "ripemd160 not supported", but the same cryptsetup.static can do it just fine when the system finally is interactive.
<stenur>
This cryptsetup.static was compiled anew on Saturday with OpenSSL 3.0.2
<stenur>
I have never seen this in the past, same kernel (config), same busybox (fwiw).
<stenur>
Kernel config unchanged for long really. No no. Kernel has no modules, all static. I do generate an initrd on the fly if it does not exist yet, but no dracut no.
<stenur>
I mean it is easy to reproduce a bit on CRUX 3.7 with OpenSSL 3:
<stenur>
openssl speed ripemd160
<stenur>
You need instead: openssl speed -provider legacy ripemd160
<SiFuh>
Yeah I saw that on your link
<SiFuh>
Not the problem but are you randomnly encrypting swap?
<stenur>
That is what this is for, yes.
<SiFuh>
I do too
<stenur>
Legacy provider enabled since 2.4.1 says cryptsetup release notes
<SiFuh>
I am using serpent-xts-plain64 -s 512 on my main machine
<stenur>
it is all encrypted here SiFuh. I am just using static kernels plus kexec
<SiFuh>
stenur: cool, everything here is encrypted too
<stenur>
ok.
<SiFuh>
I left the CIPH="aes-cbc-essiv:sha256" in the swap script to give an idea of options
<stenur>
yes i was thinking about changing cipher, but i yet to discover where to find the list i can use ;-)
<SiFuh>
For me using dracut I had to make sure the encryption was a module. Never had the time to look into why
<SiFuh>
luks has the list
<SiFuh>
cryptsetup benchmark should also
<stenur>
ok. argon2id is the must-have today. the rfc is grazy.
<SiFuh>
I use serpent which is super slow
<SiFuh>
aes is pretty much the fastest
<stenur>
here too :)
<stenur>
but NSA proven for top secret (for 256+ bits _i think_)
<stenur>
We just had two updated NSA RFCs last week
<SiFuh>
NSA are also liars
<stenur>
RFC 9152 and 9151, the latter Commercial National Security Algorithm
<SiFuh>
Also for kernel level you can do cat /proc/crypto
<stenur>
ok thanks
<stenur>
problem is cryptsetup.static :)
<SiFuh>
New flags?
<SiFuh>
Going back to watch Jason and the Argonauts (1963)
<stenur>
Sure. cryptsetup does EVP_DigestInit_ex(h->md, h->hash_id, NULL), i presume that does load additional things.
<stenur>
And these are not available when disk is still encrypted.
<stenur>
Luckily the luks2 decryption is compiled in.
<SiFuh>
So a module?
ppetrov^ has joined #crux
<stenur>
Well i do not know. /usr/lib/libcrypto.a _does_ seem to have ripemd160.
<stenur>
But swap was not initialized. Well regardless thanks SiFuh. I will check out another algorithm.
<SiFuh>
I have always had to have crypto as a module to be able to boot
<stenur>
Kernel is all static.
<SiFuh>
And lvm
<SiFuh>
Let me know what you learn. Crypto is something I am deeply intersted in
<farkuhar>
How long has /usr/ports/contrib/r/r.png been invalid as a PNG image? The signature verifies fine, but the file itself only contains HTML. Skimming through the gitweb history doesn't reveal an obvious commit that replaced the once-good PNG image.
<cruxbot>
[contrib.git/3.6]: kexec-tools: v2.0.24 (renamed from kexec)
<stenur>
So i am now using '--hash sha512', will see how this works out on Saturday (shall nothing terrible happen) :-)
<stenur>
'Still wondering, cryptsetup release notes explicitly mention the problem as solved, OpenSSL 3 libcrypto.a has ripemd160, ... but it is not there.
<stenur>
It is there when the filesystem is available, however.
<farkuhar>
_moth_: the CRUX packaging guidelines say that it's not necessary to list core ports among the dependencies. Every user is expected to install the whole core repository.
<farkuhar>
And it appears that bison is among the core ports. Users who choose to install only part of core are responsible for any subsequent breakage.
<farkuhar>
For example, I yanked out core/vim from my system and replaced it with neovim. But then I couldn't build something that relied on /usr/bin/xxd (provided by vim), so I had to make an xxd-standalone port.
<_moth_>
farkuhar: thanks for the clarification, i didn't know that.
<farkuhar>
_moth_: no problem. Once you've upgraded to 3.7, you can remind yourself of such details by running `man Pkgfile`.