configure: Add unsupported --with-system-libsecp256k1 configure flag

[luke-jr]

No description provided.

[sipa]

I don't think makes sense without guarantee that even the API remains stable.

[luke-jr]

@sipa Lots of libraries don't have stable APIs... The only reason this is risky/questionable in our case is the consensus-critical nature of it, but since we maintain libsecp256k1 anyway (unlike LevelDB), that risk is IMO much smaller (the unstable API actually helps for this).

[jonasschnelli]

IMO: this critical library should not be linked against a system install lib. Security: control your stack.
Even if sipa/core-devs maintains it, it throws over the whole deterministic build system in case of critical crypto functions.

[luke-jr]

@jonasschnelli Obviously we won't be using this in the deterministic binaries. It's also disabled by default and has a big fat warning label on it.

[jonasschnelli]

@luke-jr right. My fault. This won't affect the gitian part, right. Oversaw the warning as well. Looks good.

[laanwj]

NACK. Same reasoning as for leveldb but even stronger. The consensus code
must stay self-contained.

[sipa]

@laanwj while I agree about not doing this, currently libsecp256k1 isn't used in consensus code.

[laanwj]

I know. But that was the plan right?

I don't see how that's an argument for this. You want to merge this and than remove it again once it is used for verification/consensus?

[sipa]

No, I don't want to merge this. I'm just saying that currently the consensus argument is not (yet) valid :)

[jgarzik]

-1 I don't see why this additional option should be supported.

[paveljanik]

I'd also prefer only one: --with-system-libs. This would allow distro packagers to make clean packages. But one such option is enough ;-)

[jgarzik]

@paveljanik Based on practical experience, that would be dangerous. Packagers would ignorantly enable that by default, without understanding the consequences.

[paveljanik]

I think it is better to teach packagers to do it properly than package glibc/openssl/boost inside Bitcoin Core. And of course, they will surely modify our code to use system libs anyway... Thus it is much cleaner to do that even in upstream where they all can share their code/changes.

[paveljanik]

... and we can sanity check the libs at the startup as we already do.

[laanwj]

Forget teaching packagers anything. There are so many distros that we'd have to start a packager training school. Just making it hard to do is a good signal IMO.

[rebroad]

@luke-jr, when would/should this option be used please?