I'm using weak keys while doing cryptography with libgcrypt and I'm getting proper warnings about it from libgpg-error as "Weak encryption keys" to stderr. Problem is that I'm reading std:err into GUI, where I don't want to see them (just because getting too many of them). I can filter stderr input in GUI, but my preferable way would be to suppress the warning in more intelligent way. Unfortunately I don't have any clue how to achieve this. While reading though libgcrypt documentation I found that it allows suspending of secure memory warning only. Reading through libgpg-error source code I haven't found anything useful.
Your advice would be much appreciated.
Thanks in advance.
Jan
Finally I've got to ask libgcrypt developers. Following is the answer from Werner Koch, whom I want to thank in this way. I hope this is going to help somebody else.
==================================================================
I case you try to use a weak key for regular encryption and the error
checking inside the DES module inhibits you from actually doing it,
there is no documented way to go with it. A weak key is something which
should never ever happen.
You may however use a private control code to disable the weak key
detection. We use it in the regression tests. But note that this is
undocumented private feature which may or may not work with future
versions of Libgcrypt. Here is a code excerpt:
#define PRIV_CTL_DISABLE_WEAK_KEY 61
err = gcry_cipher_open (&hd, cipher_algo, cipher_mode, 0);
if (err)
die ("gcry_cipher_open failed for algo %d, mode %d: %s\n",
cipher_algo, cipher_mode, gpg_strerror (err));
gcry_cipher_ctl (hd, PRIV_CTL_DISABLE_WEAK_KEY, NULL, 0);
==================================================================
Edit
Disabling weak keys warning is now suppressed in the latest libgcrypt version so the above makes no sense anymore. We've fixed that by catching up stderr in a boost stream and filtering it out before providing it in a log.
Related
I've learned something about thread local storage(TLS). From my point of view, this is a totally black box - you give it a key, and it gives you the thread local data back. No idea what the key is like and where these local data is saved.
Recently I've found some hacky ways to retrieve TLS data, but couldn't figure out how they work.
In project async-profiler(at src/vmStructs.cpp line:347), pthread key is an int, why? I read the source code about pthread manipulation of Hotspot JVM and didn't find any clue. Hotspot doesn't specify the type of pthread key (and I don't think it can either). And why we could guarantee to find the pthread key with just a simple integer loop? Not sure this is a TLS question or a Hotspot question. :(
pthread_tis an address of pthread. I think it points to some OS thread instance that we may not parse it directly. But, according to Phoenix87's answer, we could regard pthread_t as an address of pthread_t list in which we could find TID(the return of gettid()) with a simple loop (a simple loop, again). You could find it in Austin (at src/linux/py_proc.h line: 613). How does it work?
Both of these make assumptions about the pthread implementation they are working on.
Such assumptions are not warranted in general, and are almost guaranteed to break with a different implementation.
Don't write code like that unless absolutely necessary, and if you do write code like that, please clearly state exactly which implementation(s) and which versions you support.
With a snippet like
perl6 -e 'loop { FIRST say "foo"; last }'
I get
WARNINGS for -e:
Useless use of LOOP_BLOCK_1 symbol in sink context (line 1)
foo
I know how to work around the warning. I'm wondering about what the source of the warning is. I found this open ticket, but it doesn't seem to have received any attention.
What is this warning about?
And what about this is useless?
Version
$ perl6 --version
This is Rakudo version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
It's a bug, a bogus warning.
I know how to work around the warning.
That's the main thing.
I'm wondering about what the source of the warning is.
It's a bogus warning from the compiler.
I found this open ticket, but it doesn't seem to have received any attention.
I think it got some attention.
bbkr, who filed the bug, linked to another bug in which they showed their workaround. (It's not adding do but rather removing the FIRST phaser and putting the associated statement outside of the loop just before it.)
If you follow the other links in bbkr's original bug you'll arrive at another bug explaining that the general "unwanted" mechanism needs to be cleaned up. I imagine available round tuits are focused on bigger fish such as this overall mechanism.
Hopefully you can see that it's just a bizarre warning message and a minor nuisance in the bigger scheme of things. It appears to come up if you use the FIRST phaser in a loop construct. It's got the very obvious work around which you presumably know and bbkr showed.
What is this warning about?
Many languages allow you to mix procedural and functional paradigms. Procedural code is run for its side effects. Functional code for its result. Some constructs can do both.
But what if you use a construct that's normally used with the intent of its result being used, and the compiler knows that, but it also knows it's been used in a context in which its value will be ignored?
Perls call this "useless use of ... in sink context" and generally warn the coder about it. ("sink" is an alternative/traditional term for what is often called "void" context in other language cultures.)
This error message is one of these warnings, albeit a bogus one.
And what about this is useless?
Nothing.
The related compiler warning mechanism has gotten confused.
The "Useless use of ... in sink context" part of the message is generic and hopefully self-explanatory.
But there's no way it should be saying things like "LOOP_BLOCK_1 symbol". That's internal mumbo-jumbo.
It's a warning message bug.
I know that I can ignore compiler warnings with -w on a given file in Xcode.
I would like to similarly ignore analyze warnings on a given file (JSONKit.m in this case, which has two potential leaks). I trust that the developer of that library knows what they're doing, and I don't want to maintain a fork of it. Not to mention that I have no clue what's going on in there anyway.
Any ideas?
Don't trust the developer. Figure out why the potential leaks exist and fix them (ideally, sending a patch back to the developer).
If you want to take the lazy way out (j/k ;), you can add code to fix the problem under the analyzer only using:
#ifdef __clang_analyzer__
... release the offending variable here ...
#endif
I prefer this solution to whole-file-disabling because it both exactly identifies the problem area with an easily searchable identifier and it allows the rest of the file to be vetted by the constantly improving analyzer.
This code hummed along merrily for a long time, until we recently discovered an edge case where it fails silently-- no errors returned.
The fail is apprently pretty subtle. We can get the code to run uneventfully in the edge case by:
1) compiling with any set of options that includes -traceback or debug (-g or -gopt);
2) compiling with -fast -Mnounroll;
3) compiling with optimization <2;
4) adding WRITE statements into the code to determine the location of the fail;
In other words, most of the tools useful for debugging the failure-- actually result in the failure disappearing.
I am probing for any information on failures related to loop unrolling or other optimization, and their resolution.
Thank you all in advance.
I'm not familiar with pgf (heck, it's been 10 years since I used any fortran), but here are some general suggestions for tracking down (potential) compiler bugs:
Simplify a reproducible case. I.e. try to reproduce the problem with a similar looking piece of code that has all the superfluous details removed. This is helpful because a) you'll be less hesitant to release the code publicly, and b) if someone attempts to diagnose the problem, it will be easier for them with less surrounding material.
Talk to the experts: If you have a support contract for pgf, use it! There's a support request form on their site. If not, there's a User Forums section where you might be able to post your information - someone else may have better workaround, or an employee there may be able to log your problem.
Double-check your code. Is it possible that you're relying on some sort of unspecified behavior? This is the sort of thing that would cause your program to switch behavior when changing optimization levels. I'm not saying compiler bugs are impossible, but it could be a hack in your code too.
Hope that's helpful.
Theoretically, the end user should never see internal errors. But in practice, theory and practice differ. So the question is what to show the end user. Now, for the totally non-technical user, you want to show as little as possible ("click here to submit a bug report" kind of things), but for more advanced users, they will want to know if there is a work around, if it's been known for a while, etc. So you want to include some sort of info about what's wrong as well.
The classic way to do this is either an assert with a filename:line-number or a stack trace with the same. Now this is good for the developer because it points him right at the problem; however it has some significant downsides for the user, particularly that it's very cryptic (e.g. unfriendly) and code changes change the error message (Googling for the error only works for this version).
I have a program that I'm planning on writing where I want to address these issues. What I want is a way to attach a unique identity to every assert in such a way that editing the code around the assert won't alter it. (For example, if I cut/paste it to another file, I want the same information to be displayed) Any ideas?
One tack I'm thinking of is to have an enumeration for the errors, but how to make sure that they are never used in more than one place?
(Note: For this question, I'm only looking at errors that are caused by coding errors. Not things that could legitimately happen like bad input. OTOH those errors may be of some interest to the community at large.)
(Note 2: The program in question would be a command line app running on the user's system. But again, that's just my situation.)
(Note 3: the target language is D and I'm very willing to dive into meta-programming. Answers for other languages more than welcome!)
(note 4: I explicitly want to NOT use actual code locations but rather some kind of symbolic names for the errors. This is because if code is altered in practically any way, code locations change.)
Interesting question. A solution I have used several times is this: If it's a fatal error (non-fatal errors should give the user a chance to correct the input, for example), we generate a file with a lot of relevant information: The request variables, headers, internal configuration information and a full backtrace for later debugging. We store this in a file with a generated unique filename (and with the time as a prefix).
For the user, we present a page which explains that an unrecoverable error has occurred, and ask that they include the filename as a reference if they would like to report the bug. A lot easier to debug with all this information from the context of the offending request.
In PHP the debug_backtrace() function is very useful for this. I'm sure there's an equivalent for your platform.
Also remember to send relevant http headers: Probably: HTTP/1.1 500 Internal Server Error
Given a sensible format of the error report file, it's also possible to analyze the errors that users have not reported.
Write a script to grep your entire source tree for uses of these error codes, and then complain if there are duplicates. Run that script as part of your unit tests.
I know nothing about your target language, but this is an interesting question that I have given some thought to and I wanted to add my two cents.
My feeling has always been that messages for hard errors and internal errors should be as useful as possible for the developer to identify the problem & fix it quickly. Most users won't even look at this error message, but the highly sophisticated end users (tech support people perhaps) will often get a pretty good idea what the problem is and even come up with novel workarounds by looking at highly detailed error messages. The key is to make those error messages detailed without being cryptic, and this is more an art than a science.
An example from a Windows program that uses an out-of-proc COM server. If the main program tries to instantiate an object from the COM server and fails with the error message:
"WARNING: Unable to Instantiate
UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance'"
99% of users will see this and think it is written in Greek. A tech support person may quickly realize that they need ro re-register the COM server. And the developer will know exactly what went wrong.
In order to associate some contextual information with the assertion, in my C++ code I will often use a simple string with the name of the method, or something else that makes it clear where the error occured (I apologize for answering in a language you didn't ask about):
int someFunction()
{
static const std::string loc = "someFunction";
: :
if( somethingWentWrong )
{
WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance);
}
}
...which generates:
WARNING [someFunction] : Unable to
Instantiate UtilityObject: Error
'Class Not Registered' in
'CoCreateInstance