|
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 | ||
| right | |||
| 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. |
14:48 | |
|
16:07
Xliff joined
16:21
rypervenche left
23:21
jjatria left
23:23
jjatria joined
|
|||