TL;DR A component licensed under LGPL can be used by closed source, proprietary software, both internally used and distributed, for free, with no effects on the software using the component. LGPL is not “contagious” in the same way as GPL, so it only affects the component under LGPL. As long as you’re only using official distributions of the component, it is free to use and free to redistribute. The only requirement is that you include a notice in your “about” page or similar that the component is used.
I often get questions about the LGPL license used for Kentor.AuthServices. I also often find it confused with GPL, which is something you should never, ever even consider to use in any closed source software that you intend to distribute. So this post is an effort to explain and answer common questions about the LGPL. Unfortunately I have to add the disclaimer: I’m not a lawyer and the content of this post is only meant as an overview and introduction to the license. I might have got things wrong, so please read the real license yourself and involve appropriate legal counsel to be sure.
Static Analysis has interested me for nearly as long as I’ve been coding, so when I was offered to try out NDepend I got really excited. I already rely on the warnings the compiler can give and code analysis rules for my projects and a tool such as NDepend seems like the next logical step. I was not disappointed.
I think that the code analysis rules offered by Visual Studio are powerful and helps improve code quality, but they have a user experience that’s more punishing than encouraging. Code Analysis rules are evaluated after the code is written and after it has passed the compilation – which means when you are sort of done. Then it comes and tells you that you’re not done. That’s demoralising. There’s also no hint of how many rules you did in fact dit pass. The NDepend analysis is different. It is run from the NDepend Dashboard and it shows not just rules violations, but it can also show that your code is good.
With Coveralls.IO it’s possible to get code coverage on all pull requests submitted. For Kentor.AuthServices I’ve set up AppVeyor builds that uses Coveralls.Net to upload coverage numbers to Coveralls.IO.
When I set up the code coverage I already had AppVeyor builds running. I wanted something that worked together with AppVeyor. I tried out a few options and quickly found out that I also wanted something that used the Visual Studio Code Coverage engine. The project had 100.00% coverage in Visual Studio when I started and when I tried another coverage engine it showed some lines as skipped. I wanted consistency with the Visual Studio Code Coverage, which coveralls could give me.
Earlier this month, Microsoft released MS16-035 that addresses issues I previously reported in SignedXml. They did not only fix the duplicate Id vulnerability I reported though, they also fixed a number of other issues – introducing some breaking changes. This post is an effort to document those and changes and the registry switches that can be used to revert back to the old behaviour.
These are the breaking changes I know about. If you know of any more issues, please leave a comment or drop a mail and I’ll try to update the post.
- Duplicate Ids for reference elements no longer allowed (applies to both
- Id values must be a well formed NCName (which is required by the XML standard, applies to both
- External references disabled by default
- XPath Transform disabled by default
- XSLT Transform disabled by default
.NET’s SignedXML class
has had a risky implementation for lookup of XML elements by id in
GetIdElement() when resolving signed xml references. The lookup validated only the first element if there are several with the same id. This opens up for XML Signature Wrapping attacks in any library that is using the default implementation without taking necessary precautions. For SAML2 libraries signature wrapping is a well known attack class with very severe implications.
I reported this privately to Microsoft on December 3rd 2015. They responded (as promised within 24 hours) that they would investigate. The vulnerability was assigned ids CVE-2016-0132 and MS16-035. A fix was released on “patch Tuesday” in March 2016 (and yes, I’m proud to be listed in the acknowledgement section). The fix also contains a number of related breaking changes.
This is an example of a signed XML document with data that might be incorrectly trusted.
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<data>Some false data</data>
The document demonstrates how two elements have the same id. The unpatched
SignedXml.GetIdElement() method will only find and validate the first occurrence of the id, but code that loops all nodes and checks that the id is present in the signature’s references will trust both