--- Log opened Mon Nov 04 00:00:40 2024
00:07 -!- josie [~josibake@suhail.uberspace.de] has quit [Remote host closed the connection]
01:45 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
01:51 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
03:28 -!- Netsplit *.net <-> *.split quits: ghost43
03:35 -!- Netsplit over, joins: ghost43
03:47 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
03:49 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
04:38 -!- bitcoin-git [~bitcoin-g@2620:6e:a000:ce11::21] has quit [Quit: Bridge terminating on SIGTERM]
04:38 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::30] has quit [Quit: Bridge terminating on SIGTERM]
04:38 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::39] has joined #secp256k1
04:39 -!- roconnor [~quassel@coq/roconnor] has quit [Ping timeout: 252 seconds]
04:40 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has joined #secp256k1
04:40 -!- roconnor [~quassel@coq/roconnor] has joined #secp256k1
04:43 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
04:43 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #secp256k1
04:44 -!- bitcoin-git [~bitcoin-g@2620:6e:a000:ce11::21] has joined #secp256k1
04:44 -!- stratospher[m] [~stratosph@2620:6e:a000:ce11::1e] has joined #secp256k1
04:44 -!- laanwj [~laanwj@user/laanwj] has joined #secp256k1
06:08 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
06:21 < bitcoin-git> [secp256k1] jonasnick opened pull request #1631: release: prepare for 0.6.0 (master...0.6.0-prepare) https://github.com/bitcoin-core/secp256k1/pull/1631
06:32 -!- LainExperiments [~LainExper@user/LainExperiments] has joined #secp256k1
06:50 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:01 < nickler> hi
07:01 < real_or_random> hi
07:01 < sipa> hi
07:02 < hebasto> hi
07:02 < nickler> topic suggestion: release
07:03 < real_or_random> sounds reasonable :D
07:04 < nickler> I created https://github.com/bitcoin-core/secp256k1/pull/1631 which is essentially master + 2 bug fixes + the release preparation commit
07:04 < nickler> In particular, it doesn't include the memory cleaning PR or the symbol checker.
07:05 < sipa> is it realistic to get the memory cleaning in?
07:05 < nickler> It's a draft because the release notes are not complete. Currently working on that.
07:05 < nickler> sipa: I haven't looked at it so far. But I'm happy to rebase the PR.
07:05 < nickler> *release preparation PR
07:07 < real_or_random> nickler. if you're working on the changelog, here's what I had for the structs:
07:07 < real_or_random>  - Any struct `secp256k1_foo` can now be forward-declared using `typedef struct secp256k1_foo secp256k1_foo;`.
07:08 < real_or_random> (in case you didn't care about this item so faR) 
07:08 < nickler> real_or_random: thx!
07:08 < real_or_random> (under #### Changed)
07:09 < real_or_random> sipa: I think it's ready to be merged if you reACK, which should be trivial
07:09 < real_or_random> I guess the only question is if whether we want such a change just before the release, of if we want to give it some time to settle before a release
07:09 < sipa> real_or_random: yeah, on it
07:09 < nickler> But I don't fully understand this entry. You don't need the typedef to forward-declare it.
07:10 < real_or_random> but I don't it's particularly "dangerous". I mean we cleaned the memory before, just not properly, so I don't fear any semantic changes 
07:10 < sipa> You mean you could just use `struct secp256k1_foo;` ?
07:10 < nickler> yeah?
07:11 < sipa> in C++ I think that suffices, but in C it won't, I believe.
07:11 < real_or_random> why not? should work
07:11 < sipa> In C++, `struct secp256k1_foo;` declares "secp256k1_foo" as a type.
07:11 < real_or_random> https://gcc.godbolt.org/z/Ezqr1zxTz
07:11 < sipa> In C, structs and typedefs live in separate namespaces.
07:12 < real_or_random> yeah I mean you have to use it with `struct secp256k1_foo` then :P
07:12 < sipa> but the API functions use "secp256k1_foo*" arguments, not "struct secp256k1_foo*" arguments.
07:12 < real_or_random> ahh I see
07:13 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
07:14 < sipa> https://gcc.godbolt.org/z/1n5j73aTc
07:14 < nickler> looks like this is what achow101 does: https://github.com/bitcoin/bitcoin/pull/29675/files#diff-eac420957d57c05c5d89b88820db0371bdb2b04de615cae02c8ce282cf31715eR12-R13
07:14 < real_or_random> and technically speaking, I think the sentence "Any struct `secp256k1_foo` can now be forward-declared using `typedef struct secp256k1_foo secp256k1_foo;`" is correct in either case. It says the struct `secp256k1_foo` can be forward-declared, not the struct  `struct secp256k1_foo` 
07:14 < real_or_random> But I think it should say: Any type `secp256k1_foo` can now be forward-declared using `typedef struct secp256k1_foo secp256k1_foo;"
07:14 < real_or_random> The user doesn't care whether it's a struct or not. It
07:14 < real_or_random> is an API type
07:15 < sipa> nickler: yes, in C++
07:15 < real_or_random> nickler: ok yes, but that's really because it's C++
07:15 < nickler> ure
07:15 < nickler> sure
07:15 < real_or_random> and the typedef will also work in C++
07:16 < sipa> indeed
07:16 < real_or_random> Can also say this:
07:16 < real_or_random> Any type `secp256k1_foo` can now be forward-declared using `typedef struct secp256k1_foo secp256k1_foo;`" (C and C++) or  `struct secp256k1_foo secp256k1_foo;` (only C++).
07:16 < nickler> - Any type `secp256k1_foo` can now be forward-declared using `typedef struct secp256k1_foo secp256k1_foo;` (or `struct secp256k1_foo` in C++)
07:17 < sipa> real_or_random: duplicate "secp256k1_foo"
07:17 < real_or_random> nickler: sounds good, perhaps s/or/or also 
07:17 < real_or_random> sipa: oops
07:17 < real_or_random> too many foos
07:18 < nickler> kk
07:18 < real_or_random> "too many foos" would be an awesome compiler diagnostic
07:22 < real_or_random> I think the SECP256K1_APPEND_DFLAGS doesn't need a changelog entry. This is too niche
07:23 < nickler> real_or_random: it's used by bitcoin's build system as I understand it
07:24 < real_or_random> indeed. but it's a bit of a hack. the description already says "This variable is intended for debugging and special builds."
07:24 < real_or_random> but yeah, I don't think the changelog entry hurts
07:24 < real_or_random> it's just not necessary. 
07:26 < real_or_random> (so fine to keep it) 
07:28 < nickler> k
07:28 < real_or_random> merge https://github.com/bitcoin-core/secp256k1/pull/1579 /
07:28 < real_or_random> ?
07:31 < nickler> why not, theStack wrote it and real_or_random and sipa ACK'd it
07:31 < sipa> yeah
07:31 < real_or_random> if yes, this will also a changelog entry... New: "API functions now make a best-effort attempt to clear secrets from their stack frames before returning." Perhaps a bit too technical with the frame?
07:32 < sipa> They did that before too, it was just not a very thorough best effort.
07:32 < real_or_random> yeah, it was arguably not a "best" effort :D
07:33 < real_or_random> "API functions now make a not entirely unreasonable attempt to clear secrets from their stack frames before returning."
07:33 < real_or_random> jk
07:33 < sipa> "API functions now have improved clearing of secrets from their stack before returning (but this is still only a best effort attempt)."
07:34 < nickler> significantly improved, maybe
07:35 < bitcoin-git> [secp256k1] real-or-random pushed 10 commits to master: https://github.com/bitcoin-core/secp256k1/compare/a38d879a1a60...b161bffb8bfb
07:35 < nickler> would be good if this sounds beneficial enough to convince users to update
07:35 < bitcoin-git> secp256k1/master e7d3844 Tim Ruffing: Don't clear secrets in pippenger implementation
07:35 < bitcoin-git> secp256k1/master 1c08126 Tim Ruffing: Add secp256k1_memclear() for clearing secret data
07:35 < bitcoin-git> secp256k1/master d79a6cc Tim Ruffing: Separate secp256k1_fe_set_int( . , 0 ) from secp256k1_fe_clear()
07:35 < bitcoin-git> [secp256k1] real-or-random merged pull request #1579: Clear sensitive memory without getting optimized out (revival of #636) (master...revival_of_pr636_cleanse) https://github.com/bitcoin-core/secp256k1/pull/1579
07:36 < nickler> rebasing the preparation PR
07:39 < real_or_random> "API functions now clear secrets from the stack before returning using a significantly more robust method (but clearing secrets is still only a best-effort attempt)."
07:39 < sipa> sgtm
07:40 < real_or_random> "API functions now use a  significantly more robust method to clear secrets from the stack before returning (but clearing secrets is still only a best-effort attempt)."
07:40 < real_or_random> (simpler sentence structure)
07:42 < sipa> sgtm
07:46 < real_or_random> running the tests now
07:52 < real_or_random> the new musig.md is not in the autotools tarball (distcheck)  
07:52 < real_or_random> same for ellswift.md ...
07:53 < nickler> ok, fixing
07:53 < nickler> the other tests work for me
07:54 < real_or_random> ah yeah in the Makefile.am. EXTRA_DIST
07:54 < nickler> we should probably document the tarball check. It's not in the release process afaics.
07:54 < real_or_random> let me also check CMake
07:55 < real_or_random> yeah, I mean we test installation, so the "hard" stuff works, but we should probably add a manual inspection step for docs etc
07:59 < real_or_random> it's questionable whether we want to support the autotools tarball at all. so far we had considered the github tarball the canonical one, and I don't   think we have any CMake code for generating a tarball
07:59 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
08:00 < real_or_random> but yeah, let's maybe fix it now, and we can see later whether we want to keep this 
08:00 < sipa> sounds good
08:01 < nickler> I wouldn't consider the github tarball the canonical one. It's not signed.
08:01 < nickler> I added a fix to the PR.
08:04 < real_or_random> we already have https://github.com/bitcoin-core/secp256k1/issues/1175 issue, we should just revisit this after the release
08:05 < hebasto> re " I don't   think we have any CMake code for generating a tarball" -- it's a matter of a couple of new lines in CMakeLists.txt
08:05 < real_or_random> yep, though that's also in the issue :P
08:05 < real_or_random> the API report says we have two removed symbols. sounds right ^^
08:06 < nickler> Ok, sanity checks look good. If there's no issue with the PR, I guess we're waiting for CI to complete.
08:08 < real_or_random> shouldn't _LIB_VERSION_AGE be 0 ?
08:08 < real_or_random> " If any interfaces have been removed or changed since the last public release, then set age to 0. "
08:09 < real_or_random> or do we ignore the removal of the scratch space? 
08:10 < sipa> i guess we should set it to 0
08:10 < nickler> yeah! sry
08:11 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
08:11 < sipa> if we didn't consider the removal of the scratch space to be a compatibility break, we needn't have waited for a major release
08:11 < sipa> well, insofar that 0.x is "major"
08:12 < real_or_random> yeah indeed, and bindings code may actually use it 
08:12 < real_or_random> and then it's a PITA if you get missing symbol errors during runtime etc
08:16 < real_or_random> so we went from  libsecp256k1.so.2.2.1 to libsecp256k1.so.5.0.0 ...
08:16 < real_or_random> this scheme is weird but whatever
08:16 < nickler> xD
08:17 < sipa> sense, it makes none
08:17 < sipa> (yes, i know there are rules, and there are reasons for them, but the result is still inscrutible)
08:18 < real_or_random> I mean I could understand 3.0.0 because it's breaking
08:18 < real_or_random> but skipping 3 and 4?
08:19 < real_or_random> wait, is this actually consistent between the build system
08:20 < real_or_random> argh no -.- cmake now builds a 5.0.0
08:20 < real_or_random> autotools builds a 2.3.0
08:20 < sipa> ...
08:21 < nickler> sure? autotools builds 5.0.0 for me
08:21 < real_or_random> let me check again with a clean build
08:22 < real_or_random> ok, ok, I guess I forgot to rerun  configure
08:23 < sipa> master builds 2.2.2 with autotools for me; the PR builds 5.0.0
08:24 < sipa> cmake with the PR also builds 5.0.0
08:24 < real_or_random> cmake on master?
08:25 < real_or_random> It seems I had 2.2.1 there. at least that's what the abi-checker says and it uses cmake
08:25 < sipa> cmake on master creates 2.2.2
08:25 < sipa> so at least autotools and cmake behave identically in this regard
08:26 < real_or_random> ok, I just tested master and cmake again and it's also 2.2.2 
08:27 < real_or_random> whatever. if they're consistent, that's good
08:27 < real_or_random> still not convinced about skipping 3 and 4.  but at least it won't hurt, there are enough integers
08:28 < hebasto> re "still not convinced about skipping 3 and 4" -- that's normal for libtool versioning scheme
08:28 < sipa> i bet libtool or whatever internally uses a fixed-size integer for representing these
08:28 < sipa> so at some point we may run out!
08:29 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
08:29 < real_or_random> oh I understand now what the check-abi does
08:29 < real_or_random> it compares to the last tag, which is the 0.5.1 release, which still was 2.2.1
08:29 < real_or_random> so 2.2.2 was never released
08:30 < real_or_random> :D
08:30 < sipa> right!
08:30 < real_or_random> sipa: yeah if our development efforts speed up that much, I won't complain about this
08:30 < sipa> "first world problem"
08:31 < real_or_random> 4294967295th world problem
08:31 < real_or_random> wait for CI then and good to go?
08:32 < sipa> alright
08:32 < sipa> ehh, lots of CI jobs haven't started
08:32 < sipa> how long do we expect that to take?
08:32 < real_or_random> they're waiting for the docker build
08:32 < real_or_random> I assume
08:32 < sipa> (lunch has arrived here, happy to continue in 30-45 minutes or so)
08:33 < real_or_random> ah no, the docker image was finished 15 mins ago Oo
08:34 < real_or_random> captain?
08:34 < real_or_random> continue later? ^^
08:39 < nickler> hm?
08:40 < nickler> looks like we got some ACKs, so just waiting for CI results now
08:40 < real_or_random> yep
08:40 < real_or_random> sipa is at lunch
08:41 < real_or_random> I might be at dinner when CI arrives
08:41 < sipa> i do need to leave in ~2.5 hours or so
08:41 < sipa> getting a Merkle root canal
08:44 < nickler> :O luckily it's only log depth
08:45 < sipa> :D
08:51 < real_or_random> wut?
09:00 -!- LainExperiments [~LainExper@user/LainExperiments] has quit [Quit: Client closed]
09:04 < nickler> I'm guessing sipa is getting a root canal treatment
09:04 < nickler> 1 remaining check...
09:10 < nickler> done, merging
09:10 < real_or_random> ci is green
09:12 < sipa> alright
09:13 < bitcoin-git> [secp256k1] jonasnick pushed 5 commits to master: https://github.com/bitcoin-core/secp256k1/compare/b161bffb8bfb...0cdc758a5636
09:13 < bitcoin-git> secp256k1/master 145868a Hennadii Stepanov: Do not export `secp256k1_musig_nonce_gen_internal`
09:13 < bitcoin-git> secp256k1/master a306bb7 Jonas Nick: tools: fix check-abi.sh after cmake out locations were changed
09:13 < bitcoin-git> secp256k1/master df2eceb Jonas Nick: build: add ellswift.md and musig.md to release tarball
09:13 < bitcoin-git> [secp256k1] jonasnick merged pull request #1631: release: prepare for 0.6.0 (master...0.6.0-prepare) https://github.com/bitcoin-core/secp256k1/pull/1631
09:14 < real_or_random> :)
09:15 < bitcoin-git> [secp256k1] jonasnick pushed tag v0.6.0: https://github.com/bitcoin-core/secp256k1/compare/v0.6.0
09:15 < hebasto> \o/
09:17 -!- achow101_ [~achow101@user/achow101] has joined #secp256k1
09:18 -!- achow101 [~achow101@user/achow101] has quit [Ping timeout: 276 seconds]
09:18 < bitcoin-git> [secp256k1] jonasnick opened pull request #1633: release cleanup: bump version after 0.6.0 (master...0.6.0-cleanup) https://github.com/bitcoin-core/secp256k1/pull/1633
09:21 < nickler> created GH release: https://github.com/bitcoin-core/secp256k1/releases
09:21 < real_or_random> https://github.com/bitcoin-core/secp256k1/releases/tag/v0.6.0 link to Changelog is broken
09:21 < real_or_random> missing "-" in bitcoincore
09:22 < real_or_random> dinner may arrive any minute but I think it's ok to leave then. the cleanup PR looks good
09:22 < nickler> thx fixed
09:23 < real_or_random> we could also merge it already, it has two ACKs 
09:24 < real_or_random> ah and the email
09:26 < sipa> hi. back
09:27 < sipa> what's next, ACK on cleanup PR?
09:30 < real_or_random> yep
09:31 -!- LainExperiments [~LainExper@user/LainExperiments] has joined #secp256k1
09:34 < real_or_random> ok, all ACKs there
09:37 < real_or_random> nickler: merge?
09:39 < real_or_random> ok, I need to leave now for a few minutes, though dinner hasn't arrived yet. I think merging and the email are the only remaining things
09:44 < nickler> ok, merging
09:46 < nickler> sent the email
09:46 < bitcoin-git> [secp256k1] jonasnick pushed 2 commits to master: https://github.com/bitcoin-core/secp256k1/compare/0cdc758a5636...ec329c25010e
09:46 < bitcoin-git> secp256k1/master c97059f Jonas Nick: release cleanup: bump version after 0.6.0
09:46 < bitcoin-git> secp256k1/master ec329c2 Jonas Nick: Merge bitcoin-core/secp256k1#1633: release cleanup: bump version after 0.6...
09:46 < bitcoin-git> [secp256k1] jonasnick merged pull request #1633: release cleanup: bump version after 0.6.0 (master...0.6.0-cleanup) https://github.com/bitcoin-core/secp256k1/pull/1633
09:48 < sipa> \o/
09:48 < sipa> we done?
09:49 < nickler> yes
09:50 < sipa> Most excellent. Thank you, captain.
10:00 < nickler> aye, next one is for real_or_random to captain
10:26 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:27 -!- jamesob15 [~jamesob@108.44.248.162] has quit [Ping timeout: 248 seconds]
10:38 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:13 -!- LainExperiments [~LainExper@user/LainExperiments] has quit [Quit: Client closed]
11:14 -!- LainExperiments [~LainExper@user/LainExperiments] has joined #secp256k1
12:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
12:27 -!- achow101_ is now known as achow101
12:50 -!- LainExperiments6 [~LainExper@user/LainExperiments] has joined #secp256k1
12:53 -!- LainExperiments [~LainExper@user/LainExperiments] has quit [Ping timeout: 256 seconds]
12:59 -!- LainExperiments6 [~LainExper@user/LainExperiments] has quit [Ping timeout: 256 seconds]
13:36 -!- LainExperiments [~LainExper@user/LainExperiments] has joined #secp256k1
13:46 -!- LainExperiments [~LainExper@user/LainExperiments] has quit [Quit: Client closed]
13:52 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
13:56 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
14:29 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
18:46 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.4.2]
19:43 -!- harding [quassel@newmail.dtrt.org] has quit [Ping timeout: 248 seconds]
20:13 -!- harding [~quassel@newmail.dtrt.org] has joined #secp256k1
21:25 -!- Netsplit *.net <-> *.split quits: johnzweng, BlueMatt[m]
21:26 -!- Netsplit *.net <-> *.split quits: FelixWeis__, michaelfolkson, elichai2, siv2r
21:26 -!- Netsplit *.net <-> *.split quits: nickler, jnewbery, theStack
21:27 -!- Netsplit over, joins: nickler, jnewbery, theStack
21:27 -!- Netsplit over, joins: FelixWeis__, michaelfolkson, elichai2
21:28 -!- Netsplit over, joins: BlueMatt[m], johnzweng, siv2r
23:50 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
--- Log closed Tue Nov 05 00:00:41 2024