--- Log opened Mon Aug 29 00:00:03 2022
00:58 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
02:05 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
02:32 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
02:46 -!- orionwl is now known as laanwj
04:04 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
04:04 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 258 seconds]
05:47 < elichai2> real_or_random: might interest you, this looks like an efficient way to make memory cleansing not optimize away without inline assembly: https://godbolt.org/z/q85jd5Pbv
05:53 < realtbast[m]> There's a very recent thread on this on the cryptography mailing list, with a few interesting techniques mentioned: https://www.metzdowd.com/pipermail/cryptography/2022-August/037861.html
05:59 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
06:15 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
06:20 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
06:57 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
07:39 < real_or_random> elichai2: I know that technique. the disadvantage here is that this will always call the stdlib memset
07:40 < real_or_random> so no opportunity for the compiler to optimize the memset
07:40 < real_or_random> (optimize, not optimize out)
07:40 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
07:45 < real_or_random> but this is mentioned in that thread too... https://lkml.org/lkml/2022/8/25/1372 sigh, I guess writing constant-time code just got harder?
07:48 < halosghost> oof
07:51 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:55 < halosghost> recognizing that this is tangential, real_or_random do you happen to know if there's a published rationale from Intel/ARM? skimming the docs linked, I don't see why they'd want to do that
07:59 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
08:00 < real_or_random> halosghost: I guess performance?
08:00 < real_or_random> meeting, sipa nickler elichai2 
08:00 < real_or_random> hebasto
08:00 < nickler> hi
08:00 < elichai2> Hi :)
08:00 < real_or_random> siv2r[m]: 
08:01 < halosghost> real_or_random: the perennial excuse I suppose
08:01 < michaelfolkson> hi
08:02 < instagibbs> gotta make up for specter mitigation slowdowns ;)
08:02 < real_or_random> hehe yes
08:02 < real_or_random> topics?
08:03 < nickler> topic suggestion: https://github.com/bitcoin-core/secp256k1/pull/1055 it's not obvious to me what conclusions from your investigations into the library versions hebasto real-or-random
08:04 < real_or_random> hm not sure if there are conclusions
08:05 < real_or_random> it mostly helped us the understand these things better
08:05 < real_or_random> there's no need to deviate from the libtool versioning. it can be simulated with automake (so both systems would agree) 
08:06 < real_or_random> it may generate some big jumps, e.g., from 1.2.3 to 4.0.0 ... but that's not a problem, I think
08:07 < nickler> The only problematic aspect as far as I understand is that the SONAME version could easily hop from 0.x.y to 3.a.b but I don't understand the SONAME versioning scheme anyway so that might not be an issue.
08:08 < nickler> and hebasto, the table in your last comment, does it show anything unexpected?
08:08 < real_or_random> by the way, it seems that many other libraries don't care at all about binary compatibility and "reuse" semantic versioning for both API and ABI, i.e., they simply increase the corresponding number whenever they make an API *or* ABI change. if we weren't relying on libtool, this could be an option. but since libtool forces us to use their scheme, I guess we don't have a choice anyway :)  
08:09 < real_or_random> as I understand it, the only drawback of a large hops is aesthetics. 
08:09 < nickler> real_or_random: yes, the reason I added this is that our build system will give it a version number anyway, so we can try a best effort using what libtool suggests
08:10 < hebasto> everything is as expected
08:10 < hebasto> I confirm my ack
08:11 < real_or_random> ok yes. the reason I started this discussion was that I still had the feeling I don't fully understand what's going on. and then I figured out we need to make sure that both libtool and cmake can produce the same numbers. but apparently they can, so everything is alright
08:11 < nickler> ok cool, that answers my questions regarding 1055
08:13 < real_or_random> (I now understand why debian's glibc package is called glib6. that's just the SONAME. they have it in the package name, which makes a lot of sense but confuses the hell out of users who expect the number to a "normal" release version. ^^)
08:13 < real_or_random> *glibc6
08:13 < hebasto> my table was supposed to be a little help for other reviewers to get the origin of "gaps" in numbers
08:14 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
08:14 < real_or_random> so if they adopt the lib, maybe at some point we'll have secp256k1-17 package lol. but whatever, that's just their policy
08:15 < real_or_random> to be honest, I don't think we'll make a lot of releases that have ABI compat but no API compat. I would imagine when we break something it's 95% API or API+ABI
08:15 < real_or_random> anyway
08:16 < hebasto> libtool versioning cares about ABI only
08:17 < real_or_random> more topics? 
08:17 < real_or_random> I still haven't worked on  https://github.com/bitcoin-core/secp256k1/pull/1126 , sorry....
08:18 < real_or_random> maybe that's a short meeting then :)
08:20 < real_or_random> ok, I guess then we can close 
08:26 < halosghost> short and sweet
09:09 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
09:16 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
09:53 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:17 -!- jesseposner [~jesse@user/jesseposner] has quit [Ping timeout: 268 seconds]
10:22 -!- jesseposner [~jesse@user/jesseposner] has joined #secp256k1
10:35 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:16 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
12:15 -!- hg [~halosghos@user/halosghost] has joined #secp256k1
12:18 -!- halosghost [~halosghos@user/halosghost] has quit [Ping timeout: 255 seconds]
12:43 -!- hg [~halosghos@user/halosghost] has quit [Ping timeout: 252 seconds]
12:47 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
13:05 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Connection closed]
14:10 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
14:23 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
14:33 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
16:25 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.6]
22:51 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
23:01 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
23:18 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
--- Log closed Tue Aug 30 00:00:04 2022