On Tue, Dec 26, 2017 at 03:28:09PM -0500, Peter Eisentraut wrote:
> On 12/22/17 03:10, Michael Paquier wrote:
> > Second thoughts on 0002 as there is actually no need to move around
> > errorMessage if the PGconn* pointer is saved in the SCRAM status data
> > as both are linked. The attached simplifies the logic even more.
> >
>
> That all looks pretty reasonable.
Thanks for the review. Don't you think that the the refactoring
simplifications should be done first though? This would result in
producing the patch set in reverse order. I'll be fine to produce them
if need be.
> I'm working through patch 0001 now. I haven't found any documentation
> on the function OBJ_find_sigid_algs(). What does it do? One might
> think that the nid returned by X509_get_signature_nid() is already the
> algo_nid we want to use, but there appears to be more to this.
All the objects returned by X509_get_signature_nid() are listed in
crypto/objects/obj_dat.h which may include more information than just
the algorithm type, like for example if RSA encryption is used or not,
etc. I found about the low-level OBJ_find_sigid_algs() to actually get
the real hashing algorithm after diving into X509* informations. And by
looking at X509_signature_print() I found out that this returns the
information we are looking for. This has the damn advantage that we rely
on a minimal lists of algorithms and we don't need to worry about any
future options linked with X509_get_signature_nid(), so this simplifies
Postgres code as well as long-term maintenance.
--
Michael
