On Mon, Jul 22, 2024 at 2:43 AM Stefan Oltmanns via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > > Am 22.07.24 um 00:15 schrieb Hendrik Leppkes: > > On Mon, Jul 22, 2024 at 12:08 AM Stefan Oltmanns via ffmpeg-devel > > <ffmpeg-devel@ffmpeg.org> wrote: > >> > >> Am 18.07.24 um 17:23 schrieb epira...@gmail.com: > >>> > >>>>> > >>>>> Well, the DLL directory is added to PATH by the VapourSynth installer, > >>>>> but for safety reasons ffmpeg explictly tells the LoadLibrary function > >>>>> to only search the application directory and system32, quote from > >>>>> w32dlfcn.h: > >>>>> > >>>>>> /** > >>>>>> * Safe function used to open dynamic libs. This attempts to improve > >>>>>> program security > >>>>>> * by removing the current directory from the dll search path. Only > >>>>>> dll's found in the > >>>>>> * executable or system directory are allowed to be loaded. > >>>>>> * @param name The dynamic lib name. > >>>>>> * @return A handle to the opened lib. > >>>>>> */ > >>>>> So ffmpeg prevents that solution on purpose. Or should that behavior be > >>>>> changed in the w32dlfcn.h? > >>>> > >>>> Oh, bummer. I would expect that overriding the PATH environment > >>>> variable would work kind of like how LD_LIBRARY_PATH works on Linux. I > >>>> don't know why that was changed. I don't really follow what goes on in > >>>> Windowsland anymore. Does anyone else care to comment on this? Martin, > >>>> maybe? > >>> > >>> IIRC this is done to prevent DLL injection attacks > >>> > >>> https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security > >>> > >> > >> So what's your proposal how to continue? > >> > >> I see different options with pros&cons: > >> > >> > >> 1. > >> Read the DLL path from registry, function for that could be located > >> outside the VapourSynth module. > >> > >> Pro: Safest method to protect from DLL-injection > >> Con: A lot of custom code/functionality for Windows > >> > > > > Relaxing security considerations to avoid a 10 line function seems not > > worth it to me. So go with actually finding the correct path. > > > > Ok, should that function remain in the vapoursynth module, or should > handling the registry be done in a header like "compat/w32registry.h"? > > An external file with a universal function would of course require more > code. >
Just have it in vapoursynth. Compat would be the wrong place for it, but in general I don't think we're going to need a lot of registry access in the future. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
