Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
CIAvash I'm getting TLS errors when I use `Cro::HTTP::Client` with URLs with https protocol. After upgrading`IO::Socket::Async::SSL`, only the error message changed gist.github.com/CIAvash/64407c15f8...9746682508 06:18
jnthnwrthngtn CIAvash: Try upgrading HTTP::HPACK too, I'm pretty sure I merged a PR there to fix it agaisnt latest Rakudo also 10:23
Hm, but did it need a new release...maybe. 10:24
CIAvash jnthnwrthngtn: Hmm, I ran zef upgrade on it, zef said they are already at their latest version. But I force installed it and now Cro::HTTP is working, not sure what happened. 11:43
lizmat the problem is (I believe) that Cro does not specify a version of IO::Socket::Async::SSL and just simply takes the highest that is installed 11:57
therefore, there doesn't seem to be a need for upgrading 11:58
jnthnwrthngtn lizmat: It specifies a minimum version 13:55
However, it'd be HTTP::HPACK that needs one here 13:56
lizmat I believe in pinning versions :-)
it would have needed a Cro bump then, but then at least everything would be clear imo :-) 13:57
jnthnwrthngtn Well, it only helps if Cro pins a Rakudo version :P 14:06
I worry to pin exact versions of things like IO::Socket::Async::SSL since if there's a security issue it's better folks can get the newer version of it. 14:07
Without having to wait for a Cro release 14:08
lizmat well, the Cro release could be minimal 14:10
to me not pinning feels to me that potentially you're sweeping a security issue under the rug 14:11
for people using Cro, they don't care much about IO::Socket::Async::SSL
they care about using Cro, and that being safe 14:12
now if you have version X of Cro, you can't really know for sure whether you're safe
suppose that you have another dependency that you don't control, that has an issue and the author doesn't upgrade quickly enough 14:13
you would need to fix that in Cro, wouldn't you ?
jnthnwrthngtn lizmat: Are you arguing that a future version of, say, IO::Socket::Async::SSL for example could introduce a new security issue? 14:17
lizmat no, I'm talking more general in any situation when you are responsible for a library with dependencies, and one of the dependencies has an issue 14:18
jnthnwrthngtn Ah. Well, yeah, that's always the risk of depending on something.
lizmat the user of *your* library generally doesn't care about what dependencies *your* library has
but it feels to me that when you're using a dependency, you become responsible for its functioning inside your library 14:19
jnthnwrthngtn I mean, I didn't trust any of Raku's URI modules, so there's Cro::Uri.
But the question is where to stop. 14:20
lizmat and as such, you owe it to *your* customers to make sure that a faulty dependency doesn't endanger them
well, it stops at your end: that can be before any problems (like not trusting URI and using your own) 14:21
jnthnwrthngtn Well, but all the problems triggering this round of breakage are due to Rakudo changes (which I agree with in principle, but it's still the case that Rakudo's tightening up around uint broke Cro). 14:26
lizmat true... and that is another can of worms :-)
jnthnwrthngtn Should we declare which Rakudo versions we're willing to support, and refuse to install on newer ones, because we don't know if we trust them?
lizmat yeah... indeed, that's the question :-) 14:27
I'm in a lot of minds about that :-(
jnthnwrthngtn I mean, that probably isn't terribly practical, but nor is refusing to depend on anything we don't have control over. 14:28
That'd imply for example that we should make IO::Socket::Async::SSL not depend on OpenSSL and instead duplicate the bits of it we need. But then we need to duplicate the effort of bundling current binaries for Windows, and other maint. Where do the resources to do that come from? 14:29
lizmat no, I'm not saying that
I mean, ultimately it *could* mean that, yes, but only if the OpenSSL people would be unresponsive 14:30
jnthnwrthngtn *nod* 14:31
Geth cro-http: bba383ebf8 | (Jonathan Worthington)++ | META6.json
Depend on a newer HTTP::HPACK

Which has a fix to cope with a Rakudo change.
16:07 Xliff joined 16:21 rypervenche left 23:21 jjatria left 23:23 jjatria joined