Re: [Maria-discuss] Introduction and Task Suggestion

[Hemant Kumar Singh]

Thanks!

So, this is what Igor mentioned in MDEV-13648 thread:
> For those of you who are preparing proposals for this project:
> In your proposal you are expected to cover the following issues:
> 1. How to build the tree for the result of re-writing for a join expression 
> with FULL OUTER JOIN.
> (It's not trivial as the parser provides you only with one tree that can be 
> easily transformed into a
> tree either for LEFT OUTER JOIN or for RIGHT OUTER JOIN, but not for both and 
> you need the
> trees for two SELECTs, not just for one. You can get an idea how you could 
> build the
> tree for the second SELECT in sql_view.cc).
> 2. At what stage to do the re-writing: at the parser stage, at the beginning 
> of the context analysis
> stage (see JOIN::prepare or at the beginning of the optimization stage (see 
> JOIN::optimizer).
> 3. How to handle embedded FULL OUTER JOINs.
> 4. How and when to check possible conversion to LEFT OUTER JOIN or RIGHT 
> OUTER JOIN.
> 5. What adjustments must be done for different references to the tables used 
> in the original join
> expression with FULL OUTER JOIN that may occur outside of this expression.

So, if we stick to point 1&2 will it make it comparable to other projects? 
Ofcourse, I'll try to complete the rest too, but for defining the sub-task as 
of now; will this suffice?
Regards,
Hemant Kumar Singh
https://iamhks.com 
(https://link.getmailspring.com/link/6f54a257-ada3-4e97-a25e-1dc701b96...@getmailspring.com/0?redirect=https%3A%2F%2Fiamhks.com=bWFyaWEtZGlzY3Vzc0BsaXN0cy5sYXVuY2hwYWQubmV0)

On Mar 14 2021, at 5:25 pm, Sergei Golubchik  wrote:
> Hi, Hemant!
>
> On Mar 14, Hemant Kumar Singh wrote:
> > Hi everyone,
> > I am Hemant from Nepal, currently a Computer Science Junior at NIT
> > Warangal, India willing to take part in GSoC 2021.
> >
> > I saw a major priority task "MDEV-13648- Add FULL OUTER JOIN to
> > MariaDB" unresolved since gsoc 2019; but it's not listed in 2021 List
> > of Ideas. So, I was just wondering whether I can contribute to this
> > task for gsoc 2021. Can anyone confirm this?
>
> Yes, you absolutely can, and it's great that you're looking beyond
> what's listed on our "GSoC 2021" page of suggestions.
>
> The thing is - GSoC rules were changed this year and there is less time
> for coding than before. So in 2021 we offer smaller tasks that can
> reasonably fit within the new GSoC format.
>
> For MDEV-13648, I think, we need to define some subtask, so that if you
> implement that, the project would be still a success, even if you won't
> have time for the full MDEV-13648. So - totally possible, and it'd be
> perfect if you'll manage to do it all. But to make it comparable with
> other tasks we should define this intermediate milestone within
> MDEV-13648.
>
> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and secur...@mariadb.org
>

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Is it possible to upgrade SHA-1 and MD5 algorithms in Mariadb-10.5?

[Sergei Golubchik]

Hi, Lukas!

On Mar 19, Lukas Javorsky wrote:
> 
> The main functions that are important for us is the password hashing,
> certificate fingerprinting in mariadb-connector-c which uses SHA-1 or
> MD5

Neither password hashing nor certificate fingerprinting, as far as I can
see, use MD5.

Password hashing, indeed, uses SHA-1. It's still secure, as far as I
know, but I understand that you're likely just need a checkbox "no
SHA-1 inside". Please, create a feature request at jira.mariadb.org for
that (use type=task, project=MDEV).

Certificate fingerprinting in mariadb-connector-c also uses SHA-1.
If think it might make sense to allow other digest algorithms too.
Please, create a feature request at jira.mariadb.org (project=CONC).

Regards,
Sergei
VP of MariaDB Server Engineering
and secur...@mariadb.org

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Is it possible to upgrade SHA-1 and MD5 algorithms in Mariadb-10.5?

[Lukas Javorsky]

> What do you mean by "upgrade SHA-1 and MD5 algorithms in MariaDB" ?

Sorry for misleading terminology Sergei.
What I meant was to change this algorithm to something newer, and most
importantly more secure.

There is an article  about breaking the
SHA-1 which is dated to 2020 and it explains the vulnerability of this
algorithm.

RHEL also adheres to Government standards like FIPS 140-2, which permits
the use of SHA-1 for verification of legacy signatures.
That may not be the case of mariadb, however, our goal is to
eliminate every possible weakness of the algorithms used in packages.

The main functions that are important for us is the password hashing,
certificate fingerprinting in mariadb-connector-c which uses SHA-1 or MD5

Please let me know what you think.
Lukas

On Fri, Mar 19, 2021 at 1:48 AM Daniel Black  wrote:

> md5:
>
> extra/mariabackup/xbcloud.cc - old bit, however for old reasons used md5
> as a checksum on a storage format. I'm think can be removed before RHEL9
>
> In SQL there is a MD5 function, we can't just replace that as it will
> break user applications.
>
> sha1:
>
> also a SQL function.
>
> plugin/file_key_management/parser.cc is a digest on the keys, however if
> this is a point of attack you've lost already. I suspect this can be fixed.
>
> sha1 forms part of the mysql_native_password implementation, there's no
> known vulnerabilities in this due to its sha1 usage.
>
> https://mariadb.com/kb/en/authentication-plugin-ed25519/ is available,
> however not everything supports in on the client side.
> A mistake was also made (ref MDEV-19217), so a v2 might be needed.
>
> As things like php have mysqlnd and are more strictly tied to MySQL rather
> than MariaDB compatibility so adding MariaDB authentication
> plugins hasn't been accepted yet.
>
> On SQL functions, is this going to be a problem? or would a compile option
> that issues a user SQL warning if they are used be useful?
>
>
>
>
> On Thu, Mar 18, 2021 at 2:29 PM Eliezer Croitoru 
> wrote:
>
>> Hey Sergei,
>>
>> I cannot speak in the name of Lukas but I assume that he is talking about
>> the payload signature of RPM files.
>> Technically speaking SHA1 and MD5 can collide but only to specific file
>> sizes.
>> It's not that simple to create an RPM in a size of 10+ MB which will
>> provide the exact same
>> functionality ie DB which will include errors and/or other things.
>>
>> I know it's pretty simple to upgrade the signature so I do not find any
>> reason to not add a SHA256 sig.
>>
>> All The Bests,
>> Eliezer
>>
>> 
>> Eliezer Croitoru
>> Tech Support
>> Mobile: +972-5-28704261
>> Email: ngtech1...@gmail.com
>> Zoom: Coming soon
>>
>>
>> -Original Message-
>> From: Maria-discuss > gmail@lists.launchpad.net> On Behalf Of Sergei Golubchik
>> Sent: Wednesday, March 17, 2021 5:24 PM
>> To: Lukas Javorsky 
>> Cc: maria-discuss@lists.launchpad.net
>> Subject: Re: [Maria-discuss] Is it possible to upgrade SHA-1 and MD5
>> algorithms in Mariadb-10.5?
>>
>> Hi, Lukas!
>>
>> What do you mean by "upgrade SHA-1 and MD5 algorithms in MariaDB" ?
>>
>> Regards,
>> Sergei
>> VP of MariaDB Server Engineering
>> and secur...@mariadb.org
>>
>> On Mar 17, Lukas Javorsky wrote:
>> > Hi,
>> >
>> > In RHEL-9 we are deprecating, old SHA-1 and MD5 and that's why I want to
>> > ask you if there is any chance that upstream is going to change it, or
>> we
>> > should do it downstream.
>> >
>> > These algorithms are no longer considered as safe, so it may be a good
>> > thing to upgrade them.
>> >
>> > AFAIK mariadb uses these algorithms in *mariadb* and
>> *mariadb-connector-c.*
>> >
>> > Also if you have no intention to change it, is there any chance you
>> could
>> > help us somehow. Maybe point out what we should be aware of.
>> >
>> > Please let me know what you think
>> >
>> > Lukas
>> >
>> > --
>> > S pozdravom/ Best regards
>> >
>> > Lukáš Javorský
>> >
>> > Associate Software Engineer, Core service - Databases
>> >
>> > Red Hat 
>> >
>> > Purkyňova 115 (TPB-C)
>> >
>> > 612 00 Brno - Královo Pole
>> >
>> > ljavo...@redhat.com
>> > 
>>
>> ___
>> Mailing list: https://launchpad.net/~maria-discuss
>> Post to : maria-discuss@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~maria-discuss
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~maria-discuss
>> Post to : maria-discuss@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~maria-discuss
>> More help   : https://help.launchpad.net/ListHelp
>>
>

-- 
S pozdravom/ Best regards

Lukáš Javorský

Associate Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
Mailing 

Re: [Maria-discuss] Is it possible to upgrade SHA-1 and MD5 algorithms in Mariadb-10.5?

[Reindl Harald]

Am 19.03.21 um 01:47 schrieb Daniel Black:

md5:

extra/mariabackup/xbcloud.cc - old bit, however for old reasons used md5 
as a checksum on a storage format. I'm think can be removed before RHEL9


In SQL there is a MD5 function, we can't just replace that as it will 
break user applications.


sha1:

also a SQL function.

plugin/file_key_management/parser.cc is a digest on the keys, however if 
this is a point of attack you've lost already. I suspect this can be fixed.


sha1 forms part of the mysql_native_password implementation, there's no 
known vulnerabilities in this due to its sha1 usage.


https://mariadb.com/kb/en/authentication-plugin-ed25519/ 
 is available, 
however not everything supports in on the client side.

A mistake was also made (ref MDEV-19217), so a v2 might be needed.

As things like php have mysqlnd and are more strictly tied to MySQL 
rather than MariaDB compatibility so adding MariaDB authentication

plugins hasn't been accepted yet.

On SQL functions, is this going to be a problem? or would a compile 
option that issues a user SQL warning if they are used be useful?


sql functions for sure not matter in that context

besides it would break existing usecases it also would require to change 
applications workign with that data *and* replace the hases with some 
others in *existing* data which is a no-go


--

md5/sha1 are not evil on it's own - it's a matter of what they are used 
for, i have usecases where even MD4 is enough and i use it because it's 
simply faster


it's unlikely in my md4 usecase making sure in autotests that html 
output out of frameworks didn't change to hit a hash-collision at the 
same time a single html attribute in a source code changed


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp