"Slow" cryptographic functions (hashes) for password derivation / stretching
(like PBDKF2, bcrypt, scrypt)
--
Key: CORE-6222
URL:
Hence why I reported
http://tracker.firebirdsql.org/browse/CORE-5788
and why SRP256 has been available from Firebird 3.0.4 onwards.
On 09/01/2020 17:25, marius adrian popa wrote:
> Actually, it shouldn't be this way because explicitly states that "`TIME`
> and `TIMESTAMP` are synonymous to theirs respectively `WITHOUT TIME ZONE`
> data types".
> --
> WBR, SD.
So sorry for my error, I will not do that againt (answering based on memory)
... only to find this was
10.01.2020 23:27, Evelyne Girard wrote:
In FB4, when adding a timestamp field it creates me timestamp_tz (32752).
normal?
Yes, unless you force FB4 to use previous versions default datatypes either
with (DataTypeCompatibility = 3.0 in Firebird.conf) or with set bind of
timestamp with time
> In FB4, when adding a timestamp field it creates me timestamp_tz (32752).
> normal?
Yes, unless you force FB4 to use previous versions default datatypes either
with (DataTypeCompatibility = 3.0 in Firebird.conf) or with set bind of
timestamp with time zone to legacy; (see README.set_bind.md
Without a doubt, SHA1 (like SHA) should not be used for digests. For
other applications, it's fine. For example, the Secure Remote Password
Protocol (SRP) uses SHA produce a fixed length hash of password, salt> on the server to compute a verifier and on the client
for subsequent
Hello
In FB4, when adding a timestamp field it creates me timestamp_tz
(32752). normal?
--
Norbert Saint Georges
http://tetrasys.fi
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
https://obartunov.livejournal.com/200076.html
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Hello!
I've made PR https://github.com/FirebirdSQL/firebird/pull/247
I left my comments there too.
Please, take a look.
--
Roman Simakov
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
If we forget that GPRE is used in the core, GPRE is just an utility that
calls the standard API and is not being updated with features or bug fixes.
It could be split to another sub-project and built. The built version
will probably work with whatever client/server is installed and will not
10.01.2020 15:17, Mark Rotteveel wrote:
My intent was more that if we remove it, that we should at least first
explicitly deprecate it and announce removal, and not just remove it
right now.
Agreed.
Dmitry
Firebird-Devel mailing list, web interface at
On 2020-01-10 09:57, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-10 11:24, Mark Rotteveel wrote:
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on
On 2020-01-10 11:24, Mark Rotteveel wrote:
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on GPRE for its own build, so in that sense, GPRE isn't
On 2020-01-09 14:10, Adriano dos Santos Fernandes wrote:
Better IMO: remove GPRE (and QLI) from the kits.
I don't really see why we should remove it right now. Firebird still
relies on GPRE for its own build, so in that sense, GPRE isn't
deprecated. And people still use GPRE, so removing it
Incorrect (throw-based) alloFunc for zlib1. Possible memory leak.
-
Key: CORE-6221
URL: http://tracker.firebirdsql.org/browse/CORE-6221
Project: Firebird Core
Issue Type: Bug
15 matches
Mail list logo
