Renaming Kentor.AuthServices Nuget packages to Sustainsys.Saml2

Last year I left Kentor for new adventures as an independent consultant. I got the Kentor.AuthServices project with me, but of course need to rename it as it is not associated with Kentor any more. So how does one rename a library and nuget packges with 100k+ downloads and users all over the world? Simply releasing new versions under the new Sustainsys.Saml2 name will leave a lot of users stale on the last version with the old name. So what I did was to release dummy packages that kicks off the migration process.

The last release with functionality in the Kentor.AuthServices name was 0.22.0. I then did a huge renaming operation and published new packages named Sustainsys.Saml2 with version 0.23. Finally I published dummy Kentor.AuthServices 0.23 packages that brings in the Sustainsys.Saml2 0.23 packages and shows a readme with migration instructions.

The LGPL License

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 with NDepend

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.

Code Coverage on GitHub PRs with Coveralls.IO

2016-06-05 18_01_53-KentorIT_authservices _ Coveralls - Test Coverage History & StatisticsWith 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.

Why 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.

Breaking Changes to SignedXml in MS16-035

xml-ms16-035Earlier 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.

  1. Duplicate Ids for reference elements no longer allowed (applies to both SignedXml and EncryptedXml)
  2. Id values must be a well formed NCName (which is required by the XML standard, applies to both SignedXml and EncryptedXml)
  3. External references disabled by default
  4. XPath Transform disabled by default
  5. XSLT Transform disabled by default
Software Development is a Job – Coding is a Passion

I'm Anders Abel, an independent systems architect and developer in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

Code for most posts is available on my GitHub account.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.