Also bei DLLS willst Du wissen "Stammt diese DLL mit der Version 2 wirklich von Herausgeber X"

Was aber dann doch voraussetzt, dass "Herausgeber X" nicht einfach per "SN -k"ein unprüfbares Schlüsselpaar mit einem nicht verifizierbarem Public Key generiert. Oder prüft diese B2B Anwendung die Authentizität der Plugins anhand des Thumbprints oder anderer Daten im öffentlichen Schlüssel?

Stecke nicht zu viel Zeit in die Antwort. Das ist nur interessehalber. Vor so einer Herausforderung stehe ich momentan nicht und das Grundproblem ist gelöst.

Danke schonmal an euch beide ....

Gruß
Jens

Hi,

danke.

Ich habe dieses selbst erstellte StringNaming Schlüsselpaar (sn.exe -k) nicht erstellt, weil ich befürchtet habe, dass die selbstsignierten Schlüssel für Zertifikatswarnungen sorgen. Deshalb habe ich den Ansatz verfolgt einen verifizierbaren Public Key zu verwenden.

Aber nun wird das ganze Thema schon klarer. Wenn das StrongNaming "nur" dafür da ist, um den Hash Wert der Assembly asymmetrisch zu verschlüsseln, um damit die Integrität der Assembly sicherzustellen, dann kann das Code Signing Zertifikat dafür nicht funktionieren. Das ist ja kein x509 Zertifikat.
Nun wird mir auch klar, warum man für das StrongNaming keinen TimeStamp Server angeben muss. 😉

Was ist denn jetzt ratsamer für das StrongNaming? Einfach ein Schlüsselpaar per SN.exe generieren oder ein Schlüsselpaar aus einem verifizierbaren x509 Zertifikat zu extrahieren? Wird die Authentizität des StrongNaming Public-Keys eigentlich jemals irgendwo geprüft?

Gruß
Jens

Seit einer Woche kämpfe ich mit dem CodeSigning und hangle mich von einer schlechten Doku zur Nächsten.

Bisher habe ich meine Assemblies per Post-Build Event und Signtool signiert. Das hat immer gut funktioniert. Nun habe gelernt, dass man den Programm-Code (exe,dlls) eher per SNK signieren sollte und das signtool eher für Setups und Ähnliches gedacht ist.

Ich nutze ein CodeSigning Zertifikat von StartCom. Bis gestern habe ich alle unten beschriebenen Varianten mit meinem alten (noch gültigen) SHA1 Zertifikat durchgespielt. Heute früh wurde das SHA256 Zertifikat von denen validiert. Also heute die ganzen Tests noch einmal mit dem neuen Zertifikat. Leider genauso erfolglos ...

Was bisher geschah: 😁

Test ClickOnce Signierung ...*Der originale PKSC12 Container (pfx) von StartCom wurde von Visual Studio 2012/2015 nicht für ClickOnce nicht anerkannt. Weder aus dem Zertifikatsspeicher noch aus der PFX Datei. Vermutlich liegt das an den Intermediate Zertifikaten oder an dem Verschlüsselungsverfahren für den privaten Schlüssel.

Nach einer Weile googeln und langen Experimenten habe ich dafür eine funktionierende Lösung:
1. originales Codesigning Zertifikat (PFX) nehmen und Key extrahieren:
openssl pkcs12 -in StartSSL_Codesigning.pfx -nocerts -out StartSSL_ClickOnce.key

2. extrahierten Key in RSA Key umwandeln:
openssl rsa -in StartSSL_ClickOnce.key -out StartSSL_ClickOnce_RSA.key

3. Codesigning Zertifikat (PFX) nehmen und Zertifikat extrahieren:
openssl pkcs12 -in StartSSL_Codesigning.pfx -clcerts -nokeys -out StartSSL_JWa_ClickOnce.crt

4. aus dem extrahierten RSA Key und dem extrahierten Zertifikat wieder ein PFX bauen:
openssl.exe pkcs12 -export -inkey StartSSL_ClickOnce_RSA.key -in StartSSL_ClickOnce.crt -out StartSSL_ClickOnce.pfx

Der neu erstellte PKSC12 Container "StartSSL_ClickOnce.pfx" signiert sorgenfrei ClickOnce Manifeste (per Datei und aus dem Zertifikatsspeicher) und funktioniert weiterhin mit SignTool.

SNK will leider nicht klappen.
Folgendes habe ich getestet:

*das originale StartCom PFX in den Projekteigenschaften > Signierung hinzufügen
-> bringt Fehler "ungültiger Anbieter" beim Build

*mein reassembliertes StartCom ClickOnce PFX (s. oben) in den Projekteigenschaften > Signierung hinzufügen
-> bringt Fehler "Die folgende Schlüsseldatei kann nicht importiert werden: Codesigning-SHA2-ClickOnce.pfx. Die Schlüsseldatei ist möglicherweise kennwortgeschützt. Importieren Sie das Zertifikat erneut, oder Installieren Sie das Zertifikat mit dem folgenden Schlüsselcontainernamen im CSP mit starkem Namen, um das Problem zu beheben: VS_KEY_372D5F1CA717D1A3

*SN -P OriginalStartCom.pfx StrongNaming.SNK SHA256
-> SN exportiert nichts, Fehler "unbekannter Anbieter"

*SN -P MyCodesigning-ClickOnce.pfx StringNaming.SNK SHA256
-> SN schreibt eine SNK Datei, die dummerweise nur den Public Key enthält
-> Build bricht ab, Fehler "Fehler beim Signieren der Ausgabe mit einem öffentlichen Schlüssel aus der Datei "StrongNaming.snk": Der Wert liegt außerhalb des erwarteten Bereichs."
-> Build mit verzögertem Signing bricht ebenfalls ab. Also eher ein Public Key Problem in der SNK Datei

*SN -i OriginalStartCom.pfx StrongNamingContainer
-> SN importiert das Schlüsselpaar nicht in den Container. Ungültiger Anbieter.

*SN -i MyStartCom_ClickOnce.pfx StrongNamingContainer
-> AssemblyKeyName Attribut "StrongNamingContainer" gesetzt
-> Build Fehler: Fehler beim Signieren der Ausgabe mit einem öffentlichen Schlüssel aus dem Container "StrongNamingContainer": Der Schlüssel ist nicht vorhanden. (Ausnahme von HRESULT: 0x8009000D)

*SN -d StrongNamingContainer (wieder entfernt)

*SN -i MyStartCom_ClickOnce.pfx VS_KEY_372D5F1CA717D1A3
(Test dieses Containernamens wegen der Fehlermeldung oben ...)
-> AssemblyKeyName Attribut "VS_KEY_372D5F1CA717D1A3" gesetzt
-> Build Fehler: Fehler beim Signieren der Ausgabe mit einem öffentlichen Schlüssel aus dem Container "VS_KEY_372D5F1CA717D1A3": Der Schlüssel ist nicht vorhanden. (Ausnahme

*Download und Build des PFX2SNK Projektes
https://github.com/aarnott/pfx2Snk

-> soll eine SNK Datei erstellen, die Private- und PublicKey enthält
-> Test mit der originalen StartCom PFX - Pfx2Snk.exe wirft beim Lesen der PFX eine Exception
-> Test mit der meiner StartCom ClickOnce PFX - Pfx2Snk.exe läuft durch und schreibt eine SNK Datei

*Test dieser Pfx2Snk erstellten SNK Datei
-> Build bricht ab mit der Meldung "keinen öffentlichen Schlüssel in der SNK gefunden"

*mit OpenSSL einen RSA Public-Key aus meiner PFX extrahiert und mein ClickOnce.PFX neu assembliert mit dem RSA Private Key und dem RSA Public Key
-> alle Schritte von oben (ab "SNK will leider nicht klappen.") mit dem neuen ClickOnce_RSA.PFX wiederholt -> unveränderte Ergebnisse ...

***heute von A-Z alles wiederholt mit dem neuen StartCom SHA256 CodeSigning Zertifiakt ... **
-> unveränderte Ergebnisse ...

Also, ich habe echt viel gelesen und echt viel probiert, aber dieses SNK CodeSigning ist echt mager dokumentiert oder ich bin einfach nur kein echter Zertifikats-Ninja.

Offenbar haben SN.exe und/oder Visual Studio Probleme damit, den Public Key zu lesen bzw. zu verwenden.

Wie muss der Public-Key aufgebaut sein, damit er funktioniert?
Welche Chipher und welche Digests werden unterstützt?
Warum so kompliziert und keine ordentlichen Fehlermeldungen?
Base64 oder Binärformat?

Wer kann helfen?
Gerne mit StartSSL CodeSigning Erfahrung.
Ich will eine automatische Signierung aller Assemblies per SNK während des normalen Builds in Visual Studio. Wenn möglich ohne manuelles Bearbeiten aller Projektdateien ...

Grüße
Jens

OK, danke.
NewtonSoft.Json schaue ich mir genauer an.

Ich taste mich gerade an meinen ersten REST Client heran und bin mir nicht sicher, ob ich die Klassen für die Deserialisierung richtig aufbaue.

Hier mal ein ganz übersichtliches Beispiel.

                
{
      "success":true,
      "messages":[],
      "results":{
              "balance":"295.23000"
      }
} 

Meine manuell erstellten Klassen nach MSDN Doku:

        [DataContract]
        public class Balance
        {
            /* JSON Response
                {
                   "success":true,
                   "messages":[],
                   "results":{
                      "balance":"295.23000"
                   }
                }            
            */
            [DataMember(Name = "success")]
            public Boolean Succcess { get; set; }
            [DataMember(Name = "messages", IsRequired = false)]
            public String[] Messages { get; set; }
            [DataMember(Name = "results")]
            public BalanceResults Results { get; set; }
        }

        [DataContract]
        public class BalanceResults
        {
            [DataMember(Name = "balance")]
            public decimal Balance { get; set; }

        }

Sind die DataContract und DataMember Attribute auf dem Unterobjekt "BalanceResults" für eine erfolgreiche Deserialisierung nötig? Dafür habe ich nicht die richtige MSDN Seite gefunden.

JSON2SHARP lässt die Attribute komplett weg und generiert mir diese Klassen:

public class Results
{
    public string balance { get; set; }
}

public class RootObject
{
    public bool success { get; set; }
    public List<object> messages { get; set; }
    public Results results { get; set; }
} 

Allerdings möchte ich es lieber verstehen anstatt Copy&Pasten.
Was ist richtiger, üblicher oder besser? Kann bitte jemand 1-2 erklärende Worte dazu schreiben?

Die dort beschrieben Registry Einträge setzt das aktuelle Setup inzwischen selbst. Das manuelle Bearbeiten und Importieren der passenden Reg Datei ist zum Glück nicht mehr nötig.

Der Kommentar mit dem "Firebird EF-6" Testprojekt hat mich aber vermutlich auf die richtige Lösung gebracht. Das Projekt lief bei mir nicht und warf aussagekräftige Exceptions.

Das DDEX Provider Setup fügt beim "Installieren" und "Reparieren" immer einen Firebird Provider Eintrag in der machine.config unter "system.data\DbProviderFactories" hinzu, ungeachtet dessen, ob dieser bereits existiert. Die Deinstallation bereinigt die machine.config nicht wieder.

Der "invariant" Name aller Provider unter <DbProviderFactories> muss eindeutig sein. Durch den Setup Bug war er das nicht mehr.
Ich habe die Setups im Laufe des Fehlersuche oft durchlaufen lassen. 😮)

Nach der manuellen Bereinigung konnte ich im Server-Explorer neue Verbindungen konfigurieren. Designtime läuft. Runtime teste ich morgen.

Danke

Was bedeutet das das nicht geht.
Wozu meinst du den überhaupt brauchen zu müssen?

Naja, gehen muss es schon. Es handelt sich um aktuelle und offizielle ADO.Net Treiber und DDEX Provider von der Firebird Foundation.
Ohne passende Visual Studio DDEX (Data Designer Extension) ist das Arbeiten mit komplexen Datenbanken äußerst unproduktiv und fehleranfällig. Eben alles Handarbeit anstatt Designer. Das Entity Framework braucht den DDEX ebenfalls.

Keine Ahnung warum der FB DDEX Provider genau bei mir ein Problem hat (und womit 🤔 ). Auch blöd, dass die Firebird Leute kein Interesse haben sich mit Einzelschicksalen zu befassen. Aber sicher bin ich nicht der Einzige der aus VS heraus mit Firebird arbeiten muss. Ergo wird der Provider anderswo grundsätzlich laufen.

Probiere vielleicht mal die NuGet Packete zu Installieren und per Quellcode eine Verbindung aufzubauen.

Das läuft ausschließlich über den ADO.Net Treiber und funktioniert problemlos.

Ich bekomme den Firebird DDEX Provider bei mir nicht zum Laufen.
Der Firebird ADO.Net Treiber ist installiert und der DDEX Provider taucht in Server-Explorer > Datenberbindungen > neue Datenverbindung" als Datenquelle auf.
In dem Firebird Verbindungsdialog, der dort erscheint, kann ich nichts eingeben. Der Dialog wird beim ersten Klick oder Tastendruck geschlossen.

Vor 3 Wochen hatte ich schon eine Anfrage in Stackoverflow gestartet. Dort gab es bisher noch keine zielführenden Hinweise.

Die Registrierungen in der "machine.config" und im GAC sind meiner Meinung nach richtig. (Bitte schaut wegen dieser Details in den Stackoverflow Link.)
Aus dem Firebird Bugtracker wurde meine Anfrage sofort wieder von den Entwicklern gelöscht. Es kam nur der platte Kommentar "This is not a Forum.".
Ohne Frage arbeite ich lieber mit MS-SQL, aber die Firebird Anbindung muss ich trotzdem recht zeitnah für ein Kundenprojekt zum Laufen bekommen.

Kennt sich hier jemand damit aus? Es gibt leider keine offizielle Doku dafür, keinen Support von den FB Entwicklern und keine Fehlermeldungen an Hand derer ich mir selbst helfen könnte.

Grüße
Jens

Ich programmiere seit fast 2 Jahren mit RemObjects Oxygene für iOS. Statt Xamarin würde ich mir eher wünschen, dass Microsoft eine Integration von "RemObjects C#" ins Auge fasst.
Der Vorteil bei denen ist, dass RO C# direkt auf die Android, JAVA, iOS und OSX SDKs aufsetzt und keine wilden, schwerlastigen Wrapper zwischen der App und der Plattform hängen.
Zudem ist der RO C# Compiler unbeschreiblich flexibel. Die RemObjects Jungs greifen sich die besten Sprachfeatures aus allen Plattformen und bauen für alle anderen Plattformen nach. Dabei heraus kommen dann Dinge wie Linq und Generics für iOS, Multi-part Methodnames für C# und Java, Properties und Delegates für Java uvm. Im Hintergrund arbeitet der Code 1:1 auf den nativen SDKs (auf Windows natürlich .Net und nicht Win API).
Ich mag dieses Konzept lieber als Xamarin. Es macht echt Spaß damit zu arbeiten. Es war für mich, als alt eingesessener Delphi Entwickler ein riesiger Schritt, aber inzwischen fange keine neuen Sachen mehr an, die nicht in C# geschrieben sind, egal für welche Plattform auch immer ...