non working header?

[4dacowgirl]

Hi there. when I pull this down, and change the header defines, e.g.

#define SIGALG "eD"
#define SIGALG_HASHED "DE"
#define KDFALG "cS"

absolutely eff all happens.

So, they make no difference, why??? I can't make it out. I look in the code say for pubkey recreation or so

ithere are memcmp yet when checking they are in fact different (e.g. CHKALG and seckey_struct->chk_alg)

if (memcmp(seckey_struct->chk_alg, CHKALG, sizeof seckey_struct->chk_alg) != 0) {
exit_msg("Unsupported checksum function");

never fires... I am going insane here I think.. maybe you can point out what is going on?

[jedisct1]

1. Generate a new key (minisign -G).
2. Change CHKALG from B2 to B3.
3. Recompile (zig build)
4. Try to sign something (minisign -Sm test.txt)
5. You get an Unsupported checksum function error.

If not, make sure you are calling the right program,; the one you just compiled, not a system-wide installation. For example by providing the full path ``zig-out/bin/minisign`.

[4dacowgirl]

I wouldn't just close this. I am not using zig but using C. With your OWN CMAKE setup. vanilla. all you have to do is mkdir b;cd b; cmake ..;make and you would see the effect. If C is "unsupported" then don't add it, certainly not a build system. :) IF however, you are getting the expected error, which I (should* be getting too, it's amazingly odd.. unless some kinda crazy caching system here or whatever would be at play...

I am on archlinux/voidlinux a few others. (and for the record, by looking at C code, it should absolutely throw an error, yet doesn't).

I built with zig, still works without any issue.. despite changing all three ALGS this is what I get. yes, this is the local....
(i.e. it builds and runs and creates keys and does not react to any of the ALGS).
this is on arch. And yes, I don't get it. it's linked to system libsodium but no minisign in system so it can't be pulling in some other header, I don't think. I also checked in the code as I mentioned and prints two different values but doesn't bork. Please reopen this until it's confirmed where the issue would be.

I seen this across OSes too.

And for the record, I obviously change other values too like version in that header just to be sure it's not some bizarre ghost header being used and sure enough it all updates.. yet not those.

[jedisct1]

Linux is not easy to use. Keep experimenting, this is the best way to learn!

[4dacowgirl]

Ditto. Just next time, when you don't have verified your building code. don't just close stuff. Cheers. Broken code. You download your own master and build it you get the error correctly? If so, smells of a potential compiler bug on arch which when I have the bother to look into more, I guess I will as this was a cul-de-sac.

[4dacowgirl]

HI.. yes, it's a "broken system". Indeed there is some weird 'caching' going on, can be within a few ocmpilation rounds, sometimes it seems it lingers for hours... I had to recover some libs a while back, it's either this or more frighteningly, a nefarious logger or so. No caching mechanisms exist on this system (ccache or similar). When I ran a compilation today a day later, the header gets 'updated' and I get the result. I have noticed this many times but I have been dismissing it. now I know this system has to go. Cheers. (no wonder I thought I was going insane though :))