Comment by delusional 3 days ago
> You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
I don't understand what you mean by this. I can access them "as a file" because they are in fact just files
$ ls /etc/ca-certificates/extracted/cadir | tail -n 5
UCA_Global_G2_Root.pem
USERTrust_ECC_Certification_Authority.pem
USERTrust_RSA_Certification_Authority.pem
vTrus_ECC_Root_CA.pem
vTrus_Root_CA.pemLinux lacks a lot of APIs other operating systems have and certificate management is one of them.
A Linux equivalent of listing certificates through the Windows virtual file system would be something like listing /proc/self/tls/certificates (which doesn't actually exist, of course, because Linux has decided that stuff like that is the user's problem to set up and not an OS API).
Do note the 'ls' usage:
PS Cert:\LocalMachine\Root\> ls
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
Thumbprint Subject EnhancedKeyUsageList
---------- ------- --------------------
CDD4EEAE6000AC7F40C3802C171E30148030C072 CN=Microsoft Root C…
BE36A4562FB2EE05DBB3D32323ADF445084ED656 CN=Thawte Timestamp…
A43489159A520F0D93D032CCAF37E7FE20A8B419 CN=Microsoft Root A…
92B46C76E13054E104F230517E6E504D43AB10B5 CN=Symantec Enterpr…
8F43288AD272F3103B6FB1428485EA3014C0BCFE CN=Microsoft Root C…
7F88CD7223F3C813818C994614A89C99FA3B5247 CN=Microsoft Authen…
245C97DF7514E7CF2DF8BE72AE957B9E04741E85 OU=Copyright (c) 19…
18F7C1FCC3090203FD5BAA2F861A754976C8DD25 OU="NO LIABILITY AC…
E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46 CN=UTN-USERFirst-Ob… {Code Signing, Time Stamping, Encrypting File System}
DF717EAA4AD94EC9558499602D48DE5FBCF03A25 CN=IdenTrust Commer…
DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 CN=DigiCert Global …
I always love how linux fans do like to talk without any experience nor the will to get the said experience.
This is nice! What I find hard to grapple with is, how do other concepts of the file system map to these providers, even more so to Alias, Environment, Function or Variable? Like creating an item, deleting an item, copying an item, viewing contents and properties like permissions, size, visibility of an item?
For the Certificate provider specifically: When I think certificates and hierarchy, I think signing hierarchy of issueing certs. But this is not what is exposed here, just the structure of the OS cert store without context. and moving items has much more implications that inside a normal data folder. Thus I prefer certlm/certmgr.msc as they provide some more of it.
Sometimes It feels as they crammed too much into that idea, a forced concept. https://superuser.com/q/1065812/what-is-psprovider-in-powers...
there are magical holding areas in Linux as well, but that detail is up to TLS libraries like openssl at run-time, and hidden away from their clients. There are a myriad of ways to manage just ca certs, gnutls may not use openssl's paths, and each distro has its own idea of where the certs go. The ideal unix-y way (that windows/powershell gets) would be to mount a virtual volume for certificates where users and client apps alike can view/manipulate certificate information. If you've tried to get a internal certs working with different Linux distros/deployments you might be familiar with the headache (but a minor one I'll admit).
Not for certs specifically (that I know of) but Plan9 and it's derivaties are very hard on making everything VFS abstracted. Of course /proc , /sys and others are awesome, but there are still things that need their own FS view but are relegated to just 'files'. Like ~/.cache ~/.config and all the xdg standards. I get it, it's a standardized path and all, but what's being abstracted is here is not "data in a file" but "cache" and "configuration" (more specific), it should still be in a VFS path, but it shouldn't be a file that is exposed but an abstraction of "configuration settings" or "cache entries" backed by whatever thing you want (e.g.: redis, sqlite, s3,etc..). The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
> The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
In theory, this is what dbus is doing, but through APIs rather than arbitrary path-key-value triplets. You can run your secret manager of choice and as long as it responds to the DBUS API calls correctly, the calling application doesn't know who's managing the secrets for you. Same goes for sound, display config, and the Bluetooth API, although some are "branded" so they're not quite interchangeable as they might change on a whim.
Gnome's dconf system looks a lot like the Windows registry and thanks to the capability to add documentation directly to keys, it's also a lot easier to actually use if you're trying to configure a system.
No, he meant access like virtual pseudo filesystem - /proc, /sys etc
You can access files that contain certificate information (on any OS), but you can't access individual certificates as their own object. In your output, you're listing files that may or may not contain valid certificate information.
The difference is similar to being able to do 'ls /usr/bin/ls' vs 'ls /proc/12345/...' , the first is a literal file listing, the second is a way to access/manipulate the ls process (supposedly pid 12345). In windows, certificates are not just files but parsed/processed/validated usage specific objects. The same applies on Linux but it is up to openssl, gnutls,etc... to make sense of that information. If openssl/gnutls had a VFS mount for their view of the certificates on the system (and GPG!!) that would be similar to cert:\ in powershell.