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

pull luke-jr wants to merge 1 commits into bitcoin:master from luke-jr:sys_libsecp256k1 changing 3 files +31 −2

luke-jr commented at 11:28 AM on December 3, 2014: member

No description provided.
configure: Add unsupported --with-system-libsecp256k1 configure flag 400969e7f7
sipa commented at 12:18 AM on December 4, 2014: member

I don't think makes sense without guarantee that even the API remains stable.
luke-jr commented at 5:35 AM on December 4, 2014: member

@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 commented at 6:50 AM on December 4, 2014: contributor

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 commented at 6:51 AM on December 4, 2014: member

@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 commented at 7:02 AM on December 4, 2014: contributor

@luke-jr right. My fault. This won't affect the gitian part, right. Oversaw the warning as well. Looks good.
laanwj commented at 1:21 PM on December 4, 2014: member

NACK. Same reasoning as for leveldb but even stronger. The consensus code must stay self-contained.
sipa commented at 1:27 PM on December 4, 2014: member

@laanwj while I agree about not doing this, currently libsecp256k1 isn't used in consensus code.
laanwj commented at 2:25 PM on December 4, 2014: member

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 commented at 2:30 PM on December 4, 2014: member

No, I don't want to merge this. I'm just saying that currently the consensus argument is not (yet) valid :)
jgarzik commented at 2:32 PM on December 4, 2014: contributor

-1 I don't see why this additional option should be supported.
paveljanik commented at 2:36 PM on December 4, 2014: contributor

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 commented at 2:42 PM on December 4, 2014: contributor

@paveljanik Based on practical experience, that would be dangerous. Packagers would ignorantly enable that by default, without understanding the consequences.
paveljanik commented at 2:54 PM on December 4, 2014: contributor

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 commented at 3:06 PM on December 4, 2014: contributor

... and we can sanity check the libs at the startup as we already do.
laanwj commented at 3:09 PM on December 4, 2014: member

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.
laanwj closed this on Dec 4, 2014
rebroad commented at 4:12 PM on March 1, 2016: contributor

@luke-jr, when would/should this option be used please?
DrahtBot locked this on Sep 8, 2021

Contributors