[Date Prev][Date Next]
Re: (ITS#4868) Binary Attribute Patch(es)
Few preliminary comments follow.
> Version: 2.3.32
You should rather patch HEAD code instead of released, and even not the
latest. However, given the development rate of back-sql (~0), it
shouldn't really matter
> These address the use of Binary-valued attributes (#3113, #3386):
> For example, inetOrgPerson.userCertificate is usually transferred with the
> ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL.
Well, the solution you propose is not correct, since you are altering
schema data, which is supposed to be read-only. In any case, the point is:
- if we decide that back-sql should ignore tags, then the solution
consists in using the canonical name of the underlying AttributeType
when looking up data;
- however, this would destroy the possibility to use different storages
for differently encoded data; for example, a column for "cn;lang-en" and
a column for "cn;lang-jp". I don't know how many users would prefer one
solution over another, but in any case either we find a solution that
preserves both capabilities or we choose one. I'd vote in favor of
ignoring ";binary" since it's obsolete and related to transport only,
but in favor of honoring language tags.
> As well,
> the data itself, when stored in the database is not properly read out -- all
> data is read as SQL_C_CHAR data. This supports SQL_C_BINARY-based data.
This is just fine.
> There remains an issue with selecting attributes using, e.g.,
> "userCertificate;binary" -- nothing is returned. Someone with a better
> understanding of the attribute-processing method would be much more effective in
> terms of finding the correct place to remove the ";binary" from the
> "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name;
> "userCertificate" is the attribute-name, ";binary" is a transport directive (see
In fact, "userCertificate;binary" is the attribute description. The
attribute name is in ad_type->sat_cname.
> Additionally, I included to the patch to remove the "assert(0)" in Back-SQL's
> verification that a search filter and ldap-data don't mis-match on suffix.
Fine, but already fixed.
> Tags: OpenLDAP, Back-SQL, MySQL, userCertificate, Binary Attributes, Client
> Addressed ITS#4856 -- I think you already fixed this
> Address ITS#3113, ITS#3386
> Support for binary attribute values
> Addresses issue with accessing attributes that have been provided with
> ";binary" directive
> note that I have no doubts whatso ever that there are many better ways to do
You made an extensive use of C++ style comments, which are non portable.
Obviously you didn't read the contribution guidelines.
I'm testing (and improving) it.
Ing. Pierangelo Masarati
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA