This is technically true, and nobody contested the CABF's focus on HTTPS TLS.
However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.
I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.
Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server.
This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.
The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1096750 (0x10bc2e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
Validity
Not Before: May 27 16:16:59 2015 GMT
Not After : May 28 12:34:54 2016 GMT
Subject: C = DE, CN = chat.yax.im, emailAddress = [email protected]
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:chat.yax.im, DNS:yax.im, xmppAddr:chat.yax.im, dnsSRV:chat.yax.im, xmppAddr:yax.im, dnsSRV:yax.im
Ironically, this was the last server certificate I obtained pre-LetsEncrypt.
Yes, this is what is happening. It isn't happening fast enough, so some implementations (especially servers that don't upgrade often enough, or running long-term-support OS flavors) will still be affected. This is the impact that the original article is warning about.
My point was that this is yet another change that makes TLS operations harder for non-Web use cases, with the "benefit" to the WebPKI being the removal of a hypothetical complexity, motivated by examples that indeed should have used a private PKI in the first place.
A federated ecosystem of servers that need to verify each other based on their domain name as the identity is the prime use-case for a public CA to issue domain-verified client certificates. XMPP happens to be this ecosystem.
Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort, essentially redoing all the hard work of LetsEncrypt, but without the major funding, thus ending up with an insecure solution.
We make use of the public CAs, that have been issuing TLS certificates based on domain validation, for quite a few years now, before the public TLS CAs have been subverted to become public HTTPS-only CAs by Google and the CA/Browser Forum.
It is really great how they write "TLS use cases" and in fact mean HTTPS use cases.
CA/Browser Forum has disallowed the issuance of server certificates that make use of the SRVName [0] subjectAltName type, which obviously was a server use case, and I guess the only reason why we still are allowed to use the Web PKI for SMTP is that both operate on the server hostname and it's not technically possible to limit the protocol.
It would be perfectly fine to let CAs issue certificates for non-Web use-cases with a different set of requirements, without the hassle of maintaining and distributing multiple Roots, but CA/BF deliberately chose not to.
The interop was a nice feature implemented by their engineers, but it violated the lock-in operational principles of the gatekeeper services, so it had to be abandoned. Let's see if the EU Digital Markets Act will bring back XMPP interfaces to the big ones... ;)
Regarding the RTOS, I took my NX300 from the shelf some weeks ago to make a few shots for the live demo at https://programm.froscon.org/froscon2025/talk/fc37ae17-9264-... and OH MY FSCKING GOD IT'S SLOW! I made a burst shot of a model train approaching, and the camera was busy processing it for multiple minutes. The NX500 is lightning fast in comparison, and the NX1 is even snappier.
So what do you plan to do with the ARM hook? I've poked at different places of di-camera-binary, but never at the processing pipeline, and there are soooo many things to reverse-engineer, and I'm but one person!
The other half of the problem is what to gain from a root shell. You can't influence the stages of the image processing without a PhD in Sony DSP Reverse Engineering, and so what remains is probably hooking into the camera controls and injecting key events to re-invent time-lapse timers or bulb exposures, and removing the 30min video recording limit.
This is where the NX mod project arrived - additional hooks into the camera controls and a few changes to internal registers left over by Samsung engineers for debugging, like silent shutter or the 30min limit.
When reverse-engineering some of the Samsung NX camera firmware files, I found USB-PTP code that implements different custom remote commands <https://chaos.social/@ge0rg/114723076401717110> but I'm not deep enough into PTP to make sense of them.
Is there anywhere a group focusing on understanding and re-implementing custom PTP protocols?
The last two generations of Samsung NX cameras were built around Tizen Linux, and it was (and still is) easy to get a root shell on them. They still make great photos and you still can buy them used for a good price.
NX300/NX30/NX2000 had a read-only rootfs, but for NX500 and NX1 there was a persistent mod that extended camera functionality with a menu, and you can actually SSH into them and rsync your photos... while shooting!
Looks like it was invented by two Fujitsu engineers, is free of patents and maybe was optimized for hardware implementation? I've linked some Japanese sources in the post, but I don't speak Japanese and the auto translation is not easy to read.
Creating a high performance image processing pipeline requires significant engineering effort and probably a custom SoC or DSP. You need to take care of auto focus and all the other physical configurations (shutter time, aperture, ISO), then you need to add post processing to correct for lens distortion and to do white balancing. I wish there was a FOSS camera, eg with the rather open MFT lens mount, but I don't see it happen any time soon.
I want back the UX of electronics from twenty years ago, with physical knobs and dials. Spare me the glitchy touch screens on kitchen appliances that can't be operated with wet fingers. Spare me the cheap pseudo buttons without a noticeable click point on washing machines. I don't want to wait multiple seconds after pushing the power "button" to see if the device just lags or if I didn't push hard enough. I don't want a TV that needs minutes to boot android, only to overlay what I want to see with ads benefiting the manufacturer. I don't want to wait a minute after starting the car before I can configure the heating... on a touch screen that first makes me accept the ToS.
I'm a huge fan of the NX mini and they are fully supported by the SNS API bridge.
I have a bunch of them, one converted to infrared. Usually I have the mini with me when the NX500 is too bulky. It's a pity that the lenses are so rare on the used market. The image quality is just awesome for the form factor!
So I've used the discussion here and the inspiration by @samcat116 to finally publish my review of the Samsung Galaxy NX - half smartphone, half "professional" camera: https://op-co.de/blog/posts/galaxy_nx/
Right, that's something that I'm actually sometimes missing on my NX500 when using vintage lenses, but I'm not sure how relevant it is for pro amateurs in general.
[ my public key: https://keybase.io/ge0rg; my proof: https://keybase.io/ge0rg/sigs/IbGDkSaF88bGZ5TR2pBfzVgSpIjQIR2ujem0AQx0qms ]