Add provider property for dynamic loader flags

[astos-marcb]

In PE shared objects the search path can not be controlled by the loaded binary (in contrast to ELF). Resolving additional dependencies provided by 3rd party DLLs in the same folder as the primary PKCS11 module.

This is required to avoid workarounds as needed for e.g. the default vendor-provided YubiKey module.

[alonbl]

Hi, Thanks for the patch. I do not like adding shapi to dependencies as far as I understand it is not designed for backend, and magically detect relative does not mean that I would like this functionality.

First question: Why not just add the yubikey to PATH?

If we go this route, maybe add this to provider properties as option instead?

Regards,

[astos-marcb]

(Sorry, messed up my boolean.)

The PATH manipulation is always an option for advanced users. It's not an instruction I'd like to give to remote workers. In case of YubiKeys, in the current situation I would rather go with the OpenSC module (which compiles down to a singular DLL).

I just used a simple and existing approach for a first draft. Would you be more open to an approach like:

• use LoadLibraryEx with 0 flag by default (same behavior as LoadLibrary)
• add an option to set (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS)
• have the option provider determine if he wants
  • default behavior
  • set the option AND supply an absolute path (required by this flag combination)?

This does not change current behavior at all and shlwapi would not be involved (was only needed for PathIsRelative).

[alonbl]

Yes, it would be nice to have this as an option. But it would be the same advanced usage as PATH... :)

[astos-marcb]

Not sure I tackled all corner cases, but a with a (pending) OpenVPN patch it seems at least usable.

• no change to existing behavior (default loader flags)
• caller flags are used verbatim (special flags are never 0)

[alonbl]

Can you please revise?

On Fri, 9 Dec 2022 at 14:34 Marc Becker @.***> wrote:

@.**** commented on this pull request.

In lib/pkcs11h-core.c https://github.com/OpenSC/pkcs11-helper/pull/59#discussion_r1044412108:

void *p;

+#else

• DWORD loader_flags = 0;

No reservations from my side, was just cautious to not move magic values too far off their function calls (to have more/better context). Do you want to apply this on-the-fly or should I send a revised version?

— Reply to this email directly, view it on GitHub https://github.com/OpenSC/pkcs11-helper/pull/59#discussion_r1044412108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJURLKD5BT553DM62GF2PDWMMRO5ANCNFSM54LIQIRA . You are receiving this because you commented.Message ID: @.***>

[alonbl]

Thank you!

[selvanair]

@alonbl This seems to have been accepted but not merged yet. Can we assume that this will eventually be available in a future release?

[alonbl]

On Mon, Jan 2, 2023 at 6:53 AM Selva Nair @.***> wrote:

@alonbl https://github.com/alonbl This seems to have been accepted but not merged yet. Can we assume that this will eventually be available in a future release?

Oh, I am sorry, I did not push it to the public repo. Should be fine now.

Message ID: @.***>