On 10/05/2016 07:56 AM, Richard Levitte via RT wrote: > To be noted, there's more in section 2: > > Most extant parsers ignore blanks at the ends of lines; blanks at the > beginnings of lines or in the middle of the base64-encoded data are > far less compatible. These observations are codified in Figure 1. > The most lax parser implementations are not line-oriented at all and > will accept any mixture of whitespace outside of the encapsulation > boundaries (see Figure 2). Such lax parsing may run the risk of > accepting text that was not intended to be accepted in the first > place (e.g., because the text was a snippet or sample). > > I haven't looked enough in our code recently to remember if we're doing > "standard" (figure 1) or "strict" (figure 3) parsing... what I hear is a > request for us to move to "lax" (figure 2) parsing. >
If I remember correctly, it's somewhere in between. The core PEM-parsing code is vintage EAY, and contains some "interesting" behavior, like going to the end of the line/buffer that was read, backtracking past any characters with ASCII value less than or equal to that of <space>, and writing \n\0. So, it seems like trailing whitespace would be ignored, but leading whitespace would trip up the "len == 65" check later on. I refactored this stuff a while ago to add a flags field that would force the temporary read buffer to be allocated from the secure heap; I should really dig it up and clean it up for master. -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
