Eclipse Product Configurations

An Eclipse Product Configuration (stored in a *.product file) makes RCP branding easy and offers an easy way to create a run menu entry for the RCP by simply clicking on the “Launch an Eclipse application” link. This even updates the run menu entry. But lately we ran into a, in my eyes, huge disadvantage: the product configuration stores the version number for every feature. Even worse, this version is not visible in the product configuration editor. Since the product file is an XML file you can easily open it in a text or XML editor. Have a look at the features element and its child elements feature. You will see a version attribute.

I’m unhappy with two things here: a) this version number is not visible in the product configuration editor itself. And b) there is no way to update it. The only solution is to remove the corresponding feature and to add it again. Forgetting this leads to a defect product configuration: the run menu doesn’t contain the features plug-ins any more and they are missing after exporting the RCP. It was a lot of work to track this error down to updated feature version numbers…

Btw, as you have probably noticed, I’m writing in English now. Since I’m working in an official Eclipse project and from time to time those guys want to know what I’m writing about, I have decided to change my blogs language to English.

Eclipse Product Configurations auf Twitter teilen
Eclipse Product Configurations flattrn
Eclipse Product Configurations auf Digg teilen
Eclipse Product Configurations auf Delicious teilen
Eclipse Product Configurations auf Xing teilen
Eclipse Product Configurations auf LinkedIn teilen
Eclipse Product Configurations auf Pinterest teilen
Eclipse Product Configurations auf StumbleUpon teilen
Eclipse Product Configurations auf Tumblr. teilen
Eclipse Product Configurations auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

XML Security Tools Update

Seit einigen Wochen ist ja mein XML-Security Plug-In in Form der XML Security Tools im Eclipse Web Tools Platform Incubator gelandet. Die Arbeit geht voran, unter http://www.eclipse.org/webtools/incubator finden sich jetzt auch Hinweise auf das neue Projekt. Das werde ich in den nächsten Tagen noch ausbauen.

Ich hoffe im Laufe der nächsten Woche den Build Process an den Start zu bringen und die aktuelle Version zum Download anbieten zu können. Es gibt noch einiges zu tun: Neben dem Refactoring (sauber Trennung Business Logic und GUI, was ein eigenes UI Plug-in bedeutet) stehen auch Extensions/ Extension Points an (nicht zuletzt durch die Trennung von Logic und UI) und natürlich Tests… Also doch noch einiges an Arbeit, nichtsdestoweniger ist es mal wieder Zeit für ein neues Release, 1.6.1 liegt schon 2 Jahre zurück.

XML Security Tools Update auf Twitter teilen
XML Security Tools Update flattrn
XML Security Tools Update auf Digg teilen
XML Security Tools Update auf Delicious teilen
XML Security Tools Update auf Xing teilen
XML Security Tools Update auf LinkedIn teilen
XML Security Tools Update auf Pinterest teilen
XML Security Tools Update auf StumbleUpon teilen
XML Security Tools Update auf Tumblr. teilen
XML Security Tools Update auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Best Practices für XML Signatures

Das W3C hat vor einigen Tagen unter http://www.w3.org/TR/2008/WD-xmldsig-bestpractices-20081114/ eine Sammlung von 16 Best Practices für die digitalen Signaturen mit XML veröffentlicht. Noch ist es ein Working Draft (d.h. Kommentare sind bei der Working Group willkommen), aber ein erster Blick darauf kann keinem schaden, der mit XML Signatures zu tun hat.

Generell geht es mit den Best Practices darum, die Anzahl möglicher Attacken auf XML Signaturen zu reduzieren und somit natürlich die Sicherheit zu erhöhen. Grob vereinfacht, weniger Komplexität, mehr Sicherheit. Und da sticht Best Practice 3 besonders hervor:

Consider avoiding XSLT Transforms

Genau so wie Nummer 4:

Try to avoid or limit XPath transforms

Allein mit den beiden schon seit längerem bekannten Tipps hat man bereits viel gewonnen und eine große Menge Komplexität entfernt. Dass entspricht genau dem Wunsch vieler, die XML Sicherheit modular aufzubauen und in den Implementierungen nur die Features anzubieten, die man wirklich benötigt.

Best Practice 11 finde ich dagegen wenig hilfreich:

Unless impractical, sign all parts of the document.

OK, es gibt die Einschränkung Unless impractical, aber ein gigantischer Vorteil der XML Sicherheit (ob Signatur oder Verschlüsselung) ist es ja wohl, dass man gezielt einzelne Dokumentfragmente sichern kann. Wenn ich immer alles signiere bin ich, bis auf die XML Syntax, wieder zurück bei den herkömmlichen Signaturvarianten, und davon will ich mit der XML Sicherheit ja eigentlich weg. Für mich ein unbrauchbarer Tipp.

Nichtsdestoweniger lohnt es sich, das Dokument zu lesen und möglichst viele der Best Practices (sofern sie denn passen) in eigenen Implementierungen zu verwenden.

Best Practices für XML Signatures auf Twitter teilen
Best Practices für XML Signatures flattrn
Best Practices für XML Signatures auf Digg teilen
Best Practices für XML Signatures auf Delicious teilen
Best Practices für XML Signatures auf Xing teilen
Best Practices für XML Signatures auf LinkedIn teilen
Best Practices für XML Signatures auf Pinterest teilen
Best Practices für XML Signatures auf StumbleUpon teilen
Best Practices für XML Signatures auf Tumblr. teilen
Best Practices für XML Signatures auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren