Re: [FWD] An error appears when run ./CA.sh -sign
forwarding from -users for a query. This is the second time that I've heard of bad end line or could not decode base64 today. Did a change go into 0.9.8i that changed base64 handling? -Kyle H On Thu, Dec 11, 2008 at 11:31 PM, Lutz Jaenicke jaeni...@openssl.org wrote: Forwarded to openssl-users for public discussion. Best regards, Lutz - Forwarded message from fastrunn...@sina.com - Date: Fri, 12 Dec 2008 14:20:21 +0800 From: fastrunn...@sina.com To: r...@openssl.org Subject: An error appears when run ./CA.sh -sign 1??The env is solaris9+openssl0.9.8i 2??The error message is below: Using configuration from /usr/local/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Error reading certificate request in newreq.pem 29809:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:746: Signed certificate is in newcert.pem 3??The CSR File is newreq.pem??it's content is below?? -BEGIN NEW CERTIFICATE REQUEST- MIIBnjCCAQcCAQAwXjELMAkGA1UEBhMCQ04xCzAJBgNVBAgTAmJqMQswCQYDVQQH EwJiajENMAsGA1UEChMEbWRjbDEMMAoGA1UECxMDbWdzMRgwFgYDVQQDEw9iam1v Y2hhLWh1YW5nd3AwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKrc553GG7Zr MwF4ZMpHFuKOQIt7f1XGLa0Cb2EFt+bAe5iXwg+bI9qOOy3p4UA7SRddzU8cCw5E miU076PI9eT2UsA1xwOxCJKAgYLQAjA04cgPzZ5w3EmvBYnxkawG+8PK5IvX2Voj JN+zV56BVMcEYLensOXv/lvdfIVZ3IADAgMBAAGgADANBgkqhkiG9w0BAQQFAAOB gQBR04JMtcpHZHEB+DlMiHS/466mvExHxVU6NuEmxdkXLhwpbjAqFBPDuWIahgv+ tv59ZhkpNQEcXr0YUKcfpx8g/8dw7MCbsg1gMHPkzQkhOLFJZBnJX7XuasR7HD63 8P1oYSNMXAuFttUt46z7iK1wBE3sq/u11MUljR0oBHukSw== -END NEW CERTIFICATE REQUEST- --- ??(http://space.sina.com.cn/ ) - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Realligning const void *data variables into 32-bit boundaries
On Fri, Dec 12, 2008 at 1:31 AM, Dave Thompson dave.thomp...@princetonpayments.com wrote: One note: type casting doesn't modify the pointer value (check your ANSI/ISO C89/C99 standard references). What you need is data at an 'aligned pointer'. Yes and no. Standard C allows different data pointer types to have [...] But (I believe) your point was that casting an unaligned pointer doesn't (reliably) make it aligned. That's true, and important. Yup, that was my point. The whole 'get me a properly aligned pointer' is system-specific activity anyhow and should be restricted to system-specific code (device drivers, that sort of thing). I wonder if that (i.e. 'alignment') is his _real_ trouble right now, but sometimes a little short-term scare helps a brain long term. ;-) Besides, on all alignment faulting/trapping/whatchamacallit platforms I've been, both malloc() and array declarations of the proper word type (and in case of 'dunno', it's 'long' or 'double' you can use) align on safe memory boundaries (malloc() takes care of that under the hood; the array decls are taken care of alignment-wise by the compiler), so the only 'real' alignment trouble you can run into these days is using char[] arrays and accessing it as int[] or other bigger types on hardware which doesn't like that, e.g. MC68K. i86 is very forgiving, but slows down a tad when you do that kind of thing. ... Not a very educational platform, i86 is, Yoda says. [backedit: sorry, reiterated of what you already said] (This is, of course, neglecting all the goodness regarding DMA ( / GPU bitblit) transfers, which are often 'sector'-aligned and other hardware-assisted activities.) // for C89: typedef unsigned charbyte; Did you mean this single line 'for C89' or the whole code? There is no difference between C89 and C99 as to a type named 'byte', so the typedef is equally needed in C99. (And // comments aren't C89!) (C99 library has new 'exact' types like uint8_least_t, only if you #include stdint.h or inttypes.h, but not any named byte.) Ha! That's what I get when banging my bongo keyboard late at night and people-in-the-know are watching! :-)) What I meant was 'uint8_t' instead of 'byte', all the way through. bows / Use unsigned. int is not necessarily big enough for (all) addresses [...] (unsigned)rawptr (wordsize-1) gives the same result and is almost always more efficient. And yes again. See lame 'late night' excuse above. Declaration after (executable) statement in a block is C99 or C++ only. Easily fixed; for that matter, we don't really need shift as a separate variable, I assume you just used it for greater explanatoryness. Yup. And combine that with total laziness. The major idea here was a curveball: see if I could trigger the brain into thinking 'hey, this alignment stuff is unusual, and now that I use it, the problem persists, so maybe it's not what I need, let's recheck my code and see if I fubar'ed a different sort of thing...' Your corrections clearly prove I shouldn't try 'fancy' while having other stuff on the brain as well (such as 'bed'). One benefit: if the intended message (the curveball) isn't coming through 20-20 (loud clear) by now, I don't now what will. Note that this method will give (byte*)rawptr+wordsize in the case rawptr is already aligned, which for _malloc it *usually* will be. BUG in my code - and a grievious mistake at that. :-( Wasn't my best day, yesterday. [added backedit line above] int shift = wordsize; shift -= ((int)rawptr) % wordsize; -- unsigned int shift = wordsize - 1; shift -= ((unsigned int)rawptr) % wordsize; Or, we can easily use (byte*)rawptr+0 in that 'special' case: al_ptr = ((unsigned)rawptr + wordsize-1) -wordsize; May I? nitpick: casting back to pointer is missing. I like the -wordsize (I always used ~wordsize, which is what you really want and identical for 2's complement signed int machines - do we still have the other kind around, BTW?) And I did the modulo-plus-pointer-shift thing above instead of this bit-masking-shoving-into-int-and-back-into-pointer (which is faster on all machines I know) to allow for those platforms where a pointer does not fit an int (or a long) (e.g. MSVC2005 64-bit i86: int/long = 32 bit, long long = 64 bit, but then 'long long' doesn't exist on older C89 environments, so harder to port (ahem). /* perform word-aligned operation: */ do_aligned_thing(); on al_ptr for srclen*wordsize, or maybe part(s) thereof, which you need to pass to it (either directly or indirectly). Indeed. That was left as an exercise for the reader. IF the aligned processing modified the data, need to copy it back. Don't forget _cleanse if appropriate and _free. So far, 'C class 102'. ;-) Now with free lecture notes as well. :-) Thanks for the exchange. Now I can cope with Friday morning again. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:
Re: [openssl.org #1753] snapshot 20081003 broke mingw build
Hello OpenSSL developers, Please merge these patches [2], [3] from bug [1]. Current cross compile is broken as the cpp used is not cross compile one. It causes mingw cross compile build to fail. I will be happy to know if there is something wrong, so I be able to provider better solution. Thanks, Alon. [1] http://rt.openssl.org/Ticket/Display.html?id=1753 [2] http://rt.openssl.org/Ticket/Attachment/20033/8783/openssl-001-SNAP-20081003-mingw.patch [3] http://rt.openssl.org/Ticket/Attachment/20033/8782/openssl-000-msys-symlink.patch __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Realligning const void *data variables into 32-bit boundaries
(getting rather offtopic now, so I've tried to keep it short) From: owner-openssl-...@openssl.org On Behalf Of Ger Hobbelt Sent: Friday, 12 December, 2008 05:12 On Fri, Dec 12, 2008 at 1:31 AM, Dave Thompson dave.thomp...@princetonpayments.com wrote: snip: about getting an aligned buffer Note that this method will give (byte*)rawptr+wordsize in the case rawptr is already aligned, which for _malloc it *usually* will be. BUG in my code - and a grievious mistake at that. :-( Wasn't my best day, yesterday. [added backedit line above] int shift = wordsize; shift -= ((int)rawptr) % wordsize; -- unsigned int shift = wordsize - 1; shift -= ((unsigned int)rawptr) % wordsize; Sorry, that's worse. That makes (byte*)rawptr +shift _always_ misaligned. Or, we can easily use (byte*)rawptr+0 in that 'special' case: al_ptr = ((unsigned)rawptr + wordsize-1) -wordsize; May I? nitpick: casting back to pointer is missing. I like the Yes, that's fair. But at least the compiler catches this one. -wordsize (I always used ~wordsize, which is what you really want and identical for 2's complement signed int machines - do we still have the other kind around, BTW?) No, those are quite different. Assuming (as before) that wordsize is a power of two, thus only one bit set in binary, wordsize-1 is all the bits below it, and -wordsize is all the bits at and above it. Done in unsigned arithmetic it doesn't matter whether the machine is 2sC or not, although as you imply in practice all are. Oops, I see wordsize wasn't unsigned -- either make it so, or cast it. Obviously its value should never be negative (or zero); that wouldn't make sense. ~wordsize is different, and unuseful here. 2sC -x is ~x PLUS ONE. (That's why some early machines preferred 1sC: you don't have to wait for carry propagation, as you do in 2sC, in the days when carry lookahead meant a whole extra rack of tubes or at least a board of diodes.) And I did the modulo-plus-pointer-shift thing above instead of this bit-masking-shoving-into-int-and-back-into-pointer (which is faster on all machines I know) to allow for those platforms where a pointer does not fit an int (or a long) (e.g. MSVC2005 64-bit i86: int/long = 32 bit, long long = 64 bit, but then 'long long' doesn't exist on older C89 environments, so harder to port (ahem). To be exact, where ptr doesn't fit any (safely) available UNSIGNED integer type. That's a good point. Then my method needs to be more like: /* assumes common uchar,uint, obvious fixes otherwise */ void* rawptr = malloc_or_whatever; uint good = ((uint)rawptr +wordsize-1) -/*(uint)*/wordsize ; uchar* al_ptr = (uchar*)rawptr + (good -(uint)rawptr); /* note the second and third terms are done in unsigned arithmetic, hence with wraparound, BEFORE adding the result to rawptr, which is vital when rounding up to next bit above uint's width; may prefer to shift that step to the line above to ensure less-skilled maintainers don't wrongly 'optimize' this. */ The other way that works mathematically (unsigned or 2sC) is: -( -(integer)rawptr -wordsize ) but IME this confuses many people, and ends up needing a comment bigger than just coding the other method, so I usually don't. Or if ptr doesn't fit in available unsigned integer: uint good = - (-(uint)rawptr -uwordsize); uchar* al_ptr = (uchar*)rawptr +(good -(uint)rawptr); but now it's confusing AND inelegant. Thanks for the exchange. Now I can cope with Friday morning again. I hate ALL mornings. You may notice my posts are late in the day (in Eastern US winter = -0500 if that isn't obvious). G __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
