Categories
JCrypTool

New CrypTool Portal available

The new CrypTool Portal is online! This portal unifies all CrypTool projects – CrypTool 1, CrypTool 2, JCrypTool, CrypTool online and Mystery Twister C3 – in a single place. Visit it today, and don't forget the new JCrypTool pages in English and German.

Be aware that our former weekly builds download page cannot be accessed directly any more. You'll find all our downloads in the new portal, available on a German and an English page (both weekly and stable).

Categories
Java

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.

Categories
XML Encryption XML Security

XML Security Working Group announced last calls for XML Encryption working drafts

The XML Security working group published the last calls for two XML Encryption working drafts: XML Encryption 1.1 contains, besides some other updates, AES-128-GCM, a new mandatory algorithm to implement which addresses the lately published security problems (catastrophe?!) with XML Encryption. This part alone justifies a closer look at the candidate recommendation.

The other last call is about XML Encryption 1.1 CipherReference Processing using 2.0 Transforms. This recommendation makes the usage of CipherReference transform processing easier with XML Encryption (as defined in the XML Security 2.0 spec).

Besides that, test cases for XML Encryption 1.1 and Canonical XML 2.0 have been updated as well. And of course the XML Security Algorithm Cross-Reference which reflects the latest changes to the XML Encryption recommendation.

Categories
JCrypTool

JCrypTool Release Candidate 6 planning started

Release planning for our final JCrypTool release candidate, the magic number is 6, has started. This release is already scheduled for March 2012 and will complete (hopefully) all features, fix all open bugs and finalize the documentation (the most important part). So please keep on testing our current release candidate 5 and report bugs and missing documentation: simply file a bug in our core or crypto issue tracker on GitHub. Or, in case you are up to it and you want to join the JCrypTool development team, provide a patch for a bug…

Categories
JCrypTool

JCrypTool Release Candidate 5 available

JCrypTool Release Candidate 5 is available for download! This release contains the new crypto plug-ins DES, Homomorphic Encryption and Viterbi. Plus many bugfixes, some smaller new features and improvements. Have a look at our wiki for detailled release information.

Since the new crypto portal is not ready yet, the download is a little bit complicated at the moment: You can either download the files from our old SourceForge project page our use the temporary download directory. For the first time, installers for Windows (x86 and X86-64) are available too. The update site works as before (use the integrated update manager).

Categories
JCrypTool XML Encryption XML Security XML Security Tools XML Signature

Apache Santuario 1.4.6 available

A new maintenance release (1.4.6) of Apache Santuario, the Apache XML Security project, is available. The release notes are a little bit confusing. Looks like five bugs were fixed. The new version will be available in the next JCrypTool release.

Categories
XML Encryption XML Security

Unsafe XML Encryption?!

This analysis (in German, English version is available here) by the well-known Ruhr University Bochum puts XML Encryption into some real trouble. Since there is no solution or workaround, the only possibility is to accept the drawbacks and to use SSL to secure any Web Service communication. Back to good old transportation based security.

Categories
XML Security Tools

XML Security Tools in danger

Yes, the XML Security Tools are really in danger. Those of you following the improvement of the project didn‘t see much lately. Not that I'm not interested in Eclipse or XML Security any more. But my free time is very limited and I desperately need a co-developer supporting me and the project.

As a first step, I have integrated the XML Security Tools into JCrypTool, and moved the adapted code into our Crypto GitHub repository. The XML Security Tools are located in the org.jcryptool.crypto.xml projects there. This code differs from the code at eclipse.org to match the JCrypTool requirements and extension points. Integration is by far not complete, and the code needs some love – feel free to contact me and join the JCrypTool project.

On Eclipse side, Dave Carver will be separating the XML Security Tools code into a separate Git repository. If no one steps up, the code will be archived there.

Categories
Eclipse Java

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.

Categories
Eclipse Java

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.