Re: [RFC] Certificate validation helper

On 04.07.2012 12:11, Alex Rousskov wrote:
> On 07/03/2012 04:56 PM, Amos Jeffries wrote:
>> On 03.07.2012 14:59, Alex Rousskov wrote:
>>> On 07/02/2012 06:20 PM, Amos Jeffries wrote:
>>>>
>>>> I am in the process of modifying the helper API for consistency
>>>> across
>>>> all helpers starting with 3.3. It would be great if you could
>>>> design
>>>> your helper to use a generic output format for data sent back to
>>>> Squid:
>>>>
>>>> [channel-ID] (OK/ERR/BH) [key-pairs] <terminator>
>>>
>>> OK, but not all helper communication is line-based. We may need to
>>> send
>>> PEM-encoded certificates back (and ssl_crtd already does that).
>>> That
>>> requires sending multiline blocks of data.
>>>
>>> If you want to generalize that, consider adding body start/end
>>> terminators.
>>
>> I know. That is why I omit the word "line" and specify <terminator>
>> instead of <EOL>.
>
>
> The proposed format is missing the body itself, unless you want to
> force
> all helpers to use key=value format for blobs such as PEM-encoded
> certificates.

Oops. yes. The HelperReply object has to include a field <blob> of type
char* specific to each helper (for certs and bodies blobs, messages,
etc.) which includes everything between the first undentifiable key-pair
and the terminator. It is required for backward compatibility even if I
was set on key-pair always. So it may as well be formalised.

[channel-ID] (OK/ERR/BH) [key-pairs] <blob> <terminator>

> Ideally, there will be a way for generic helper parsers to
> detect and extract the body. To reach that ideal, there should be a
> common format that includes the body.
>

Yes.

Pedant: There are only 2 helpers out of 14 that send certificate
bodies. This new one and ssl_crtd. Why define a "body" field just for
them?

With [key-pair] before any helper-specific <blob>, we can add a
key-pair "cert=<foo>" for generic certificate passing around if/when
necessary.

>
>>> Do you want me to provide basic reusable classes for helper request
>>> formatting and response parsing, if I have a chance?
>>
>> I have one almost finished as a callback params object for replies.
>> As
>> soon as it passes all the build tests I'll be submitting a patch
>> before
>> starting to merge the parsers and extend the available response
>> key-pairs.
>>
>> If you want to make a generic one for requests that would help. It's
>> a
>> bit more complicated to get backward compatible due to the larger
>> syntax
>> variance between helper request formats.
>
> Understood.
>
> Alex.
Received on Wed Jul 04 2012 - 00:54:06 MDT