When I add a dependency to my maven projects, I like to add some comments to indicate what it is, and what license it's released under, for example:
<!-- XML parser -->
<!-- Apache License, Version 2.0 -->
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.9.1</version>
<scope>compile</scope>
</dependency>
My main concern is being able to check (manually, for now) that the licenses are all compatible with one another. The pom.xml documentation states:
Note that a project should list only licenses that may apply directly to this project, and not list licenses that apply to this project's dependencies.
Is there a better way to capture this metadata? Maybe a way to "override" the <licenses> information from a dependency's POM if it's missing?
First of all you can't overwrite the licenses part of a pom, cause it's not inherited. Secondly you can automatically check the licenses of your dependencies using the Maven-Licenses-Verifier-Plugin (available via Maven Central) which will handle such a situation for you and furthermore you can generate a report about that (Example).
If I understand correctly, the Maven Remote Resources Plugin and the License Maven Plugin claim to be able to do this.
I have been working with the License Maven Plugin today and following their instructions I can generate a license report that indicates which licenses are missing. Then I can add the missing licenses and get a report on all the licenses in the project. However really I would like this information to be available when I generate the site, but there the license information for the third party dependencies is missing. It would also be useful to be able to add URLs for new licenses or URLs for the dependencies themselves (this information is also included in the site report).
I took a look at the plugin khmarbaise wrote for verifying if the dependencies used in a project but this does not help solve the problem of missing licenses.
Related
Due to the recent problems with log4j I was checking all my code etc..
While doing so i discovered two files named
"slf4j-log4j12-1.7.5.jar" and "log4j-1.2.17.jar"
to find under
"...\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars"
Since we are also developing SSIS packages we kinda rely on this extension.
Sadly I was not able to find anything about SSIS in context with log4j. IMO it's also a bit dubious that the version of the log4j seems to be 1.x, which support ended in 2015.
Are there any known fixes/updates?
This is not a problem.
In what way those .jar file can be exploited to trig a privilege escalation or software evasion?
The fact that Visual Studio is using old libraries doesn't shock me at all. Large companies are use to rely on third party library and then they are usually forbidden in the corner during years.
EDIT:
You question was somehow interesting and I needed to dig further.
Apparently this 0-day has been around since March, so it means 9 month ago. There is no evidence of mass exploitation but that doesn't mean that it hasn't been used in the past months.
In order to use it:
[...] an attacker only needs to get the system to log a strategically
crafted string of code. From there they can load arbitrary code on the
targeted server and install malware or launch other attacks. Notably,
hackers can introduce the snippet in seemingly benign ways, like by
sending the string in an email or setting it as an account username.
This means that hypothetically you can exploit the vulnerability through SSIS in this scenario:
Create an SSIS package that ask for an input to the client user
The package must use log4j for logging
The user enter the malicious crafted string of code
...then yes in this case an SSIS package could be exploited.
I will try it out in my spare time and I will let you know.
EDIT 2:
After extensive research I can confirm you that this is not a problem because only version Log4j 2.X are impacted:
Mitigation
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques
below.
Use log4j-finder developed by FOX IT to enumerate vulnerable log4j files on your machines.
Microsoft have now removed the dependency
There is a new version (3.16) of the SSIS tools for VS2019 which removes the dependency for log4j.
Here's the download link:
https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
Version 3.16 Upgrade Notes
I've been developing UWP app until I got this error (picture below). I've searched for solution but I couldn't find anything. It doesn't even say which package is the incompatible. How can I find the incompatible package in my solution? Also is there any way to re-create project.json by automatically? I ask it because I changed something on project.json and broke it more.
Also I'm using VS2017 and I'm able to run project without issue. I just can't update package.
Thanks.
(github link for project if you want to look at it.)
I used your GitHub https://github.com/almorax/dota2-handbook-uwp project to troubleshoot the problem and looks like the problem is with the way the nuget package is referred in "Dota2Handbook" project. In other projects, you have used "PackageReference" way to refer the nuget package however in "Dota2Handbook" project you are using project.json to refer nuget package. When I changed "Dota2Handbook" project to use the "PackageReference" way then I was able to get the latest package.
Note: You will notice that "Dota2Handbook.Infrastructure" project already use the new way to refer Nuget packages
More details on PackageReference : https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
What happened to me is that I have UWP projects that were made in VS 2015 and initially targeting Windows 10 RTM. These projects where updated to VS 2017 and to target Creator's Update. All worked fine, and all projects still used the original project.json style.
Then I tried to create a new Windows Runtime Component project and target Creator's Update initially. Targeting Creator's Update in VS 2017 causes the project to use the new PackageReferences project style. This produced the errors shown in the above question when I referenced the WinRT component from the UWP app.
Rather than converting the all of my legacy UWP project files to use the new format, I target the new UWP or WinRT Component library to Anniversary Edition (which uses the older project.json project style), then retarget to Creator's Update.
Of course, at some point updating the project file may be appropriate, just know that it will no longer be supported by VS 2015. Conversion steps are illustrated here.
I created a plugin for sublime and I called it "sublimecastling".
The main idea is to replace 2 selected fields.
So I'll be glad to know whether it's possible to add it to your Sublime repository in order users could install the plugin via package-control.
The github link is provided below,
https://github.com/unknownuser88/sublimecastling
If you want to make a plugin available via Package Control, visit the documentation page on the Package Control website and click on Submitting a Package. There are a number of steps, which can be summarized as follows:
Search Package Control to ensure your package fulfills an unmet need, or greatly improves upon an existing package - don't create a new one (especially a very simple one) when you could work with the author of an existing one to add a particular feature.
Pick a name - there are several requirements here.
Decide how to host - Github? Bitbucket? Your own SSL server?
my own note here: Github is easiest
Pick a versioning strategy using semantic versioning. Note that all new packages must release by using versioning tags, not by branches or commits.
Prepare your repo - several things to do here.
Fork the Package Control Channel on Github and add your repo to the default channel - detailed instructions included.
Run the ChannelRepositoryTools package in Sublime to make sure everything is OK.
Note: Test your package with both ST2 and ST3 to make sure it works with both versions of Sublime. If you can only support one version due to the language differences between Python 2.6 and 3.3, pick ST3 - it is the future of Sublime, has a very large user base already, and will get you maximum exposure. If you haven't personally upgraded to ST3, now is the time to do so. If you are a registered user—which you should be :)—test with both the public beta and the latest dev build.
Finally, you can submit your pull request.
Be patient, it may take a little while for it to be reviewed, and it is not uncommon at all for changes to be requested. It is by following strict procedures that the community maintains the high quality of the packages available for users.
I'm having trouble understanding why the Newtonsoft JSON parser has to be device specific under Xamarin. I cannot seem to find any way to have the parser exist in a common, shared library. I'm using the Tasky Pro sample app. I can get the JSON.Net DLLs from the Xamarin store to work in the Android and iOS projects, however that makes no architecural sense. E.g., the SQLite stuff is all in a shared lib, as you'd expect - as one set of c# source files.
Ideally I'd like to just add some kind of reference to "Tasky.Core" and be able to serialize/deserialize JSON.
Is there any way to get JSON.Net to work in a shared library (across droid/ios/wp8)? The source is pretty huge to try to manage as linked files, if that's even possible...
If not, is there some alternative way of managing JSON that will work in this way?
You should be able to use the JSon.NET NuGet Package for this. The implementation is actually platform-specific [1], but NuGet will transparently take care of that for you and pick the correct one for you.
Note that you need Mono 3.2.6 and Xamarin.iOS 7.0.6 for this, which just hit the alpha channel this week, I have just fixed some critical bugs in this area. You should also upgrade the NuGet Add-In in Xamarin Studio to the latest version (0.8), which contains several PCL-related bug fixes.
Simply add the NuGet Add-In to Xamarin Studio if you have not done so already, then search for "JSon.NET", the add-in will automatically install the package and add the required library references for you.
[1] The NuGet package contains different .dll's for different target frameworks and then picks and references the best one for your project - so your application will only contain a single implementation, but an iOS app may use a different one than a desktop application.
Update 01/14/14:
NuGet packages usually contain different implementations - unfortunately, not all of them will work with Xamarin.iOS due to APIs such as Reflection.Emit or Full DLR that are not available on iOS.
If you look into the packages/Newtonsoft.Json.5.0.8/lib/ directory, you'll see different sub-directories - each of these contain a different implementation and NuGet will use the one that best fits the current target framework. Unfortunately, NuGet does not always pick the right one :-(
For Newtonsoft.Json.5.0.8, the "portable-net45+wp80+win8" implementation uses DLR features that are not available on iOS, the "portable-net40+sl4+wp7+win8" one is ok. So if you add the NuGet package to a PCL that's targeting for instance Profile136, you'll get the correct implementation.
There is no GUI to choose another implementation, but you can edit the .csproj file. Replace
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net45+wp80+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
with
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.5.0.8\lib\portable-net40+sl4+wp7+win8\Newtonsoft.Json.dll</HintPath>
</Reference>
and it should work.
In general, when you're getting an error message about missing types after adding a new NuGet package, go to the corresponding package directory and grep -r for that symbol - chances are that there's a different implementation which does not use this type.
Hopefully, a more elegant solution will be available in the future, but that needs coordination with the NuGet team and package authors, so it'll take some time.
Just add it to Shared Library via NuGet. Actually, all your request/response tasks should be done in library. You should use JSON.Net to parse response.
I develope an open source application. Directory structure of my project is:
app
|-include
|-src
|-doc
|-build
|-lib
|-bin
I want to use another open source library. There are some choises:
Add third-party library source code to include and src directory.
Compile third-party library and add to include and lib directory.
Create a third_party directory and add complete source code of third-party library to it.
Create a third_party directory and add compiled of third-party library to it.
What is the best choise? Is there any better way to manage directory structure of a project that uses third-party open source library?
If you are ever planning to upgrade the third-party library, it will be much more convenient to keep it in a specific subdirectory. You don't have to have a specific "third-party" directory; you could name it after the library.
Think about what goes in version control.
If you are copying the third-party library into your repository, then you SHOULD NOT include compiled products (using source instead), as they are typically impossible to diff and platform-specific.
If the user is going to obtain the library separately and add it to your project's tree, then using a subdirectory will make it easier to unarchive and guarantee there won't be any name conflicts; source versus binary should be left up to the user.
At the other extreme, if you are using a reference your VCS manages (such as SVN externals or Git submodules), you will probably have to include the source in a subdirectory.
One concern you should bear in mind, depending on your situation, is whether you will someday have to account for those third party open source components and compliance with the licenses etc.. It can be easier to manage this kind of thing if you keep the third party files in their own directories. Having the unmodified source code and licenses handy and a link back to where you got the source code and could get it again would be useful as well. I've worked at companies where there were license compliance verification processes that were easier to get through if the third party sources were segregated in this fashion.
https://softwareengineering.stackexchange.com/questions/234511/what-is-the-best-practice-for-arranging-third-party-library-licenses-paperwork is relevant on this.