If you build from Github source, you get an error on checking signed assemblies.
Is it okay just to change:
SignAssembly = false
DelaySign = false
in tools\DotNetOpenAuth.props?
Just for developing/debugging purposes.
Yes, that should be fine.
Be cautious about making changes to and building a security library. You could think you're making a simple or safe change, but actually be inadvertently undermining a security measure and leave yourself vulnerable.
Related
So I'm working on modifying a project to build with clang++ and sanitizers (for fuzzing), as opposed to just g++. It builds using bazel.
The project currently downloads some of its build dependencies (m4/bison/flex) and builds those using the make_configure rule in https://github.com/bazelbuild/rules_foreign_cc. Importantly, these are just used for code generation, and aren't linked/compiled against.
Unfortunately, those very dependencies happen to have various sanitizer issues. That means if we build using --copt="-fsanitize=address", we can't then use them for code generation and the build fails! Now, if we ran into sensitization issues with linked dependencies, that would be unavoidable and something we'd need to work with the maintainers to fix, but right now we'd really just prefer to work around those, since they don't as directly affect the security and reliability of the actual target that we're compiling.
Is there an easy way to specify, more or less, "please ignore the compiler flags/linker options/etc. passed on the command line for just this target and use this other set instead" for a rule? It seems like linkopts/copts/cxxopts that are passed via the command line (or via a global config) are additive in most cases, and we'd like to avoid that. If there isn't, what's the best way to approach solving that? Saving/unsetting/resetting all of the variables as we go in a custom rule that wraps the actual build rule?
Thanks,
Everett
So, found my answer eventually.
There's a few approaches that will probably work here. One is a custom SkyLark rule that overrides the tools provided by the command line. That does have the potential advantage of being more "future proof" against other command line options that may not play nicely with some options passed to the compiler/linker.
However, what wound up being easier was learning the fact that the gcc/clang family of compilers has a fun behavior that plays nicely with bazel--if you specify "conflicting" command line parameters, it appears that the later one is always taken. Therefore, all we had to do is ensure that "-fno-sanitize=address" was passed into the build rule for the targets that we wanted to turn off ASAN for, while we passed "-fsanitize=address" into the global build.
Hope this helps anyone else who gets stuck on a problem like this.
--Everett
"The Correct Way" would be to define your own toolchain(s) and therein add a feature, e.g.:
asan_feature = feature(
name = "address_sanitizer",
enabled = True,
flag_set(
actions = all_compile_actions + all_link_actions,
flag_groups = [
flag_group(flags = ["-fsanitize=address"]),
],
),
],
)
that you pass along with features to create_cc_toolchain_config_info().
You can make this feature enabled by default or not for any given toolchain and you can control features used build wide on CLI, per package and per target (e.g. cc_binary):
cc_binary(
...
features = ["-address_sanitizer"],
)
The obvious downside is, there is some initial work involved.
The upside being, compiler config / behavior really is (should be) a function of toolchain configuration and not something for each target to fiddle with. You get an abstract structure that is independent from the specific compiler underlying any given toolchain.
What is the best way to restrict use of certain headers(features of the library itself) in certain Cpp files. And if it fails to follow the set rules, compilation should halt.
This is not about finding out superfluous includes. This is about restricting the developers to the applicaiton framework.
For example if there exists a osUtils class as osUtils.h and if as per this, this application's development framework mandates use of osUtils.h for filesystem operation like to make a folder. but there are always a chance that individual module finds it convenience to break this rule by including sys/stat and use a mkdir() method. But if the intention of providing a framework here lets say for cross-platform abstraction or special path handling logic, the objective is lost by doing it out of framework. Is there a way to restrict this? like restricting the usage of sys/stat.h in certain files (except for osUtils.h file in this case) can help solve the problem. but how to implement it so it will not compile if the rule is broken.
I don't know how to do this by breaking compilation - the idea of compilation failure because of a valid code don't appeal to me. I've got some other ideas:
Code review. If done right this should prevent such errors.
I am pretty sure that some static code analysis tool can help detect
those things (they can check things like 'include what you use', so
a rule 'don't include 'XYZ' should be there)
If you have this static analysis tool ready there is a problem with getting people to use it and fix errors shown by it. One option that you can use is git hook. If the new code don't pass the static analysis - reject the commit. If you cannot use hooks, or don't want to - make a separate CI job that will check for the violations of the static checking. Then you'll see who and when pushed some bad code.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I wrote own code, using C++ Win32 API and boost library. The code compiles to EXE application for windows. I can guarantee that it is malware free, but virustotal.com reports that 9 of 56 antivirus softwares will recognize the exe file as having malware.
I see no reason why this should happen. I noticed some time ago that compiling things with LCC-Win32 compiler raised some malware flags while compiling the same code with Visual C++ produced a clean EXE file, however now even Visual C++ produces EXE file which flags as malware at virustotal.
I can say that my build computer is not infected, since if I compile just Hello World code, or some other bigger application, then virustotal doesn't report any malware at all for the newly compiled exe, which it would if some crazy stuff happened behind my back.
Is there any way to get rid of the incorrect malware flags reported by virustotal? I mean, without changing my code (since I know it's clean, I wrote it). Can I report somewhere at virustotal that their virus test is broken? Do I have to contact all the antivirus companies whose antivirus triggers the flag individually, one by one, by email, asking them to fix their antivirus software? Is there any place where one can report a false positive?
I've worked in a leading antivirus company and couple of others. So trying to answer your questions.
Is there any way to get rid of the incorrect malware flags reported by
virustotal?
Antiviruses basically check executable for few suspecious symptoms. For example malicious packer used, entry point obfuscation, suspicious instruction set used, header info compromised etc. They essentially do it around executable's initial set of bytes. If any of these being incorporated in your executable behind your sense, antivirus will trigger it as malicious. If you want to "get rid of malicious flags" you have to narrow down on what causing them (It could be anything like: A function call, a module, specific post processing etc.) and then simply try to remove that root cause from your application.
At least if you can tell what type of malware is being reported by each antivirus for your executable, it would be helpful mitigating the problem.
I mean, without changing my code (since I know it's clean, I wrote
it).
Without changing the code if you thinking of editing directly executable binary to remove "those few flags", it's not simply that straight forward. (As your might have realized by reading what I written above on how antiviruses analyzes the file before they trigger it as malicious).
Also, you cannot claim that it's clean "because you wrote it". Because you actually code portion of it. May be there is third party library/component you are using unknowingly, which you are not aware it is causing to trigger the whole executable as malicious. (And moreover, if your system has been infected, your newly developed executable can get infected immediately after you build it. This happens behind your sense.)
Can I report somewhere at virustotal that their virus test is broken?
In your case, this is called "false positive". This is what virustotal says on their faq about false positives:
VirusTotal is detecting a legitimate software I have developed,
please remove the detections
VirusTotal acts simply as an information aggregator, presenting
antivirus results, file characterization tool outputs, URL scanning
engine results, etc. VirusTotal is not responsible for false positives
generated by any of the resources it uses, false positive issues
should be addressed directly with the company or individual behind the
product under consideration.
We can, however, help you in combatting false positives. VirusTotal
has built an early warning system regarding false positives whereby
developers can upload their software to a private store, such software
gets scanned on a daily basis with the latest antivirus signatures.
Whenever there is a change in the detections of any of your files, you
are immediately notified in order to mitigate the false positive as
soon as possible.
Do I have to contact all the antivirus companies whose antivirus
triggers the flag individually, one by one, by email, asking them to
fix their antivirus software? Is there any place where one can report a false positive?
Yes. As mentioned by virustotal in above faq, false positive issues
should be addressed directly with the company or individual behind the
product under consideration.
We're just beginning a new project and we're keen to include testing from the ground up.
While we were looking at which unit test solution to use I came across Code Contracts which seem like they offer an easier way to check things like null parameter passing without having to write independent unit test methods.
One thing I am little confused about and makes me wary of investing heavily in Code Contract checks, is the fact that the analysis tool needs to be downloaded from DevLabs and isn't included in VS2012 by default.
What is the reason for this?
Additionally: It seems people are reporting that VS2012 support for Code Contract analysis seems flakey, why would be use Code Contracts if the analysis capabilities aren't very good?
I can't speak for VS2012, but it works perfectly fine for me in VS2010. There is a very minor conflict with Code Analysis in that a false alert is raised, but you simply switch off that Code Analysis rule and rely on the Code Contracts static checking (which is a lot more comprehensive).
Probably the best place to get the answer for your IDE integration is via the email address located on the Code Contracts Website, however I suspect that because its a research project, not having it as an "official" part of the IDE provides the ability for more regular updates.
i want to log a lot of events in a dynamically search-algorithm (e.g. information about convergence to global optimum). This logging should have a switch to turn it off/on. Now there are a lot of possibilities to achieve that:
implement a log-version and a non-log-version of the algorithm -> redundancy
use macros -> ugly and not that safe
use a c++ logging library (or: use 1% of the functional range of a logging library).
I decided to use Pantheios, especially because of the performance claims made (don't want to lose much performance because of this logging, which is only needed in development). I have to admit, that i don't need much of the functionality of this library, but i thought i would be a much nicer/safer way to use it. Maybe there would be a better suited alternative i don't know of (i need compile-time decisions only for logging -> don't know if there are logging-libraries designed for that purpose).
After compiling, installing and finally linking (no success with manually linking, but with the scons building tool; using gcc -> explicit linking), i wanted to try a little example.
Let's reduce that to something like the following:
#include "pantheios/pantheios.hpp"
#include "pantheios/frontends/stock.h"
const PAN_CHAR_T PANTHEIOS_FE_PROCESS_IDENTITY[] = "pantheios_test"; // specify process identity
int main()
{
pantheios::log_ALERT("alert-event");
pantheios::log_DEBUG("debug-event");
pantheios::log_INFORMATIONAL("just information");
return 1;
}
Linking is done with the following files:
LIBS=['pantheios.1.core.gcc44', 'pantheios.1.be.fprintf.gcc44', 'pantheios.1.bec.fprintf.gcc44',
'pantheios.1.fe.all.gcc44', 'pantheios.1.util.gcc44']
The simple question is now: how to switch the console-output off/on? How to choose the severity-level which is given to the back-end?
Looking into the documentation lead me to a lot of functions which take a severity level, but these functions are automatically called once for initialization. I know that dynamic changes of severity-levels are possible. I don't know exactly, where i change these settings. They should be in the front-end component i think. Is linking to "fe_all" already some kind of decisions which level is logged ad which level isn't?
It should be relatively easy because in my case, i only need a compile-time decision about logging on/off.
Thanks for your help.
Sascha
Is linking to "fe_all" already some kind of decisions which level is logged ad which level isn't?
Short answer: yes.
fe.all enables all severity levels: "all" meesages are logged.
If you want better control, try fe.simple. By default it switches on everything in debug builds and everything except DEBUG and INFO in release. You can change the threshold at anytime - in debug or release - by calling the function pantheios_fe_simple_setSeverityThresdhold() (or something similar) in the fe.simple header (which is pantheios/frontends/fe.simple.h, iirc).
Be aware that Pantheios is described as a logging API library. I think the intention is that it provides an API, initialization control and output over an existing "rich" logging library. That it provides "stock" front-ends and back-ends is a convenience to users for (i) getting up to speed quickly, and (ii) simple requirements (for which your program may qualify).
btw, I think the Pantheios forums on the project site are pretty well supported, so you may want to post questions there as well as here.