< tryphe>
is there a reason configure.ac doesn't add "noexecstack" to LDFLAGS? it seems like we're using lots of other hardening options but not that one. is it not necessary?
< fanquake>
We also test our release binaries to ensure that the stacks are not marked executable
< tryphe>
fanquake, oh, that makes sense, i did see that in the gitian script for riscv while searching but couldn't figure out why not for everything else :p
< luke-jr>
tryphe: because it's not configure's job to decide your build flags
< luke-jr>
#14066 does set it explicitly for all platforms
< tryphe>
luke-jr, what's the point of ./configure --with-hardening then? it enabled relro, now, pie, but not noexecstack?
< luke-jr>
maybe --with-hardening should do that too
< tryphe>
on Debian 9, it's not, and i'm getting a different hash when i add noexecstack
< tryphe>
different bitcoind hash
< tryphe>
my thought was that everyone who went with --with-hardening assumed it was enabled, or maybe didn't know about it enough to look for it manually
< tryphe>
shall i open a PR?
< fanquake>
tryphe: is the binary actually marked as requiring an executable stack
< tryphe>
fanquake, good point, i guess not
< tryphe>
for both bins: src/bitcoind: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ec42b47cbaf82198ba6902e12568bac6f09ccde1, not stripped
< tryphe>
but i wonder why the bin hash is different, secondary differences?
< fanquake>
You can something like diffoscope on the two binaries and check what the differences are
< tryphe>
i guess if pie is on, it's still a shared object, so that could be why it's not on by default
< tryphe>
it's=noexecstack
< tryphe>
because i don't think you could have execstack with -pie
< tryphe>
building diffoscope now, it's just taking a bit :) will try to post it here when done if possible
< jonasschnelli>
hebasto: oh. 18152 looks great. I haven't looked at it previously! Will review.
< bitcoin-git>
[bitcoin] practicalswift closed pull request #18920: doc: Document how to analyze Bitcoin Core using Clang Static Analysis, clang-tidy and cppcheck (master...static-analysis-clang-tidy) https://github.com/bitcoin/bitcoin/pull/18920
< michaelfolkson>
fanquake: What do we know about how many people (if any) are running on these versions of these Windows?
< michaelfolkson>
fanquake: By enforce you mean not only do we not wish to support it we also want to do everything in our power that people don't try to run on these Windows versions?
< michaelfolkson>
Doesn't impact me personally so I guess that is a "couldn't care less" :)
< bitcoin-git>
[bitcoin] limpbrains opened pull request #19018: docs: fixing description of the field sequence in walletcreatefundedpsbt RPC method (master...walletcreatefundedpsbt-fix-docs) https://github.com/bitcoin/bitcoin/pull/19018
< bitcoin-git>
[bitcoin] luke-jr opened pull request #19019: [0.20] Fix GBT: Restore "!segwit" and "csv" to "rules" key (0.20...fix_gbt_buried) https://github.com/bitcoin/bitcoin/pull/19019
< phantomcircuit>
sipa, any opposition to putting the generated scriptPubKey's into FillableSigningProvider::mapScripts ?
< sipa>
phantomcircuit: achow101 may be a better person to ask at this point
< phantomcircuit>
achow101, same question^
< achow101>
for what purpose?
< sipa>
also, what does generated mean, and which signingprovider?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19020: net: Use C++11 member initialization in protocol (master...2005-netCxx11MemberInit) https://github.com/bitcoin/bitcoin/pull/19020