Re: [Firebird-devel] isc_database_info() and unknown info items
11.02.2020 18:18, Alex Peshkoff via Firebird-devel wrote: Return isc_info_error. One funny thing there is with this item: in IB API it is always named to be a single-byte tag the same as isc_info_end and isc_info_truncated while everywhere in code it is used as an ordinary info item with data containing one byte tag that caused the error and 4 bytes of ISC_STATUS code. I'm afraid that excessive returning of this code can blow up some user applications. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_database_info() and unknown info items
On 2020-02-11 19:22, Dimitry Sibiryakov wrote: Hello, All. In my own provider is it ok to silently ignore info items that are not applicable to the provider or isc_info_error must be returned? Return isc_info_error. Looks like client's code should be able to at least it. Something like this (from gbak): case isc_info_error: // old server does not understand new isc_info break; // parameter and returns isc_info_error. skip it Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] isc_database_info() and unknown info items
Hello, All. In my own provider is it ok to silently ignore info items that are not applicable to the provider or isc_info_error must be returned? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] No Firebird 4.0 snapshots
11.02.2020 15:28, Adriano dos Santos Fernandes wrote: Git Version: 2.24.0 Environment: PATH: contains location of git.exe So, the posix utilities should not be on the path. 7zip Version: 19.00 So 7zip is installed and can be used. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] No Firebird 4.0 snapshots
11.02.2020 15:03, Dmitry Yemanov wrote: The only question for me is whether it's going to work for automated GitHub builds on Windows. Do you have a shell access to that system? What is results of "where git" and "where unzip" commands? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] No Firebird 4.0 snapshots
On 11/02/2020 11:03, Dmitry Yemanov wrote: > > The only question for me is whether it's going to work for automated > GitHub builds on Windows. Do they have GitTools on the PATH and if not > whether such a dependency can be setup there. > > https://help.github.com/pt/actions/reference/software-installed-on-github-hosted-runners#windows-server-2016 Git Version: 2.24.0 Environment: PATH: contains location of git.exe So, the posix utilities should not be on the path. However sed and unix2dos works, so it's more about try. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] No Firebird 4.0 snapshots
Adriano et al, Adriano, could you please take a look whether it can be improved.First it would be good if the project decides if unzip should bedeclared as a new dependency and could be used or not.Personally, I don't like the argument about Git (along with GitTools) being a mandatory dependency. We (as well as GitHub release manager) still provide source tarballs and supposedly they should be buildable "as is", without any remote access to our repo.But that said, I don't see an unzip dependency being problematic. We had that for sed for many years and perhaps it looked inconvinient for somebody, but I don't remember it being a showstopper. The only question for me is whether it's going to work for automated GitHub builds on Windows. Do they have GitTools on the PATH and if not whether such a dependency can be setup there.DmitryFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] No Firebird 4.0 snapshots
On 11/02/2020 07:36, Dmitry Yemanov wrote: > > > Adriano, could you please take a look whether it can be improved. > First it would be good if the project decides if unzip should be declared as a new dependency and could be used or not. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] No Firebird 4.0 snapshots
10.02.2020 15:09, Mark Rotteveel wrote: Apparently the Linux snapshots were repaired, but there are still no snapshots under Windows. Is there any progress? The Windows snapshots are still broken. Fixed and uploaded, thanks for reminding. It appears that make_icu->zipjs path invokes unpacking asynchronously. And with slow disks, make_icu finishes before the archive is fully unpacked, thus causing a file-is-opened-by-another-process error immediately afterwards. I had to add a few seconds of timeout after make_icu before proceeding further. Adriano, could you please take a look whether it can be improved. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Key size of ChaCha20 implementation and interoperability with standard implementations
On 10-02-2020 17:19, Alex Peshkoff via Firebird-devel wrote: On 2020-01-26 16:01, Mark Rotteveel wrote: [..] Maybe instead the key should be stretched to 256 bit (eg using SHA256) instead? This would ensure that a 256 bit key is always used, and allows interoperability with implementations that only support 256 bit keys. In addition, this would reduce key length for auth plugins generating longer keys while not just discarding bits. In https://tools.ietf.org/html/rfc7539 I see the following: The ChaCha algorithm described here uses a 256-bit key. The original algorithm also specified 128-bit keys and 8- and 12-round variants, but these are out of scope for this document. I.e. I tend to agree that no matter of the fact that 128-bit is also absolutely acceptable variant of ChaCha 256-bit key is often treated as preferred one. Yes, we can stretch 20-byte key in some way and even avoid discarding bits using sha or some other way (128-bit key is just self concatenated in ChaCha). The only place that appears to have not one answer - what to do with exactly 128-bit key? If people provide that key from non-standard plugin they may expect using it according to chacha specification. On the other hand we loose generic approach and have all problems described by you earlier if we use std 128-bit key for chacha. Currently we do have 128-bit keys, they come from win_sspi. I see two possibilities: always stretch to 256 bit, and use the 256 bit variant of ChaCha, or define two plugins: chacha20-256 and chacha20-128, and define how keys should be stretched/reduced for both cases (eg using SHA-256, or using PBKDF2 or something like that). Then the client can select an appropriate/desired variant. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
