[xmlsec] Verify signature after certificate expired
Aleksey Sanin
aleksey at aleksey.com
Thu Oct 10 20:52:52 PDT 2002
Forgot to say that __FUNCTION__ is equal to function name.
For example, the following code:
#include <stdio.h>
void func1() {
printf("%s\n", __FUNCTION__);
}
void func2() {
printf("%s\n", __FUNCTION__);
}
int main() {
printf("%s\n", __FUNCTION__);
func1();
func2();
return(0);
}
will produce the following output:
"main"
"func1"
"func2"
As you can see, __FUNCTION__ outside a function has no meaning.
Aleksey.
Aleksey Sanin wrote:
> __FUNCTION__ is defined *only* inside function. According to C99 spec
> it has no defined in the global scope (outside any function).
>
> Aleksey
>
> Moultrie, Ferrell (ISSAtlanta) wrote:
>
>>Igor/Aleksey:
>> I just tried the change below and it works with MSVC 6.0 SP4. Thanks
>>for explaining what that macro is all about. One other thought though ..
>>What about something like:
>>#ifdef __FUNCTION__
>>...
>>#endif
>> That would seem to work without being tied to a specific compiler
>>version or platform.
>>Ferrell
>>
>>-----Original Message-----
>>From: Igor Zlatkovic [mailto:igor at stud.fh-frankfurt.de]
>>Sent: Thursday, October 10, 2002 10:46 PM
>>To: Aleksey Sanin
>>Cc: Moultrie, Ferrell (ISSAtlanta); xmlsec at aleksey.com
>>Subject: Re: [xmlsec] Verify signature after certificate expired
>>
>>
>>Hi there,
>>
>>You are basically right, but first let us clear something: I don't use
>>Visual Studio .NET :-) I tried, but it gave me trouble with its sick
>>C-runtime, so I vetoed its further existence on my hard drive. I use MS
>>compiler which is a part of Windows XP Driver Development Kit, all of it
>>
>>from the command line. I have no IDE installed, I use XEmacs for my
>>source-editing needs, even for .NET development :-)
>>
>>Well, my compiler from the DDK has __FUNCTION__ predefined, but is far
>>more
>>recent than the one delivered with the Visual Studio 6. It can very well
>>be
>>that the VS6 compiler (version 12 and lower) doesn't know about this
>>macro.
>>My appologies. I have no way to test compilers with version numbers
>>other
>>than my own.
>>
>>The offending line would then be something like
>>
>> #if !defined(__GNUC__) || (_MSC_VER >= 1300)
>>
>>and that should solve it. I'm now hacking something on Linux and will do
>>
>>this line myself when I boot Windows again, unless done by then allready
>>:-)
>>
>>By the way, Ferell, could you please, please test the above line with
>>your
>>compiler and confirm it is okay?
>>
>>Ciao
>>Igor
>>
>>
>>Aleksey Sanin wrote:
>>
>>
>>>Igor made changes in the Win32 build and forgot that not everyone uses
>>>Microsoft .Net Visual Studio :) MS VC 6.0 has no __FUNCTION__ and
>>>this caused problems. I guess the correct path is:
>>>
>>>326c326,327
>>>! #if !defined(__GNUC__) && !defined(_MSC_VER)
>>>---
>>>! #if !defined(__GNUC__) && (!defined(_MSC_VER) || (_MSC_VER < 1300))
>>>
>>>
>>>What do you think, Igor?
>>>
>>>Aleksey.
>>>
>>>
>>>
>>>Moultrie, Ferrell (ISSAtlanta) wrote:
>>>
>>>
>>>
>>>>Aleksey:
>>>> Thanks for making these changes. I've pushed aside what I was
>>>>
>>>>
>>working
>>
>>
>>>>on in my application so that I can work with this change. I pulled the
>>>>XMLSec tips with your changes from CVS and built it on Win32. With one
>>>>minor problem it builds and runs without any regression errors. I
>>>>haven't yet tried the new function bit but that is next. As for the
>>>>
>>>>
>>one
>>
>>
>>>>build problem I had, I don't really understand the change you made but
>>>>if I put it back like it was before, everything is fine. Here's the
>>>>diff's:
>>>>
>>>>diff -b backup/errors.h errors.h
>>>>326c326,327
>>>>< #if !defined(__GNUC__) && !defined(_MSC_VER)
>>>>---
>>>>
>>>>
>>>>
>>>>
>>>>>#if !defined(__GNUC__)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Without removing the !defined(_MSC_VER) and allowing the following
>>>>
>>>>
>>line
>>
>>
>>>>...
>>>>#define __FUNCTION__
>>>>... to be compiled, I get zillions of errors complaining about
>>>>__FUNCTION__ being undefined.
>>>>
>>>>If this isn't the correct change, please let me know what I'm missing
>>>>and I'll try that instead. More on the cert verification as soon as I
>>>>can figure out your example and make the appropriate changes in my
>>>>
>>>>
>>code
>>
>>
>>>>to do something similar.
>>>>Thanks!
>>>> Ferrell
>>>>
>>>>-----Original Message-----
>>>>From: Aleksey Sanin [mailto:aleksey at aleksey.com]
>>>>Sent: Thursday, October 10, 2002 3:53 AM
>>>>To: Moultrie, Ferrell (ISSAtlanta)
>>>>Cc: xmlsec at aleksey.com
>>>>Subject: Re: [xmlsec] Verify signature after certificate expired
>>>>
>>>>
>>>>I understand the problem with using 0.9.7 and I am waiting for it
>>>>for a very long time myself :) I've changed XMLSec library so now
>>>>this "expired certs feature" is supported for both 0.9.6 and 0.9.7.
>>>>Also I added a test case to my suite to test it. The code is not
>>>>complicated but it's new code and I would appreciate if you will
>>>>try this new feature in your environment. I would be glad to help
>>>>you and fix any bugs you find. The fixed XMLSec version should
>>>>be in tonight's snapshot or you can get it from GNOME CVS.
>>>>
>>>>Thank you in advance,
>>>>Aleksey
>>>>
>>>>Moultrie, Ferrell (ISSAtlanta) wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Aleksey:
>>>>>I *must* have this stuff -- there's not really another way to do
>>>>>
>>>>>
>>this
>>
>>
>>>>>without using a never-expiring cert from a private CA -- and that has
>>>>>it's own set of risks and hazards that are commisurate with, or
>>>>>
>>>>>
>>greater
>>
>>
>>>>>than, the risk you point out of not expiring a signature after it's
>>>>>released. For a code and/or data signing application intended *only*
>>>>>
>>>>>
>>to
>>
>>
>>>>>say that the data was valid at the time it was signed -- and should
>>>>>remain valid forever -- not having a signature expire is the
>>>>>proper/desired/required behavior.
>>>>>For your notes below:
>>>>>(1) My XML has a timestamp in a predictable format that correspond
>>>>>precisely to the time of signing so this isn't an issue in my case.
>>>>>
>>>>>
>>Not
>>
>>
>>>>>a problem.
>>>>>(2) Yucky because this is extra work in the application which I was
>>>>>avoiding -- but that's still not a big problem since verification
>>>>>
>>>>>
>>setup
>>
>>
>>>>>time isn't absolutely critical to my application.
>>>>>(3) I believe I understand your POV and the tradeoffs -- they just
>>>>>don't change how my application *must* behave.
>>>>>
>>>>>If you can either prototype the required code for 0.9.6g or give me
>>>>>
>>>>>
>>>>>
>>>>>
>>>>as
>>>>
>>>>
>>>>
>>>>
>>>>>good a pointer as you can to what should be done and where, I'll
>>>>>
>>>>>
>>check
>>
>>
>>>>>it out and test it with my application. I'm very appreciative of what
>>>>>you've done so far -- but I just can't use 0.9.7 in our
>>>>>
>>>>>
>>general-release
>>
>>
>>>>>applications at this time. Too much testing -- too many unknowns --
>>>>>
>>>>>
>>too
>>
>>
>>>>>hard to explain if it turns out to have a critical security
>>>>>issue/bug/etc. Thanks again for whatever you can do to help me move
>>>>>forward. Finding out about this today is painful/inconvenient -- but
>>>>>much better than finding out about it next year when all our
>>>>>applications suddenly shut down. Hopefully QA would have found this
>>>>>
>>>>>
>>>>>
>>>>>
>>>>soon
>>>>
>>>>
>>>>
>>>>
>>>>>(I just turned the X509 stuff over to them) but if we'd missed it, it
>>>>>would have been very painful.
>>>>>Ferrell
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20021010/a72775fe/attachment.htm
More information about the xmlsec
mailing list