10:58 <mattip> fijal: would it make any sense to approach the _ssl buffer problem from another direction

10:59 <mattip> and rewrite parts of it in C, or at least allocate the buffer as a C array

11:01 <mattip> I guess not, since you don't control the "b" in "sendall(b)"

11:46 <cfbolz> mattip: indeed, the b comes from the user usually

11:47 <fijal> mattip: I think it kinda defeats the point of cffi

11:47 <fijal> in a way

11:47 <fijal> but we can try that, to some extent

11:47 <fijal> anyway, me and armin got sucked into strange expired certificates

11:47 <fijal> (for VR Sketch)

11:54 <LarstiQ> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ ?

12:02 <fijal> well ok, so generally "fuck you"?

12:02 <fijal> like, if I can't update the client code, then it's just not going to work

12:02 <fijal> nice

12:03 <LarstiQ> I'm not sure if that is it, but since this was a recent issue I thought it might be relevant

12:09 <mattip> yeah, you have to move to OpenSSL 1.1.0 or greater, so good luck with ubuntu 16.04 or python2, pypy2

12:15 <fijal> LarstiQ: this is pretty horrendous

12:53 <LarstiQ> fijal: well, also CA certs expire, there isn't really a way around that?

12:54 <fijal> they should get a new one no?

12:55 <fijal> the point is that they are relying on their self-signed cert that was introduced to a lot of software

12:55 <fijal> that's a bit dodgy, IMO

14:55 <nimaje> well a root cert expired and some software wasn't prepared for that (and as I understand that article their recommond setup is to send two chains one with the expired root cert and a second with a valid root cert for compatibility with some android versions as they keep trusting that root cert for some reason and don't trust the new root cert, but that doesn't works with openssl 1.0.* as it sees the

14:55 <nimaje> first invalid chain and just fails instead of looking at the second chain, which would be valid)

15:51 <Dejan> fijal, every root CA is self-signed, right?

17:54 <tumbleweed> looks like there's some bug in the VFP detection on 32bit ARM in pypy3.7 7.3.6rc2

17:54 <tumbleweed> https://buildd.debian.org/status/fetch.php?pkg=pypy3&arch=armel&ver=7.3.6%7Erc2%2Bdfsg-1&stamp=1633596078&raw=0

17:58 <tumbleweed> and some weird stack overflow building pypy2.7 on ppc64 (big endian): https://buildd.debian.org/status/fetch.php?pkg=pypy&arch=ppc64&ver=7.3.6%7Erc2%2Bdfsg-1&stamp=1633584747&raw=0

20:18 <agronholm> mattip: the latest py2 image on Docker hub at least works with the new LE certs; I had to update a legacy app today because of that issue

23:47 <tumbleweed> ah, that vfp detection issue is a red-herring, the issue I'm seeing is due to calling the JIT's detect_cpu in get_multiarch()

23:47 <tumbleweed> it broke on *all* the non-JIT architectures

23:53 <tumbleweed> and the multiarch values returned aren't correct anyway...

23:53 <tumbleweed> on i386 I get sys.implementation._multiarch -> x86-linux-gnu, it should be i386-linux-gnu

23:55 <tumbleweed> mattip: can you elaborate on the thinking behind 5f72d59b9aa1 ? Because that would return the correct values (for my use-case at last)