ge0rg

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 = hostmaster@yax.im
        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

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.

Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?

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.

[0] https://community.letsencrypt.org/t/srvname-and-xmppaddr-sup...

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... ;)

Yeah, I've documented a thing or two about the NX series on https://op-co.de/blog/tags/samsung-nx/

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!

Background: I've recently taken over maintenance of the NX-KS mod at https://github.com/ge0rg/nx-ks-mod

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.

And even one with interchangeable lenses: https://op-co.de/blog/posts/galaxy_nx/

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/

They only have absurdly high resolution. The optical quality is rather mediocre if you need to zoom or shoot in low light.

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.

Samsung actually released multiple Android-based cameras: the Galaxy Camera range with built-in zoom lenses (https://www.zisman.ca/blog/2013-01-05.html) and the Galaxy NX with interchangeable lenses: https://op-co.de/blog/posts/galaxy_nx/

They all suffered from running Android 4.x with no major upgrades from Samsung.

It seems like the consumer market was completely destroyed by smartphones, used by people who don't particularly care about image quality, and the professional market is people who do RAW shooting with image file sizes of 40..90MB, with post-processing on a PC.

Seems like the niche between those markets never was large enough to warrant this functionality, given that both mobile standards and cloud service APIs change multiple times over the lifetime of a camera.

The compact models are probably not competitive to modern smartphones, except if you need optical zoom.

The NX series interchangeable lens cameras however don't fare too badly compared to today's models, and have a good price-point on the used market, if you are ready to do some bargain hunting.

In the last decade, the improvements were largely in sensor resolutions (from 20MP to 40MP, not relevant for most practical uses) and in "smart" auto-focus, with better tracking of eyes, animals or objects.

Original blog post: https://op-co.de/blog/posts/samsung_nx_mastodon/

Samsung actually created such a monster. After a few zoom cameras running Android, they finally created the Samsung Galaxy NX, which was a mirrorless camera with a 20MP APS-C sensor and Android 4.2 (it was only slightly outdated on release in 2013). It's a mediocre camera (lacking most physical controls) and a mediocre android device (way too bulky and the fixed touchscreen isn't easy to use).

I agree with all of that, and that's an elaboration what the parent post said, but I still stand by my statement: the camera vendor apps are shitty because of that too, but they are also shitty because they are badly designed and coded.

This is all true, but the camera vendors are adding insult to injury with their ugly half broken apps that mostly don't work on top of that.

The Samsung NX1 and NX500 running Linux can be pretty easily scripted to upload JPEGs or RAWs to any online service, given that you have a Wi-Fi network with you. Unfortunately they are a decade old and rare on the second hand market.

I hoped that this article provides enough information serve as a tutorial, actually. It's just skipping the parts that should be easy to google for.

Especially regarding GPU acceleration... Running video-conferencing inside windows inside vbox is almost impossible, and even modestly complex GUI apps have a significant lag there.