Re: [Firebird-devel] Sanity checks for methods' parameters in Y-valve
On 9/15/22 18:56, Dimitry Sibiryakov wrote: Hello All. If someone by mistake calls IStatement::execute() providing metadata but no data buffer, it will pass the values as is to a provider and overall result will be segfault. Shouldn't some sanity checks to be performed there? Not sure. Check for nullptr is really simple but what if user sends garbage instead data buffer address? Luckily that segfault will never disturb remote server - only client or embedded which can suffer same way from any segfault in user process. I do not want to say segfault is good thing and will not provide as a sample trivial things like strcpy() - but almost any function in C library will segfault when passed wrong address of some data. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Sanity checks for methods' parameters in Y-valve
Hello All. If someone by mistake calls IStatement::execute() providing metadata but no data buffer, it will pass the values as is to a provider and overall result will be segfault. Shouldn't some sanity checks to be performed there? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 17:18, Dimitry Sibiryakov wrote: Alex Peshkoff via Firebird-devel wrote 15.09.2022 16:14: On the other hand tomcrypt is successfully used in our sample plugin - which is problematic with static linking. For me that appears more interesting and useful. Not to say about code duplication. Dead code elimination with static libraries work at module level so there is no significant duplication. Crypt modules are tiny. We do not include crypt algorithms not needed for firebird when building tomcrypt (library's customization is used). Therefore there is not too much effect from code elimination. May be in client-only case... But have you seen a lot of clients running linux? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
Alex Peshkoff via Firebird-devel wrote 15.09.2022 16:14: On the other hand tomcrypt is successfully used in our sample plugin - which is problematic with static linking. For me that appears more interesting and useful. Not to say about code duplication. Dead code elimination with static libraries work at module level so there is no significant duplication. Crypt modules are tiny. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 17:07, Dimitry Sibiryakov wrote: Alex Peshkoff via Firebird-devel wrote 15.09.2022 12:04: With tommath there are no such issues... Why don't force build with static libs? In what way it's better than own dynamic libraries? Surely no problem with API/ABI. Therefore we link some problematic libraries statically. No mess and vulnerability with dynamic library search path. I see no mess with it but it depends on POV No multiplying of points above with every third-party plugin. May be - never used to deal with third-party plugins myself. On the other hand tomcrypt is successfully used in our sample plugin - which is problematic with static linking. For me that appears more interesting and useful. Not to say about code duplication. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
Alex Peshkoff via Firebird-devel wrote 15.09.2022 12:04: With tommath there are no such issues... Why don't force build with static libs? In what way it's better than own dynamic libraries? Surely no problem with API/ABI. No mess and vulnerability with dynamic library search path. No multiplying of points above with every third-party plugin. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 16:38, Mark Rotteveel wrote: On 15-09-2022 15:19, Alex Peshkoff via Firebird-devel wrote: On 9/15/22 14:36, Adriano dos Santos Fernandes wrote: On 15/09/2022 08:18, Alex Peshkoff via Firebird-devel wrote: This is solved by install script - it creates symlink to /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory (provided it's missing). If we decide to _always_ provide own dynamic libraries (logically it's like using static one but does not require duplicating code) this trick becomes not needed any more. Let me remind you that this thread started with me noticing an inconsistency in how we build things when explicitly building with --with-builtin-tommath compared to the - in my opinion - more sane behaviour of --with-builtin-tomcrypt (putting things in gen/buildroot/usr/local/firebird/lib/.tm vs in gen/buildroot/usr/local/firebird/lib). I was not asking about always using our own libraries, but at least doing things in a sane way when a build is performed explicitly requesting to use our own version of libraries. We need another switch for requested behavior. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 15-09-2022 15:19, Alex Peshkoff via Firebird-devel wrote: On 9/15/22 14:36, Adriano dos Santos Fernandes wrote: On 15/09/2022 08:18, Alex Peshkoff via Firebird-devel wrote: This is solved by install script - it creates symlink to /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory (provided it's missing). If we decide to _always_ provide own dynamic libraries (logically it's like using static one but does not require duplicating code) this trick becomes not needed any more. Let me remind you that this thread started with me noticing an inconsistency in how we build things when explicitly building with --with-builtin-tommath compared to the - in my opinion - more sane behaviour of --with-builtin-tomcrypt (putting things in gen/buildroot/usr/local/firebird/lib/.tm vs in gen/buildroot/usr/local/firebird/lib). I was not asking about always using our own libraries, but at least doing things in a sane way when a build is performed explicitly requesting to use our own version of libraries. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 15-09-2022 13:13, Adriano dos Santos Fernandes wrote: On 15/09/2022 07:52, Mark Rotteveel wrote: On 15-09-2022 03:52, Adriano dos Santos Fernandes wrote: On 05/09/2022 08:13, Mark Rotteveel wrote: That is not really embedded IMHO. Firebird Embedded with Firebird 3.0 has become unwieldy and even harder to use than earlier versions, especially if you compare it to other embedded database systems. How it become harder? Basically, in Firebird 2.5 and earlier, you needed fbembed.dll / libfbembed.so and the intl folder, and you were done. Now you need a whole constellation of files. Despite the problem with system libraries, which in many cases we could use static versions (I believe we cannot only with ICU), dealing with dozen of files has the same complexity of dealing with 2. In some ways yes, in others not. Other embedded database are basically on DLL/.so and you're done. Other that are *embedded only* or that can also be used (and focus on it) as a server like Firebird? Embedded only. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 14:36, Adriano dos Santos Fernandes wrote: On 15/09/2022 08:18, Alex Peshkoff via Firebird-devel wrote: On 9/15/22 14:00, Adriano dos Santos Fernandes wrote: Em qui., 15 de set. de 2022 07:06, Alex Peshkoff via Firebird-devel escreveu: > > Why don't force build with static libs? > In what way it's better than own dynamic libraries? Not put files in system lib outside of a package manager. Using own dynamic libraries does not require putting something into system lib . I'm talking about this: This is solved by install script - it creates symlink to /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory (provided it's missing). If we decide to _always_ provide own dynamic libraries (logically it's like using static one but does not require duplicating code) this trick becomes not needed any more. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 15/09/2022 08:18, Alex Peshkoff via Firebird-devel wrote: > On 9/15/22 14:00, Adriano dos Santos Fernandes wrote: >> Em qui., 15 de set. de 2022 07:06, Alex Peshkoff via Firebird-devel >> escreveu: >> >> > >> > Why don't force build with static libs? >> > >> >> In what way it's better than own dynamic libraries? >> >> >> >> Not put files in system lib outside of a package manager. >> > > Using own dynamic libraries does not require putting something into > system lib . > I'm talking about this: > This is solved by install script - it creates symlink to /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory (provided it's missing). Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 14:00, Adriano dos Santos Fernandes wrote: Em qui., 15 de set. de 2022 07:06, Alex Peshkoff via Firebird-devel escreveu: > > Why don't force build with static libs? > In what way it's better than own dynamic libraries? Not put files in system lib outside of a package manager. Using own dynamic libraries does not require putting something into system lib . Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 15/09/2022 07:52, Mark Rotteveel wrote: > On 15-09-2022 03:52, Adriano dos Santos Fernandes wrote: >> On 05/09/2022 08:13, Mark Rotteveel wrote: >>> That is not really embedded IMHO. Firebird Embedded with Firebird 3.0 >>> has become unwieldy and even harder to use than earlier versions, >>> especially if you compare it to other embedded database systems. >> >> How it become harder? > > Basically, in Firebird 2.5 and earlier, you needed fbembed.dll / > libfbembed.so and the intl folder, and you were done. Now you need a > whole constellation of files. > Despite the problem with system libraries, which in many cases we could use static versions (I believe we cannot only with ICU), dealing with dozen of files has the same complexity of dealing with 2. > Other embedded database are basically on DLL/.so and you're done. > Other that are *embedded only* or that can also be used (and focus on it) as a server like Firebird? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
Em qui., 15 de set. de 2022 07:06, Alex Peshkoff via Firebird-devel < firebird-devel@lists.sourceforge.net> escreveu: > > > > Why don't force build with static libs? > > > > In what way it's better than own dynamic libraries? > Not put files in system lib outside of a package manager. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 15-09-2022 03:52, Adriano dos Santos Fernandes wrote: On 05/09/2022 08:13, Mark Rotteveel wrote: That is not really embedded IMHO. Firebird Embedded with Firebird 3.0 has become unwieldy and even harder to use than earlier versions, especially if you compare it to other embedded database systems. How it become harder? Basically, in Firebird 2.5 and earlier, you needed fbembed.dll / libfbembed.so and the intl folder, and you were done. Now you need a whole constellation of files. Other embedded database are basically on DLL/.so and you're done. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 12:30, Dimitry Sibiryakov wrote: Alex Peshkoff via Firebird-devel wrote 15.09.2022 11:08: Also, it's different in the sense that official package builds and package tomcrypt, but not tommath. We did discuss sometimes ago why for universal binary package we have to use built-in tomcrypt. Data structures, passed In it's API, depend upon compilation flags. It's pretty easy to get an error in API call or even segfault due to it. Myself lost a lot of time when started to work with it and did not have correct defines when included tomcrypt.h. (At least it was so 5 years ago - may be fixed in fresh versions?) With tommath there are no such issues... Why don't force build with static libs? In what way it's better than own dynamic libraries? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
Alex Peshkoff via Firebird-devel wrote 15.09.2022 11:08: Also, it's different in the sense that official package builds and package tomcrypt, but not tommath. We did discuss sometimes ago why for universal binary package we have to use built-in tomcrypt. Data structures, passed In it's API, depend upon compilation flags. It's pretty easy to get an error in API call or even segfault due to it. Myself lost a lot of time when started to work with it and did not have correct defines when included tomcrypt.h. (At least it was so 5 years ago - may be fixed in fresh versions?) With tommath there are no such issues... Why don't force build with static libs? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath
On 9/15/22 04:52, Adriano dos Santos Fernandes wrote: On 05/09/2022 08:13, Mark Rotteveel wrote: On 05-09-2022 13:00, Alex Peshkoff via Firebird-devel wrote: When adding it I cared about an ability to fix secirtiy issues in 3d-party libraries not rebuilding and reinstalling FB packages. With used schema one can simply install fixed system package for tommath in a case of some issues in it. None were found - but that was when tommath was at pre-release stage. I find these inconsistencies quite confusing, but lets leave it at that. Also, it's different in the sense that official package builds and package tomcrypt, but not tommath. We did discuss sometimes ago why for universal binary package we have to use built-in tomcrypt. Data structures, passed In it's API, depend upon compilation flags. It's pretty easy to get an error in API call or even segfault due to it. Myself lost a lot of time when started to work with it and did not have correct defines when included tomcrypt.h. (At least it was so 5 years ago - may be fixed in fresh versions?) With tommath there are no such issues... Should this be changed and be consistent in FB 5, i.e., build and package both? May be it's really simplest solution... Let's first check stability of current tomcrypt API - may be it's OK now and we may do not package both libraries. BTW, we always recommended to those who need embedded-only access full install (classic) and server stop. Embedded (just built, not installed) works very ok for me. What should be the problem? Lock directory access only? Yes, group firebird should be created. In a case when single-user access is needed - everything works fine w/o it. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
