Apache XML Security 1.5.0 released

Apache Santuario 1.5.0 has been released. As the release notes point out, this release is not binary compatible with Santuario 1.4 any more.

There are some really good updates included, of which I like that Xalan/Xerces are not required dependencies any more the most. Under the covers, support for Java 1.4 was dropped, and generics are used where possible.

The binary incompatibility will require some changes and tests until this version will be available with the JCrypTool XML Security plug-in.

Java security updates – January 2012

The Oracle Secure Coding Guidelines for the Java Programming Language are available in version 4.0 (probably already for a couple of days, couldn’t find any announcement). This version includes some hints for the latest Java 7 SDK.

And John Melton announced the Year of security for Java with weekly (at least it looks like weekly posts at the moment) posts on possible Java security problems and pitfalls. The first two posts talk on session fixation prevention and error handling in web.xml are already published.

EGit 1.1 pushes only the active branch by default

As it turns out, there is already a fix in EGit 1.1 for the unexpected EGit behavior I described here and here.

The new default for EGit 1.1 is to only push the active branch via Push to Upstream in case there is no explicit default spec. More is not possible at the moment due to some JGit protocol limitations. I can totally live with that, at least there are no surprises with local branches appearing in the remote repository silently any more.

EGit pushes all local branches when no explicit RefSpec is found – Update

As it turns out, some parts of yesterdays' post are not correct: The description of the behavior I expect was OK, but EGit behavior is not correct at all. Have a close look at the Git push spec and the sentence in bold:

The special refspec : (or +: to allow non-fast-forward updates) directs git to push “matching” branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found (that is neither on the command line nor in any Push line of the corresponding remotes file—see below).

And EGit does the exact opposite of that! Every local branch is pushed, no matter it exists in the remote repository or not. Thanks to Carsten Reckord, who pointed that out in my post in the Eclipse Community Forums. I'm waiting on another reply to my post, after that I'll file a bug.

EGit pushes all local branches when no explicit RefSpec is found

Cloning a Git repository with EGit 1.0 and no further configuration causes some unexpected behavior. The moment you clone a repository, say from GitHub, everything is set up for you, and you are ready to push and pull. And since you fully adopted the Git workflow, you do create a new branch for every bug fix or new feature you are implementing. And you expect those branches to be local only. The problem with EGit is, they aren‘t. Instead, without further configuration, all branches are shared (pushed) by default.

As the Git push spec points out (refspec in options), this is correct:

The special refspec : (or +: to allow non-fast-forward updates) directs git to push “matching” branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found (that is neither on the command line nor in any Push line of the corresponding remotes file—see below).

But on the command line, e.g. with msysGit or on OS X, this is different. No branch is pushed by default, you have to explicitly do this. This behavior seems more useful, since most branches are not of any interest to other developers.

To avoid this strange behavior in Eclipse, every(!) developer with push rights to this Git repository has to update his local RefSpec: Select Team – Remote – Configure Push to Upstream… You can see the setting causing the problem at the bottom right away (section RefSpec): All branches will be pushed using Push Spec “refs/head/*:refs/heads/*”

Expand the Advanced section and click on the Edit button. A new dialog opens. Check the source ref combo and select the master [branch] entry. This automatically updates the destination ref. Keep this entry and click the Add spec button, Finish and then Save in the other dialog. That‘s it. From now on, only the master branch is pushed to the remote repository. In case you want to push another branch, you do have to configure it as described above too. Remember to do this for every Git repository in every workspace.

That‘s it. Unfortunately, every developer has to do this. In my eyes, this is way to complicated. The settings described here should be the default. Developers want to develop, and not to configure the same things all the time again and again. And since push and pull are enabled directly after cloning, everything seems ready.

Because of that, I have started a post in the Eclipse Community Forums. In my eyes this qualifies as a change request. As a compromise it should be possible to implement some choice in the Eclipse preferences which updates the repository parameter push.default (seems to be ignored at the moment).

My session at the Java Forum Stuttgart

My session for the upcoming Java Forum Stuttgart, Push up your code – next generation version control with (E)Git, was accepted! May session takes place at 12:15 p.m. (D4). As you can probably guess, it is about Git, especially about the Eclipse version EGit. The slides are in English, but I'll be speaking German.

See you here in Stuttgart on July 7th, 2011! And don't forget to visit us at the Trivadis booth in the exhibition area!

Eye on EclipseCon 2009

EclipseCon 2009 is over, and it has been great! A lot of things to learn, and even more people to meet. This was my first EclipseCon, and it couldn't have been any better!

Monday started with some great tutorials: Building Commercial-Quality Eclipse Plug-ins in the morning and Advanced Eclipse Rich Client Platform in the afternoon. I'm developing Eclipse plug-ins for about five years now, but still discovered some new stuff (and got some ideas about getting P2 working). Since JCrypTool didn't make it to the open source RCP finals, there was no tension for me while attending the Eclipse Community Awards (Apache Directory Studio totally deserved the first place). The PowerPoint karaoke was a lot of fun!

The following days always contained a good mixture of interesting sessions, from e4 over PDE to the Web Tools Platform and various other talks (I'm not going into detail here). And of course some excellent keynotes, of which I enjoyed The Darwin among the IDEs on Thursday the most. Hopefully we will see some of the ideas announced here in the future. Although I have to admit that I am not a fan of developing everything in the browser. The moment one tab crashes all your browser data is gone. Maybe this will change as well as soon as all tabs are using their own processes. But how will two or more browser instances, each with 250 MB, 500 MB or even more memory usage (remember, we are talking about a complete IDE in the browser), affect the system or even work?

Our Web Tools Platform Incubator session took place on Wednesday at 10:10 am. We ended up in the Grand Ballroom B. 31 people attended (thanks to RFID tracking (hopefully not my passport)). I expected some more, but OK, two brand new incubator projects, the community has still to grow around them. The slides from my session Incubating XML Security Tools are available for download on my home page and of course at gPublication (the conversion killed some of the slides, so better use the one on my home page).

As the statistics show, a little more than 1000 people attended EclipseCon this year. I met the people I intended to meet, and many, many more. And I collected some interesting ideas for XML Security Tools enhancements, which I will look at in detail in the next weeks. So stay tuned.

A whole bunch of new XML Security working drafts

The W3C XML Security Working Group has released eight first public working drafts last week, from updated XML Encryption 1.1 and XML Signature 1.1 specifications to even some new ones. Among others, these drafts include revisions to XML Signature and XML Encryption to support new algorithms and a new document proposing simplifications to the XML Signature Transform model to enhance performance and security.

XML Signature Best Practices experienced some updates to match the latest recommendations. XML Security Derived Keys, XML Signature Properties, XML Security Algorithm Cross-Reference and XML Security Use Cases and Requirements are completely new specifications.

XML Signature Syntax and Processing Version 1.1
This version mostly replaces more or less unsafe algorithms like SHA-1 with SHA-256 or higher (well, SHA-1 is not replaced, it is still a required algorithm, but SHA-256 is required too). Additionally elliptic curve cryptography has arrived in the recommendations in form of the ECPublicKey element and of course the matching algorithms. And we are confronted with a new digital signature namespace http://www.w3.org/2009/xmldsig11#. Check out the diff-marked version for all changes.

XML Encryption Syntax and Processing Version 1.1
Some updates on required and recommended algorithms too. Elliptic Curve Diffie-Hellman is now a required Key Agreement algorithm. Not too many changes here; and I couldn’t find a diff-marked version.

XML Security Derived Keys
This completely new specification defines a derived key XML type and associated elements, both used in XML Signature and XML Encryption.

XML Signature Properties
Signature properties are nothing new. Up to now it is possible to define any signature property one desires. This is still possible in the future, but this new recommendation will define some commonly used ones. Four properties are defined so far: Profile, Role, Expires and ReplayProtect. I guess we will see some more in the final recommendation…

XML Security Algorithm Cross-Reference
Another new document. And a really, really good idea! This reference contains all algorithms and their corresponding URI used in all XML Security recommendations. Bookmark this page, and never use an incorrect URI again!

XML Signature Best Practices
A collection of best practices, mostly security related, for implementers and users of the XML Signature recommendations. Not everything will be useful in every environment, but clearly this document points into the right direction of making a complex recommendation more practical in the daily usage.

XML Security Use Cases and Requirements
This document summarizes use cases and requirements driving revisions to XML Signature, XML Encryption and XML Canonicalization. Not that interesting for XML Security users.

XML Signature Transform Simplification: Requirements and Design
I like the idea behind this document. Basically it recommends replacing the current reference processing model with a simpler one. And simplicity is always good for security (and for performance). What may(!) happen is an extended Reference element with Selection, Transform and Canonicalization child elements. The Selection element chooses what is to be signed. The Transform element makes sure that you only sign what you see (it has a limited number of transformations that for). And finally the Canonicalization element is used to produce the input for the hash. So the reference processing may change a little bit in the future.

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.