https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/security/SecureStringHelper.cs#L449

Parece ser CoreCLR lo que falta.

Talked @ KrishnaV-MSFT Esto no es necesario para la demostración de Azure. Sacarlo de Alpha.10

Encontré el mismo error en MacOS 10.12 Beta (16A270f)

Solo estaba jugando, entendí esto:

PS> $User="Jared"
PS> $PWord = ConvertTo-SecureString –String "TestString" –AsPlainText -Force   
PS> $Cred = New-Object -TypeName "System.Management.Automation.PSCredential" –ArgumentList $User, $PWord
PS> ConvertFrom-SecureString -SecureString ($Cred.Password)

Resultado:

ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:1
+ ConvertFrom-SecureString -SecureString ($Cred.Password)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringComman

Hola,

mismo error de biblioteca al intentar usar cert mapeado: psdrive:

Get-ChildItem Cert:/LocalMachine/

Error:

get-childitem: No se puede cargar la DLL 'crypt32.dll': no ​​se pudo encontrar el módulo especificado.
(Excepción de HRESULT: 0x8007007E)
En línea: 1 carácter: 1

• get-childitem Cert: / LocalMachine /
• ~ ~ ~ ~ ~ ~ ~~~
  
  
  
  • CategoryInfo: NotSpecified: (:) [Get-ChildItem], DllNotFoundException
  
  
  • FullyQualifiedErrorId: System.DllNotFoundException, Microsoft.PowerShell.Commands.GetChildItemCommand
  
  

@ 35359595 ¡ Buen hallazgo! El error definitivamente debería ser más amigable. En Linux y macOS, Cert:/ proveedor necesita un replanteamiento. La forma en que estos dos sistemas abordan el almacenamiento de certificados es completamente diferente entre sí y entre Windows.

Fyi, 16.04.1 con PowerShell v6 alpha 14 todavía tiene el mismo problema

Esto me impide llevar mis módulos a Linux. Me gustaría poder almacenar claves de API web de forma segura en todos los sistemas operativos, no solo en Windows.

Esto es algo que solo podremos habilitar con las API de .NET Standard 2.0 que recuperan SecureString:

• Problema de CoreFX: dotnet / corefx # 13062
• CoreFX 2.0 PR: dotnet / corefx # 13362

ConvertFrom-SecureString y ConvertTo-SecureString dependen de System.Security.Cryptography.ProtectedData , que todavía no está disponible en netstandard2.0 .
Por lo tanto, estos 2 cmdlets deben volver a trabajarse en plataformas Unix.

Realmente agradecería que esta funcionalidad llegue a .Net Core
Confiamos en WinRM y usamos PSCredential para autenticarnos. Ejecutar nuestros scripts en Linux o MacOS no es posible en este momento y nos está frenando un poco.

Error que vemos:
ConvertTo-SecureString: no se puede cargar la DLL 'CRYPT32.dll': no ​​se pudo encontrar el módulo especificado.
(Excepción de HRESULT: 0x8007007E)

@ reddwarf666 El paquete System.Security.Cryptography.ProtectedData está disponible en nuget.org y es una queja de netstandard2.0. Sin embargo, no tiene implementación para plataformas Unix; arrojará 'PlatformNotSupportedException' en plataformas Unix. Por lo tanto, ConvertFrom/ConvertTo-SecureString debe reescribirse para Unix. Intentaremos obtener alguna orientación del equipo de .NET Core sobre cómo realizar las mismas tareas en Unix. / cc @joeyaiello

¿Es probable que [System.Runtime.InteropServices.Marshal] :: SecureStringToBSTR y [System.Runtime.InteropServices.Marshal] :: PtrToStringAuto aparezcan en el viaje?

Sigo viendo esto en 6.0.0-beta3 en Mac y Linux cuando se usan cmdlets SecureString.

ConvertFrom-SecureString: No se puede cargar la DLL 'CRYPT32.dll': el especificado
módulo o una de sus dependencias no se pudo encontrar.
(Excepción de HRESULT: 0x8007007E)

lo mismo aquí con convertfrom-securestring y convertto-securestring (v6.0.0-beta.3) en linux debian (jessie 64bit):

PS /> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
GitCommitId                    v6.0.0-beta.3
OS                             Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS />

PS /> read-host -assecurestring | convertfrom-securestring | out-file securestring.txt
********
convertfrom-securestring : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:29
+ read-host -assecurestring | convertfrom-securestring | out-file secur ...
+                             ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand



md5-0a78a142751a1081c46c48e10b6cba93



PS /> $pass = cat securestring.txt | convertto-securestring
convertto-securestring : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:32
+ $pass = cat securestring.txt | convertto-securestring
+                                ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [ConvertTo-SecureString], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertToSecureStringCommand



md5-25ce90db07e4f9f61b58abd5cf739027



PS /> [Reflection.Assembly]::LoadFrom("CRYPT32.dll")
Exception calling "LoadFrom" with "1" argument(s): "Bad IL format."
At line:1 char:1
+ [Reflection.Assembly]::LoadFrom("CRYPT32.dll")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : BadImageFormatException



md5-0a78a142751a1081c46c48e10b6cba93



PS /> Add-Type -Path 'CRYPT32.dll'
Add-Type : Bad IL format.
At line:1 char:1
+ Add-Type -Path 'CRYPT32.dll'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-Type], BadImageFormatException
    + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.AddTypeCommand

copiar a /opt/microsoft/powershell/6.0.0-beta.3/ y también cuando se especifica la ruta absoluta, da el mismo error que el anterior.

¿Existe una solución alternativa posible / conocida o tenemos que esperar hasta que se solucione?

@vchrizz Windows y Unix no son compatibles con los binarios y no podemos usar Windows dll en Unix. Entonces deberíamos esperar CoreFX.

@iSazonov Soy consciente de esto, me preguntaba por esos archivos .dll en /opt/microsoft/powershell/6.0.0-beta.3/ pero luego descubrí:
archivos .dll de linux:
"PE32 ejecutable (DLL) (consola) Ensamblaje Intel 80386 Mono / .Net, para MS Windows"
"PE32 + ejecutable (DLL) (consola) Ensamblaje Mono / .Net, para MS Windows"
Archivo Windows CRYPT32.dll:
"PE32 ejecutable (DLL) (GUI) Intel 80386, para MS Windows"

ahora buscando una solución alternativa y encontré el mismo problema con Export-Clixml:

PS /> $cred=Get-Credential –credential "myuser" | Export-Clixml SecureCredentials.xml

Windows PowerShell credential request
Enter your credentials.
Password for user myuser: **********

Export-Clixml : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:45
+ ... Credential –credential "myuser" | Export-Clixml SecureCredentials.xml
+                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Export-Clixml], DllNotFoundException
    + FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ExportClixmlCommand

@vchrizz Actualmente .Net CLI coloca todos los ensamblajes en paquetes Unix. # 3961 rastrea el empaquetado de Unix.

@ daxian-dbw Podríamos usar OpenSSH para proteger / desproteger datos.

Prefiero que no hagamos nada personalizado para los que no son de Windows. Parece que el equipo de Nuget también está pidiendo esto.

@ SteveL-MSFT, puede confirmar que el equipo nuget lo necesita (NuGet / Home # 1851), ya que fui yo quien mencionó que era una funcionalidad faltante

@ SteveL-MSFT @psmulovics Parece que el equipo de CoreFX no rastrea los problemas cerrados en absoluto; creo que deberíamos abrir un nuevo problema allí si queremos algún progreso.

Se creó un nuevo número https://github.com/dotnet/corefx/issues/22510

¡Funcionó! 😄 Ahora tenemos una respuesta:

No tenemos planes de hacer esto. Requiere funciones del sistema operativo que solo están disponibles en Windows.
..
Lo que tenemos en .NET Core es claro. En Windows, hace lo que hace DPAPI. En los que no son Windows, hace lo que Windows DPAPI hace en esas plataformas: no existe.

Entonces deberíamos concluir:

1. Use el paquete System.Security.Cryptography.ProtectedData en Windows y bloquee la función en otras formas de plan.
2. Cree una solución alternativa para otras formas en planta. - Si es así, creo que deberíamos abrir un nuevo problema para su seguimiento.

Gracias por mirar en esto.

@iSazonov ¿la opción 2 también incluiría System.Runtime.InteropServices.Marshal?

@iSazonov Supongo que al menos tenemos claridad sobre por qué no se hará en lugar de simplemente cerrar el problema. Dado que este no es un elemento de trabajo pequeño, creo que lo investigaremos para 6.1.0

@ SteveL-MSFT Para compatibilidad con versiones anteriores de Windows PowerShell, creo que es bueno usar System.Security.Cryptography.ProtectedData hoy.

@ngetchell La solución, como se describe en el problema CoreFX, requiere demasiado trabajo específico, así que esperaremos CoreFX. Una posible solución alternativa para los sistemas Unix puede ser: utilizar una conexión remota a los sistemas Windows.

@iSazonov, la reproducción me funciona con beta.4 en Windows, creo que el problema solo está en Windows actualmente

@ SteveL-MSFT Lo siento por la inexactitud, en System.Security.Cryptography.ProtectedData quise decir _CoreFX package_. Actualmente usamos implementación interna. La pregunta es: ¿debemos eliminar el código interno y migrar al paquete? ¿Deberíamos eliminar los cmdlets * -SecureString de Unix?

@iSazonov Creo que deberíamos pasar al paquete oficial. En cuanto a Unix, parece que lo correcto es eliminarlos. cc @joeyaiello

Solo quiero volver a hacer ping a esta historia.
¿Sigue siendo el plan _eliminar_ los cmdlets ConvertTo / ConvertFrom SecureString?
¿Qué pasa con el manejo de Credenciales y SecureStrings en Importar / Exportar CliXml?

Todos estos siguen lanzando la muy hostil DllNotFoundException de HRESULT ...

Tengo el mismo problema con el error CRYPT32.dll en Linux cuando uso el cmdlet Export-Clixml. Versión PS 6.0.0

Igual que aquí. Dado que estamos discutiendo sobre la portabilidad de algunos scripts, sería maravilloso saber si tenemos que solucionar el problema o si se va a hacer algo en el lado pwsh o CoreFX (el último parece que no).

@cenit Quizás usemos el paquete de compatibilidad de Windows

@iSazonov , tengo entendido que SecureString depende de la compatibilidad con un sistema operativo específico que no está disponible en dispositivos que no son de Windows y no forma parte del Paquete de compatibilidad de Windows.

Deberíamos proporcionar un mensaje de error mejor aunque esto no funcione.

¿Existe alguna alternativa posible a los cmdlets * -SecureString en Unix si se eliminarán?
Lo siento si me lo perdí, dame un indicio de por qué no es posible en Unix. ¿Cuál es la parte "específica del sistema operativo" que falta necesaria en Unix?
¿De qué otra manera se pueden manejar las credenciales para obtenerlas en el formato correcto y seguir utilizándolas?

Creo que este problema en CoreFX lo resume perfectamente: https://github.com/dotnet/corefx/issues/22510
También parece que, lamentablemente, no se está avanzando.

gracias, eso lo explica muy bien.

@ SteveL-MSFT Al usar WCP, se asume que se usa un patrón común if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) { ... }
Si alguna API está ausente en WCP, podríamos enviar comentarios en el repositorio de WCP. Pero incluso sin él, podemos usar el patrón común combinado con #if !UNIX .

@iSazonov para este problema específico, no creo que WCP resuelva esto ya que el tipo SecureString es realmente una implementación vacía en no Windows.

De todos modos me gusta. 😄

Ok, estoy editando esto para asegurarme de que lo entendí bien ...

1. No hubo implementación de SecureString excepto en Windows.
2. El equipo de PowerShell se burló de él, por lo que pudieron evitar cambiar todas sus API que lo requieren.
3. Luego, el equipo de .NET lo implementó, pero solo la protección en memoria a corto plazo
4. Entonces, intentar serializar un SecureString (in) falla excepto en Windows, porque toda la función ahora es solo de Windows, pero está expuesta en todas partes ...

A pesar de la alerta temprana de esto desde hace 18 meses

A pesar del mensaje _extremadamente claro_ del equipo de .Net Framework hace 6 meses.

🙄

La conclusión es que el marco .NET (y PowerShell) necesita una biblioteca de protección de datos multiplataforma, porque los desarrolladores / operaciones necesitan almacenar secretos no desaparecieron repentinamente cuando agregamos nuevos sistemas operativos a la mezcla, y no siempre es práctico confiar en servicios web como Azure KeyVault, RED Identity Management o Thycotic Secret Server. 😕

El equipo de .NET aparentemente no está dispuesto a ser particularmente útil aquí.

Sé que ASP.NET escribió sus propias cosas de protección de datos , pero es bastante extraño y recomiendan limitar su uso a escenarios específicos ...

Lo que necesitamos saber es:

¿El equipo de PowerShell planea crear una implementación multiplataforma de serialización SecureString?

Si no es así, elimine los cmdlets que no funcionan en absoluto y proporcione un mensaje de error mejor para CliXML que el actual, "Oh, maldición, si solo hubiera un Crypto dll disponible".

Consulte los artículos relacionados:
NuGet / Hogar n. ° 1851
dotnet / corefx # 6746

Podríamos usar ASP.NET DataProtection. Este es el más confiable de lo que está disponible en la actualidad. Especialmente porque necesitamos bastante.

Estoy tratando de leer una contraseña de forma segura para pasarla a una línea de comandos de MySQL. ¿Cuál es la alternativa recomendada para no enviar contraseñas a la consola mientras las escribo?

Pasos de reproducción

$str = Read-Host -AsSecureString
ConvertFrom-SecureString -SecureString $str

Resultado

ConvertFrom-SecureString : Unable to load DLL 'CRYPT32.dll': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
At line:1 char:1
+ ConvertFrom-SecureString -SecureString $str
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand

@ pcgeek86 Esta es una solución para obtener la cadena de texto sin formato de una cadena de seguridad en Linux:

$str = Read-Host -AsSecureString
$plaintext = [System.Net.NetworkCredential]::new('',$str).Password

Agregué otra solución en la descripción

Manejar secretos en Linux parece ser un desastre. Hay muchos esfuerzos de implementación y proyectos obsoletos.

Parece que Gnome está usando la API del Servicio Secreto . libsecret parece ser una biblioteca para acceder a secretos usando el bus del Servicio Secreto.

Mac OS X permite interactuar con el llavero mediante la utilidad de línea de comandos security o mediante programación a través de los servicios del llavero .

QtKeychain es un enfoque para crear una contraseña independiente de la plataforma y un administrador secreto para Linux (usando libsecret), Mac OS X (usando el Key Chain) y Windows (usando Windows Credential Store) y probablemente sea lo más cercano a lo que se requiere para PowerShell. ¿Podríamos usar esto como punto de partida?

Hasta que esto se solucione, aquí está el código para pasar de forma segura una credencial a un trabajo en segundo plano:

$credentialKey = New-Object 'byte[]' (256/8)
$rng = New-Object 'Security.Cryptography.RNGCryptoServiceProvider'
$rng.GetBytes($credentialKey)

$serializableCredential = [pscustomobject]@{ 
                                                UserName = $credential.UserName;
                                                Password = ConvertFrom-SecureString -SecureString $credential.Password -Key $credentialKey
                                            }

$job = Start-Job {
    param(
        [Parameter(Mandatory)]
        [byte[]]
        $Key
    )
    $serializedCredential = $using:serializableCredential

    $password = ConvertTo-SecureString -String $serializedCredential.Password -Key $Key
    $credential = New-Object 'PSCredential' ($serializedCredential.UserName,$password)
    [Array]::Clear($Key,0,$Key.Length)
} -ArgumentList (,$credentialKey) | Wait-Job | Receive-Job

[Array]::Clear($credentialKey,0,$credentialKey.Length)

Contraseña = ConvertFrom-SecureString -SecureString $ credential.Password -Key $ credentialKey

¿Cómo se supone que funciona esto si esto tiene un problema en sí mismo?

de todos modos, probé su script pero obtuve un error:

ConvertFrom-SecureString : Cannot bind argument to parameter 'SecureString' because it is null.
At /home/myusername/powershell.ps1:7 char:99
+ ... = ConvertFrom-SecureString -SecureString $credential.Password -Key $c ...
+                                              ~~~~~~~~~~~~~~~~~~~~

así que intenté definir el nombre de usuario y la contraseña en una variable pero:

ConvertFrom-SecureString : Cannot bind parameter 'SecureString'. Cannot convert the "testpassword" value of type "System.String" to type "System.Security.SecureString".

¿Por qué no hay un problema separado para pasar una cadena segura sobre psremote? Todos los problemas abiertos se cerraron como duplicados de este. En mi opinión, el problema es diferente.
PSRemote se bloquea durante el intercambio de claves debido a la falta de implementación de CryptoAPI en Linux.
Quién interesado cuelga aquí https://github.com/PowerShell/PowerShell/blob/5ece96a37fc9bb5cda962b32741b00396ae0f135/src/System.Management.Automation/utils/CryptoUtils.cs#L1117
Por cierto, podemos agregar un controlador de excepciones que muestre el mensaje de que securestring aún no es compatible ^ es bastante difícil darse cuenta de que está relacionado con securestrings si se cuelga así.
Creo que psremoting se puede arreglar sin arreglar ConvertFrom-SecureString commandlet, porque no necesitamos almacenar claves en la máquina para su uso posterior. Solo necesitamos generar un par de claves rsa 2048, cifrar / descifrar utilizando rsa, descifrar cifrar utilizando la plataforma cruzada AES CBC.

Una buena noticia es que existe una solución alternativa entre plataformas.
Solución alternativa para PSRemoting
Utilice la implementación nueva de Python de PSRP. ¡ Pypsrp es compatible con cadenas de seguridad!

@KKomarov Abra un nuevo problema con los pasos del repositorio y su sugerencia.

@KKomarov, el bloqueo ya se ha solucionado en PSCore6.2-RC como parte de https://github.com/PowerShell/PowerShell/issues/8723 . La capacidad de enviar cadenas seguras para usuarios que no son de Windows debería ser un tema aparte.

DE0001: SecureString no debe usarse
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

@sazonov

DE0001: SecureString no debe usarse
https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md#de0001 -securestring-shouldnt-be-used

Si bien eso es bueno en un mundo de torre de marfil perfecto, en Powershell estamos uniendo constantemente las cosas y eso requiere autenticarnos en cualquier formato que requiera la aplicación, ya sea API de descanso, aplicación heredada que solo admite autenticación básica, etc. "use credenciales o certificados de Windows" para todo, como dice esta recomendación, es una buena recomendación para desarrollar una nueva aplicación, pero no para lo que usamos powershell.

No es que PSCredential vaya a ninguna parte, ya que es una implementación de SecureString, así que hasta que tengamos algo en el núcleo .net que pueda usar un TPM para cifrar claves o algo así, necesitamos una opción "suficientemente buena".

Algo como usar AES256 y hacer que la clave de cifrado sea un archivo con permiso de 600 en el sistema de archivos que no es de Windows es un posible comienzo, no mucho peor que usar la API de cifrado en Windows

Agregué el enlace solo para información.

Esencialmente:

1. Es imposible portar SecureString porque System.Security.Cryptography.ProtectedData es solo para Windows. No hay planes para portar la API. El equipo central desaprueba la API.
2. Podemos mantener la compatibilidad con versiones anteriores de SecureString en Windows (incluida la comunicación remota)
3. PowerShell Core debe permanecer flexible y permitir trabajar con aplicaciones heredadas.
4. Es aceptable utilizar la autenticación básica en un entorno protegido.
5. Problema principal cómo detectar entorno protegido vs entorno público y qué hacer (evitar la autenticación básica, solo advertir, ...).

Al principio, el comité de @ PowerShell / powershell discutió la introducción de un SensitiveString para reemplazar la necesidad funcional de SecureString aunque ambos no son seguros (el tipo SecureString todavía sería necesario para compatibilidad con versiones anteriores). Un tipo (ya sea "Sensible" o "Seguro" es necesario para indicar a PowerShell que solicite sin hacer eco de la entrada, por lo que se usa más que solo para la comunicación remota. En cuanto al problema original de este error, esto se ha solucionado (no obtenga un error más), solo tenga en cuenta que SecureString está internamente en texto sin formato.

gracias por la actualización, parece prometedor!
¿Podemos pedir un marco de tiempo aproximado en el que esperar poder utilizar esto (por ejemplo, en el repositorio debian microsoft-debian-stretch-prod)?

En cuanto al problema original de este error, se ha solucionado (ya no recibe ningún error), solo tenga en cuenta que SecureString está internamente en texto sin formato.

¿Alguien tiene un enlace a la solución o sabe en qué versión de lanzamiento estará disponible? Sigo recibiendo errores crypt32.dll en powershell_6.1.3-1.ubuntu.16.04_amd64.deb (mismo trato con el paquete de vista previa 6.2.0-rc.1).

También tengo curiosidad por saber cómo afecta esta solución a Import / Export-CliXml cuando los datos que se van a serializar contienen objetos SecureString o PSCredential.

@rmbolger ¿Podría consultar con la última versión (6.2.0-RC)?

Veo lo mismo que @rmbolger

/home/hillr
03-20 23:44:55 31ms 11> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.2.0-rc.1
PSEdition                      Core
GitCommitId                    6.2.0-rc.1
OS                             Linux 4.4.0-17763-Microsoft #379-Microsoft Wed Mar 06 19:16:00 PST 2019
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

/home/hillr
03-21 00:47:45 35ms 12> ConvertFrom-SecureString -SecureString $ss
ConvertFrom-SecureString : Unable to load shared library 'CRYPT32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libCRYPT32.dll: cannot open shared object file: No such file or directory
At line:1 char:1
+ ConvertFrom-SecureString -SecureString $ss
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [ConvertFrom-SecureString], DllNotFoundException
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.ConvertFromSecureStringCommand

Los cmdlets cargan directamente CRYPT32.dll
https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/Microsoft.PowerShell.Security/security/SecureStringCommands.cs#L169

https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/System.Management.Automation/security/SecureStringHelper.cs#L158

https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/System.Management.Automation/security/SecureStringHelper.cs#L449

https://github.com/PowerShell/PowerShell/blob/8763c0b1d11ce3ee8639e9386383f158976490e0/src/System.Management.Automation/security/SecureStringHelper.cs#L590