Using sonarlint-cli for C++ analysis - sonarlint

I hoped to use sonarlint-cli (2.0) for pre-commit analysis of C++ with a remote SonarQube server (5.6.1), but when updating the binding and downloading analysis plugins, it tells me the cxx plugin (among others) is not compatible:
DEBUG: Plugin cxx is not compatible with SonarLint. Skip it.
This is the community C++ plugin (0.9.6).
I'm wondering about the compatibility rules for plugins with SonarLint, and about alternative pre-commit approaches.

According to SonarLint web site, the connected mode "will make SonarLint use the analyzers, quality profiles and settings defined on your SonarQube server." However, that is not entirely true.
SonarLint does not support the non-sonarqube analyzers. Thus, it does not support PMD, checkstyle, FindBugs, C++ community plugin, and others. So, even if these analyzers are defined on your SonarQube server and quality profiles, they will not be used.
You may ask why. In a google group discussion, it's said that SonarLint can only work perfectly and superfast if these other analyzers do not run.
I personally think that statement is detrimental to the developers of these other tools. The decision not to support third-party plugins is also problematic to organizations (like mine) that have invested a lot of time in polyglot static code analysis. Remember, for 5+ years many people have created custom checks and custom rules using checkstyle and PMD, for example. Back then, sonar (ergo sonarqube) did not offer an API for Java custom checks.
I'm worried that SonarQube might eventually drop support for all these external plugins altogether.

Related

Visual Studio 2019 SSIS-Extension log4j files

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

Future of native-client after WebAssembly Post-MVP

I am sure after WebAssembly Post-MVP, asm.js will be deprecated. Even now, a few existing asm.js projects already start to use WebAssembly. JS engine (V8) also starts to comiple asm.js to WebAssembly, so even if old projects never migrate, end-users will still get partial advantages from WebAssembly.
My question is, what about native-client then? It is not implemented in JS engine so that can be a problem. Native-client seems to be deprecated even now. Will native-client be completely removed from Chrome in foreseeable future? I would love to see some reduction in binary size of Chrome.
Side questions:
After thread/gc/simd/exception are included in WebAssembly, is there still something native-client has but missing in WebAssembly (blocking migration)?
It took WebAssembly about 2 years just to reach MVP, what is the expected time for any one of the Post-MVP to get finalized?
It seems like WebAssembly group is tackling multiple Post-MVP features at once instead of one by one, won't that make it slower to finalize one of them?
Answering the side-questions only, because I no longer work on Native Client. Google's plans are its own to speak for, so I'll make this a wiki.
Update as of 2017/05/20 NaCl isn't in glibc. This was the original libc which was supported, and took quite a while to clean up and upstream. It was only ever supported by NaCl's GCC toolchain. There's still support for musl libc, which works with the more up-to-date LLVM-based NaCl and PNaCl toolchain.
Update as of 2017/05/30 the Chromium team announced the fate of PNaCl and tentative roadmap of WebAssembly features.
Here are some Native Client features which you haven't mentioned:
Out-of-process, which many consider a bug because it forces asynchronous communication. It allows guaranteed address space, which with 64-bit isn't much of an upside, and was critical to Native Client's double-sandbox design. WebAssembly doesn't have processes yet.
Has blocking to and from the JavaScript event loop, through postMessageAndAwaitResponse. Also seen as a bug by many.
Has many APIs through Pepper. Many mirror the web platform's APIs.
Can do memory protection through mprotect (though execute pages are limited).
POSIX signals can be handled.
Supports computed goto and other irreducible control flow.
Has some Just-in-Time code patching support.
Supports weaker than seq_cst atomics.
Has support for inline assembly, as long as it follows the NaCl validation rules.
Not all of these are in Portable Native Client, though. There's official documentation of differences.
There's no timeline for any of the post-MVP WebAssembly features. We don't want to rush anything, but we want to deliver one the most useful things first. It's a community group, so priorities are really driven by whoever gets involved. Implementations won't be able to tackle features all at once, but exploration parallelizes well.

Can PMD, FindBugs, and Checkstyle be used together for a Java development project? Does it lead to wide overlapping of functions?

Can PMD, FindBugs, and Checkstyle be used together for a Java development project? Does it lead to wide overlapping of functions? Or else, can the same results be achieved using Sonar instead?
Yes, you can use PMD, FindBugs and Checkstyle together for a Java development project. There will be overlap, so you will have to select the rules that you activate accordingly. You could start with the default rulesets and then see which findings are being reported by more than one tool.
Using SonarQube (formerly Sonar) will also work. SonarQube uses all three tools (and more) under the hood. Using the SonarQube plugin for your IDE, you can also see the SonarQube findings in your code directly. However, you may still run into some overlap depending on your configuration. Chances are smaller though. SonarQube has recently begun providing their own detectors for much of the Checkstyle, PMD, and FindBugs functionality. Those SonarQube provided detectors have little to no overlap among themselves. Also, the "Sonar Way" default ruleset is configured so that there is no overlap.
However, if you want to utilize static code analysis professionally, you must be prepared to spend a significant amount of time configuring and fine-tuning the toolchain. After a while, the question of overlap becomes less present, and you will develop opinions on which detector implementation is best for your situation.

CI-friendly automated builds for as3/flex projects

Disclaimer: I am relatively unfamiliar with the flash build processes, so some/all of this may be misinformed nonsense. Please feel free to suggest alternative approaches.
We're currently developing a flex web app and our build situation is far from ideal. At present we're (as in individual developers) just building using FlashBuilder and deploying manually. The programmers are currently screaming bloody murder for two reasons, though:
The lack of CI is like going back to the stone age
We don't much care for FlashBuilder
(Note: We're only using FlashBuilder because it was the easiest way to set up a flex project in conjunction with Away3d and get it building / rendering correctly -- it's a stopgap solution).
As a predominately .NET development shop, we're used to doing continuous integration as well as continuous deployment. Ideally, we'd like to get something comparable to this for our flash projects without tying ourselves to a particular IDE.
Requirements:
The build process must be:
.. runnable via the commandline
.. runnable on both developer and CI build machines (and certainly not requiring an IDE!)
.. preferably as IDE-independent as possible (pragmatism will kick in though; if this causes a lot of friction we'll just pick one).
.. able to run on Windows (we develop using Windows)
We don't mind a touch of duplication or a few manual steps (e.g. tarting up the build scripts if we add a new project via an IDE, or generating one configuration from another if tools exist), but the less duplication / maintenance required the better.
I've read quite a few articles / blog posts and watched some short screencasts, but most of them are very thin on the ground on how the build system sits alongside IDEs. Most articles/screencasts have the same formula: How to create a "Hello World" build using a single file & text editors (no IDE).
I've not seen the topic of multiple libraries/projects etc. being broached, either.
After reading around the issue for a while, I'm considering investigating the following options:
Project Sprouts
Flexmojos
Maven Flex Plugin
buildr as3
Does anyone have any experience of the above solutions (or others I'm unaware of) and, if so, what do you make of them? Any help / pointers appreciated.
I recently started building with Gradle and the GradleFx plugin and I immediately fell in love with its power and ease of use.
Gradle is ANT + Maven + Ivy evolved and is primarily used from the command-line. You can:
write scripts in Groovy (a powerful Ruby-like language that runs in the Java Virtual Machine)
access all existing Maven and Ivy repositories as well as your own repos
use existing ANT tasks
integrate with CI (in Jenkins you just tick a checkbox to activate Gradle support)
although it has originally grown from the Java/Groovy community, it is in fact language agnostic. You add language-specific plugins for added functionality. GradleFx is such a plugin that provides you with additional ActionScript/Flex building tasks.
do easy multi-project builds. e.g. you can compile, unit test, package and deploy both your .NET service layer and your Flex client application with just one command.
use convention over configuration: if you stick to the conventions, your build scripts will be extremely terse
generate all kinds of reports: unit testing, checkstyles, codenarc, ...
generate Eclipse, IDEA or other IDE projects
all the things I haven't discovered yet
And best of all: it's very easy to learn. I had no knowledge of Maven before I started with Gradle and could get a multi-project build with some customizations working quite quickly.
Edit (comparison to Buildr AS3 and Maven)
I can compare this only to one of the projects you mentioned: Buildr AS3. It seems to start from a philosophy that is similar to Gradle's. But I've tried to use it about half a year ago and couldn't even get a simple 'Hello World' app to work. I e-mailed the developer for help: no response.
Compared to GradleFx: I had a small forum discussion with the developer (on a rather philosophical topic, since I didn't really need any help because it just worked right away). He answered within minutes.
As for Maven: (for what it's worth) I've only glanced at some configurations and they seem overly complicated when I compare them to a Gradle script.
There is one thing Maven does that you can't do with GradleFx (yet). It can pull the right Flex SDK from a Maven repo and build against that. With GradleFx you have to have your SDK's available locally.
I'm quite familiar with using maven as the main build tool and the flexmojos plugin from Sonatype. My experience has been a bit of a roller coaster with flexmojos. Maven is completely solid, it works all the time without issue, the only issue is the flexmojos plugin which has fluctuated a lot between versions. If you choose to go this route make sure to grab the source for flexmojos so you can see what your configuration options are actually doing to the command line parameters etc. For Flex 3.x flexmojos 3.x up to around 3.9 is good and works fine with regard to the goal for generating the .project eclipse files, believe there's also a mojo (a maven plugin) for generating intelliJ IDEA project files as well as others. If you're using Flex 4 you can compile with the latest flexmojos 4.0RC2 but it appears to me that the goal for generating flex/flashbuilder project properties is now gone (I'm not sure if this is because it's been replaced by another plugin altogether or what the deal is). However building with maven and flexmojos does fulfill all of your goals above (we also use it for building our service layer, so in a single mvn clean install we get a jar packed in a war packed in an ear with everything configured and a swf, that part is really nice). Also you can do continuous integration using bamboo (or simply write your own script that is triggered from a cron job or in windows as a batch file executed with a scheduled task if you don't have a *nix server around). Let me know if you'd like any more details or if I missed something major.
Shaun
I have been using Hudson, now Jenkins, with Ant for Flex automated builds and FlexUnit testing. Jenkins has some really useful plugins for integration with eclipse (and hence, FDT or FlashBuilder), Jira, SVN, Git etc., and it's free. Also, you can integrate the Ant build into Maven scripts, so I've found this to be a good and flexible solution for all purposes I've come across so far.
The Flex SDK comes with Ant tasks, and writing even elaborate Ant build scripts is quite easy - in fact, I'd been using Ant locally before, and I could reuse my existing scripts with only a few added extra compiler options for FlexUnit tasks.
However, it took a while to set up the system correctly for unit testing, because I'm running a headless server on Linux, and that implicates a rather complicated environment for ActionScript tests, because they run only in Flash Player. This, of course, is true for all CI scenarios using FlexUnit, regardless of which server you use.
Here's what I've learned:
FlexUnit needs a standalone debugger version of Flash Player installed, but Adobe only distributes binaries for the standard version on Linux. Therefore, compiling from source was necessary, and since my server system is stripped down to the bare necessities, it took some effort to install all the correct dependencies and get them to work.
The Flash Player needs hardware to run correctly: It uses graphics, therefore it needs a graphics card, and sounds, therefore it needs a sound card. On my headless server, this meant I had to install a VNC host to get it to run at all, and I had to eliminate any tests using sounds (those will now only run on local machines). If anyone ever comes across a working sound card emulation for openSuSE that I could use with the VNC client - you'll be my hero forever!
If you've set asynchronous timeouts in your unit tests, and/or you need to use setTimeout() to send delayed procedure calls, make sure the intervals aren't too short - I've had problems with tests that ran fine on any local machine, but broke the build on the CI server, because the Flash Player is considerably slower on the VNC client than on an actual graphics card.
I've also found this last issue to be a healthy lesson: Criteria for unit tests should not be based on assumptions about the system's performance, or at least be tolerant enough to succeed even on a slow machine.

WIX InstallUtil/InstallUtilLib and Configuration File Deployment why is InstallUtil bad?

I often find the quote "InstallUtil.exe" is an ugly pattern or "Don't use InstallUtil.exe" and that I should use native WIX or Installation package patterns and I still don't understood why.
I stepped away from using InstallUtil to install a .NET service as I finally learnt that writing registry keys for such an action should be an un-install-able action - and I've come to terms with this as correct.
As I've been working through my WIX installer for a relatively complex product, I have found myself in need of creating or updating SQL Server databases, creating or updating IIS Applications and finally updating or creating configuration files.
Each of my components (features) are optional, but they all share the same configuration file. As my product uses unity, its important to note that this library contains strong support for reading/updating/removing components from the Unity Configuration block, therefore it seems fairly smart to me that I should take advantages of these blocks via Installation Components (i.e. InstallUtil) to create or update my configuration file at installation time.
Just to be clear here, my installer does not natively contain a configuration file for my application: at installation time, the installer has no idea as to the shape of it as its based on the features selected. Surely I should be embedding this knowledge into each of the modules that are to be deployed and not in the remit of the installer which is now a completely independent project? Wouldn't this break O-O principals even if we are talking about installation?
I'd really appreciate some guidance as to whether this is good practise or not? Am I reading 'InstallUtil' is bad for installing services, or is it that using 'InstallUtil' is bad full-stop? If so, what are my options for smart updating of configuration files?
The main reason for avoiding InstallUtil is that it runs outside of the installation transaction, so Windows Installer cannot keep track of what it's done.
I have used InstallUtil on a few occasions, when I just couldn't get Wix to do what I needed and didn't have time to write a custom action. In this case I called the InstallUtilLib version as I feel this is a cleaner approach.
I used the this blog as a guide as to how to achieve this.