Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Przemysław Nogaj via Development]

+1 for moving those to separate repo (as basically those are more sophisticated 
examples)

The only question I've is Neptune3 UI still being kept alive (those were 
consumed there


--​

Przemysław Nogaj

Head of HMI Technology



t:   +48 729 043 291
m: p...@spyro-soft.com
w: www.spyro-soft.com | 
LinkedIn




From: Development  on behalf of Maurice 
Kalinowski via Development 
Sent: Thursday, December 7, 2023 8:01:40 PM
To: Tor Arne Vestbø ; Tuukka Turunen 

Cc: Macieira, Thiago ; development@qt-project.org 

Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs

⚠ This email originates from outside the organization or the sender could not 
be verified.

You are absolutely correct that this module started with a pure automotive 
focus, back then called Qt IVI.

However, we recognized that its functionality can also be utilized in a generic 
way, which was the reason for the rename and generalization efforts done in the 
past. There might still be some leftovers.



There are developers/customers using it in their production environment 
already, also outside of the automotive sector.



BR,

Maurice





From: Development  On Behalf Of Tor Arne 
Vestbø via Development
Sent: Thursday, 7 December 2023 18:37
To: Tuukka Turunen 
Cc: Macieira, Thiago ; development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs



If it’s an option to rename this module we should take the opportunity to do so 
I think.



The problem of the generic naming came up in the past, but the understanding 
was that it was too late to change.



If that is not the case after all, we should strongly consider it.



The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:



"The Qt Interface Framework module provides both the tools and the core APIs, 
for you to implement Middleware APIs, Middleware Back ends, and Middleware 
Services. “



So is this the Qt Middleware module?



On the other hand, the module seems to also provide a lot more than just core 
primitives. E.g. this set of classes for in-viechle infotainment systems:



https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html




So is this a Qt for Automotive specific module? These APIs seem to indicate 
that as well:



https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html



If we do want to promote this to a Qt module, should the core functionality be 
split off, and the rest stay Qt for Automotive specific?



https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html



Cheers,

Tor Arne



On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
mailto:development@qt-project.org>> wrote:



Hi,



Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).



That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.



So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?



Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.



Yours,



Tuukka



From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs

On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But 

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Elvis Stansvik]

Just to add another minor downside to the current name: qtif and qtifw
are already quite common shorthands for Qt Installer Framework in
search keywords / discussions.

Elvis

Den tors 7 dec. 2023 kl 20:03 skrev Maurice Kalinowski via Development
:
>
> You are absolutely correct that this module started with a pure automotive 
> focus, back then called Qt IVI.
>
> However, we recognized that its functionality can also be utilized in a 
> generic way, which was the reason for the rename and generalization efforts 
> done in the past. There might still be some leftovers.
>
>
>
> There are developers/customers using it in their production environment 
> already, also outside of the automotive sector.
>
>
>
> BR,
>
> Maurice
>
>
>
>
>
> From: Development  On Behalf Of Tor Arne 
> Vestbø via Development
> Sent: Thursday, 7 December 2023 18:37
> To: Tuukka Turunen 
> Cc: Macieira, Thiago ; development@qt-project.org
> Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
> Reference APIs
>
>
>
> If it’s an option to rename this module we should take the opportunity to do 
> so I think.
>
>
>
> The problem of the generic naming came up in the past, but the understanding 
> was that it was too late to change.
>
>
>
> If that is not the case after all, we should strongly consider it.
>
>
>
> The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:
>
>
>
> "The Qt Interface Framework module provides both the tools and the core APIs, 
> for you to implement Middleware APIs, Middleware Back ends, and Middleware 
> Services. “
>
>
>
> So is this the Qt Middleware module?
>
>
>
> On the other hand, the module seems to also provide a lot more than just core 
> primitives. E.g. this set of classes for in-viechle infotainment systems:
>
>
>
> https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html
>
>
>
> So is this a Qt for Automotive specific module? These APIs seem to indicate 
> that as well:
>
>
>
> https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html
>
>
>
> If we do want to promote this to a Qt module, should the core functionality 
> be split off, and the rest stay Qt for Automotive specific?
>
>
>
> https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html
>
>
>
> Cheers,
>
> Tor Arne
>
>
>
> On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
>  wrote:
>
>
>
> Hi,
>
>
>
> Thiago is right, we can change the name as the module technically is not part 
> of Qt release 
> (https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).
>
>
>
> That said, we can also decide not to change the name. Like mentioned by 
> Dominik, it has existing since a while with the current name 
> (https://doc.qt.io/QtInterfaceFramework/) and repository 
> (https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
> different name, so the current one is already a new name, which is probably 
> better than the initial at least.
>
>
>
> So the question is what should this module be called, if it would be renamed? 
> And another question, is it feasible to implement the renaming at this point?
>
>
>
> Moving the proposed items out from it to labs modules makes sense to me. The 
> naming of labs modules should then be aligned with the new naming of the 
> module.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
> From: Development  on behalf of Thiago 
> Macieira 
> Date: Tuesday, December 5, 2023 at 19:06
> To: development@qt-project.org 
> Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
> Reference APIs
>
> On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> > Then why are you asking for a repository if it's already there? When was
> > that module approved by the Qt Project? I can't find anything in the email
> > archives.
> >
> > The first commit in this repository is "First version of the QtGeniviExtras
> > module". When was it renamed and who approved it?
>
> This module was requested at
> https://lists.qt-project.org/pipermail/development/2015-August/022859.html
>
> There were no objections. Tuukka said it's a good idea to have the modules
> even if they aren't part of the released packages:
>
> > I think it is fine to create the requested repo for new module. Depending on
> > the need it can then either be included or not be included in the release
> > packages.
>
> That would explain why this isn't in the qt5.git/.gitmodules.
>
> But I said:
>
> > I am, however, questioning the design of the API that Dominik presented.
>
> There have been zero other discussions of "genivi" since then
> 

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Maurice Kalinowski via Development]

You are absolutely correct that this module started with a pure automotive 
focus, back then called Qt IVI.
However, we recognized that its functionality can also be utilized in a generic 
way, which was the reason for the rename and generalization efforts done in the 
past. There might still be some leftovers.

There are developers/customers using it in their production environment 
already, also outside of the automotive sector.

BR,
Maurice


From: Development  On Behalf Of Tor Arne 
Vestbø via Development
Sent: Thursday, 7 December 2023 18:37
To: Tuukka Turunen 
Cc: Macieira, Thiago ; development@qt-project.org
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs

If it’s an option to rename this module we should take the opportunity to do so 
I think.

The problem of the generic naming came up in the past, but the understanding 
was that it was too late to change.

If that is not the case after all, we should strongly consider it.

The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:

"The Qt Interface Framework module provides both the tools and the core APIs, 
for you to implement Middleware APIs, Middleware Back ends, and Middleware 
Services. “


So is this the Qt Middleware module?


On the other hand, the module seems to also provide a lot more than just core 
primitives. E.g. this set of classes for in-viechle infotainment systems:

https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html


So is this a Qt for Automotive specific module? These APIs seem to indicate 
that as well:

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html

If we do want to promote this to a Qt module, should the core functionality be 
split off, and the rest stay Qt for Automotive specific?

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html

Cheers,
Tor Arne


On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
mailto:development@qt-project.org>> wrote:

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dgenivi%2Bsite%25253Ahttps%25253A%25252F%25252Flists.qt-project.org%25252Fpipermail%25252Fdevelopment%25252F=05%7C01%7Ctuukka.turunen%40qt.io%7Cc5d9d74e44014c5e22c308dbf5b48c59%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638373928019928582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=r0fpIXCgLTyWGtC9bIJ9waV7QgvH6J%2FnwRLJ%2BZMPL9k%3D=0

I don't know what kind of API reviews have been done since. But there has been
no discussion about renaming this module. 

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Ville Voutilainen]

On Thu, 7 Dec 2023 at 12:33, Giuseppe D'Angelo
 wrote:
> * For how long is QNX going to support OpenSSL 1? Is OpenSSL 3 support
> on the radar?

Yes, it's on the radar for QNX 8, which is not released yet.

> Is there an online resource showing their commitment at
> maintaining it? Is there the possibility of just building+shipping
> OpenSSL 3 outside of what it's provided by the base OS?

Well, like it is on Linux distros, building and shipping it as a
replacement is not easy,
and building and shipping it alongside is not easy either.

> * For how long are *we* going to support QNX and OpenSSL 1 on there?

Until QNX 8 ships.

> * What about other platforms?

Maybe we should keep OpenSSL1 support in 6.5 throughout the lifetime
of that LTS.

> * Can we put this "contract" in the docs?

Sure seems like it would be a good idea to revisit this for the next
LTS in any case. Make that the point
where we drop OpenSSL1 regardless of whether Blackberry has managed to
ship QNX 8. That's different
from doing it in a patch release, or backporting the drop to
everywhere. We can plausibly say at that
point that we'll just drop it.

> > I don't quite follow why the revert "must" include making OpenSSL1
> > entirely an opt-in.
> > That doesn't change anything in how we build our release packages, at
> > the end of the day.
> > Innocent users should just build with an OpenSSL3-enabled system.
>
> Innocent users may have their own build scripts that pull OpenSSL 1 and
> build Qt against that, without realizing that they're playing with fire.
> We should never expose users to insecure defaults, hence the opt-in
> flag, and a build error if you ask for autodetection and only OpenSSL 1
> is found.

Well, okay then. Patch it first so that the opt-in supersedes
autodetection but the autodetection
is still there, then patch coin so that everything in it that needs
this uses the opt-in, then drop
the autodetection.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Tor Arne Vestbø via Development]

If it’s an option to rename this module we should take the opportunity to do so 
I think.

The problem of the generic naming came up in the past, but the understanding 
was that it was too late to change.

If that is not the case after all, we should strongly consider it.

The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as:

"The Qt Interface Framework module provides both the tools and the core APIs, 
for you to implement Middleware APIs, Middleware Back ends, and Middleware 
Services. “

So is this the Qt Middleware module?

On the other hand, the module seems to also provide a lot more than just core 
primitives. E.g. this set of classes for in-viechle infotainment systems:

https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html

So is this a Qt for Automotive specific module? These APIs seem to indicate 
that as well:

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html

If we do want to promote this to a Qt module, should the core functionality be 
split off, and the rest stay Qt for Automotive specific?

https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html

Cheers,
Tor Arne

On 7 Dec 2023, at 17:02, Tuukka Turunen via Development 
 wrote:

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
mailto:development@qt-project.org>>
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dgenivi%2Bsite%25253Ahttps%25253A%25252F%25252Flists.qt-project.org%25252Fpipermail%25252Fdevelopment%25252F=05%7C01%7Ctuukka.turunen%40qt.io%7Cc5d9d74e44014c5e22c308dbf5b48c59%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638373928019928582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=r0fpIXCgLTyWGtC9bIJ9waV7QgvH6J%2FnwRLJ%2BZMPL9k%3D=0

I don't know what kind of API reviews have been done since. But there has been
no discussion about renaming this module. Therefore, the name it is currently
using is unauthorised and does not imply a precedent.

-1 on this new module with this name.


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Thiago Macieira]

On Thursday, 7 December 2023 08:02:15 PST Tuukka Turunen via Development 
wrote:
> So the question is what should this module be called, if it would be
> renamed?

I would indeed want to know what these are interfaces of or for. Like I said, 
they are not network interfaces, which is the first thing that comes to mind 
(to me). The second one that comes to mind is C++ "interfaces" (abstract 
virtual base classes), but we still need a domain to know what this is about. 
We have abstract virtual bases elsewhere in Qt, so what's special about this 
module?

Knowing now that this used to be "GENIVI Extras" does not help yet. "GENIVI 
Extras" meant something; "interfaces" or even just "automotive interfaces" do 
not.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Semih Yavuz as an approver for the Qt project

[Ulf Hermann via Development]

+1

Disclosure: Semih is working in my team and we share the same office.


Same for me

best regards,
Ulf
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs

[Tuukka Turunen via Development]

Hi,

Thiago is right, we can change the name as the module technically is not part 
of Qt release 
(https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/).

That said, we can also decide not to change the name. Like mentioned by 
Dominik, it has existing since a while with the current name 
(https://doc.qt.io/QtInterfaceFramework/) and repository 
(https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a 
different name, so the current one is already a new name, which is probably 
better than the initial at least.

So the question is what should this module be called, if it would be renamed? 
And another question, is it feasible to implement the renaming at this point?

Moving the proposed items out from it to labs modules makes sense to me. The 
naming of labs modules should then be aligned with the new naming of the module.

Yours,

Tuukka

From: Development  on behalf of Thiago 
Macieira 
Date: Tuesday, December 5, 2023 at 19:06
To: development@qt-project.org 
Subject: Re: [Development] Requesting a repository for Qt Interface Framework 
Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote:
> Then why are you asking for a repository if it's already there? When was
> that module approved by the Qt Project? I can't find anything in the email
> archives.
>
> The first commit in this repository is "First version of the QtGeniviExtras
> module". When was it renamed and who approved it?

This module was requested at
https://lists.qt-project.org/pipermail/development/2015-August/022859.html

There were no objections. Tuukka said it's a good idea to have the modules
even if they aren't part of the released packages:

> I think it is fine to create the requested repo for new module. Depending on
> the need it can then either be included or not be included in the release
> packages.

That would explain why this isn't in the qt5.git/.gitmodules.

But I said:

> I am, however, questioning the design of the API that Dominik presented.

There have been zero other discussions of "genivi" since then
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dgenivi%2Bsite%25253Ahttps%25253A%25252F%25252Flists.qt-project.org%25252Fpipermail%25252Fdevelopment%25252F=05%7C01%7Ctuukka.turunen%40qt.io%7Cc5d9d74e44014c5e22c308dbf5b48c59%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638373928019928582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=r0fpIXCgLTyWGtC9bIJ9waV7QgvH6J%2FnwRLJ%2BZMPL9k%3D=0

I don't know what kind of API reviews have been done since. But there has been
no discussion about renaming this module. Therefore, the name it is currently
using is unauthorised and does not imply a precedent.

-1 on this new module with this name.


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Giuseppe D'Angelo via Development]

Il 07/12/23 13:55, Kevin Kofler via Development ha scritto:

Why is that Qt's problem? Qt does not and cannot check that all security
updates for all dependencies have been applied, even when using a branch
supported by upstream, so I do not see why this case would be any different.


Because
1) Qt should never use unsafe 3rdparty dependencies;
2) this is different code from the supported version. We're choosing to 
keep and maintain code, in Qt, in order to support a library that has 
reached EOL;

3) OpenSSL is by far the most security-sensitive code that we use.

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence



smime.p7s
Description: Firma crittografica S/MIME
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Thiago Macieira]

On Thursday, 7 December 2023 04:55:48 PST Kevin Kofler via Development wrote:
> Qt should just use whatever OpenSSL is installed on the system and be done
> with it. Chances are that any OpenSSL 1 it finds will be from some LTS
> distro with backported security fixes anyway. 

I only agree partially with this statement, based on the previous paragraph.

The problem is that OpenSSL 1 and 3 have differing APIs, so supporting both 
means extra work for us. It's not a matter of just washing our hands, even if 
OpenSSL were "just another third-party dependency" -- it isn't, it's the 
single most security-relevant one. In fact, this is closer to support for 
Windows 9x/Me back in the day, where keeping this added to the maintenance of 
the other, more recent and more relevant configurations.

So here's what I propose as a compromise:
* we keep the code alive in the repository, for now
* we set a deadline for re-review, based on cost of maintenance and relevance
* we make it clear to users we do not test this, not even that it compiles
* but we advise we will take care of security issues stemming from our own 
  code as we've always done

That would put OpenSSL 1 support in the same bucket as FreeBSD or HaikuOS or 
Sparc processor support: whoever is using this[1] must supply patches.

I propose we re-review once a year.

[1] that may include the Qt Company if their commercial interests call for it.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Semih Yavuz as an approver for the Qt project

[Fabian Kosmale via Development]

Hi,

I would like to nominate Semih Yavuz for approver rights to the Qt project. 

Semih has been working on the Qt project since September 2022. He has been 
mainly focusing
on the QML tooling story, including work on qmlformat and the QML language 
server. In addition,
he is also taking care of the (non-LSP based ) Qt Creator QML integration.
Finally, he has also been reviewing changes in all parts of QML.

I fully trust his judgement in reviewing and approving changes.

Changes where he is the author: 
https://codereview.qt-project.org/q/owner:semih.yavuz%2540qt.io
Changes where he commented/voted on: 
https://codereview.qt-project.org/q/commentby:semih.yavuz%2540qt.io

Disclosure: Semih is working in my team and we share the same office.

Kind Regards,
Fabian
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QT_WARNING_MSG/QT_DEPRECATED_HEADER

[Thiago Macieira]

On Wednesday, 6 December 2023 23:58:10 PST Marc Mutz via Development wrote:
> Hi,
> 
> I've developed these to deprecate qspan_p.h in favour of qspan.h, but
> we'll now just remove the old header instead. I can see us apply it to
> qglobal.h, but not for 6.7.
> 
> But if you have a use for a cross-platform #warning or the deprecation
> of a whole header, restore and stage
> https://codereview.qt-project.org/c/qt/qtbase/+/523363, it's already
> approved and just waits for a user.

QT_WARNING_MSG is useful in other contexts too, for example for deprecating 
macros.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Kevin Kofler via Development]

Giuseppe D'Angelo via Development wrote:
> Innocent users may have their own build scripts that pull OpenSSL 1 and
> build Qt against that, without realizing that they're playing with fire.
> We should never expose users to insecure defaults, hence the opt-in
> flag, and a build error if you ask for autodetection and only OpenSSL 1
> is found.

Why is that Qt's problem? Qt does not and cannot check that all security 
updates for all dependencies have been applied, even when using a branch 
supported by upstream, so I do not see why this case would be any different. 
Especially because not every OpenSSL 1 out there is going to be insecure 
(due to LTS distros etc.). And neither is every OpenSSL 3 out there going to 
be secure. (Just because updates are available from upstream does not 
automatically mean they are going to be installed.)

Qt should just use whatever OpenSSL is installed on the system and be done 
with it. Chances are that any OpenSSL 1 it finds will be from some LTS 
distro with backported security fixes anyway. And if the OpenSSL in use is 
actually insecure, that is something purely between upstream (OpenSSL) and 
downstream (the distro/OS, the application developer, and/or the end user), 
and hence completely out of the scope of Qt. Same as for any other third-
party dependency.

As long as Qt does not bundle an insecure OpenSSL, I do not see the issue 
here.

Kevin Kofler

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Meeting minutes from Qt Release Team meeting 05.12.2023

[Jani Heikkinen via Development]

Qt 6.6 status:

  *   Qt 6.6.1 released
  *   Target is to release Qt 6.6.2 by the end of January 2024

Qt 6.7 status:

  *   Platform and module freeze -milestone in effect
  *   Qt 6.7 Feature Freeze will be in effect Fri 8th of December
  *   Branching from 'dev' to '6.7' will happen Monday 11th of December
  *   Target is to release Qt 6.7 Beta1 immediately after dependency update 
succeed in '6.7'

Next meeting Tue 12th of December 16:00 CET

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:28] <+jaheikki3> ablasche: : akseli: carewolf: frkleint: mapaaso: 
The-Compiler: thiago: vohi: ping
[17:00:40]  jaheikki3: pong
[17:01:13]  jaheikki3: pong
[17:01:45]  pong
[17:02:22] <+jaheikki3> Time to start qt release team meeting
[17:02:26] <+jaheikki3> on agenda today:
[17:02:29] <+jaheikki3> Qt 6.6 status
[17:02:32] <+jaheikki3> Qt 6.7 status
[17:02:42] <+jaheikki3> Any additional item to the agenda?
[17:04:29] <+jaheikki3> Let's start from Qt 6.6 status
[17:05:10] <+jaheikki3> Qt 6.6.1 was released 27th November
[17:05:25] <+jaheikki3> So far it seems to be quite good release
[17:05:45] <+jaheikki3> The target is to release Qt 6.6.2 by the end of January 
2024
[17:06:14] <+jaheikki3> That's actually all about Qt 6.6 status at this time. 
Any comments or questions?
[17:07:50] <+jaheikki3> Ok, then Qt 6.7 status
[17:08:10] <+jaheikki3> Platform and module freeze -milestone is in effect
[17:08:29]  jaheikki3: pong
[17:08:57] <+jaheikki3> Adding new prebuild binaries (llvm mingw & Linuc on 
arm) in the repositories ongoing
[17:09:15] <+jaheikki3> Qt 6.7 Feature Freeze will be in effect Fri 8th of 
December
[17:09:29] <+jaheikki3> Branching from 'dev' to '6.7' will happen Monday 11th 
of December
[17:09:49] <+jaheikki3> And the target is to release Qt 6.7 Beta1 immediately 
after dependency update succeed in 'dev'
[17:09:57] <+jaheikki3> Sorry, in '6.7'
[17:10:27] <+jaheikki3> That's all about 6.7 status. Any comments or questions?
[17:10:31] -*- thiago has two unifnished features
[17:10:39]  one was the int128 suppotr that I had promised marc but 
forgot to work on
[17:10:50] <+jaheikki3> thiago: Hoping you can get those ready early enough
[17:10:52]  the other was the QMetaMethod::listInvoke I promised Thomas 
Zander and also didn't work on
[17:11:26]  listInvoke is finishable, only unit tests are missing
[17:12:56] <+jaheikki3> what about the int128 support? thiago: vohi: if those 
won't be ready by the FF are those critical enough to get an exception
[17:12:59]  some of int128 support (as per 
https://bugreports.qt.io/browse/QTBUG-116924) seems to be done and/or in 
progress
[17:13:33]  if all that's not done yet is missing qHash support, then 
that's ok to make an exception for IMHO
[17:13:37]  no work has been done since 6.6 release when I argued we 
shouldn't jump the FF
[17:13:41]  but we didn't develop the feature
[17:13:59]  we're missing proper printing of them (QDebug, QTextStream)
[17:14:03]  QLocale
[17:15:51]  we will either way not be worse off with 6.7 than we are with 
6.6; we can decide for individual items and patches if we want them to be in 
6.7, if they are not merged by time of branching
[17:17:48] <+jaheikki3> yeah, let's check those later if needed. But hoping 
most of important items will be in at FF; the time from FF to final release is 
a bit shorter than earlier...
[17:18:22] <+jaheikki3> This was all about 6.7 status at this time. Is there 
more comments or questions?
[17:20:18] <+jaheikki3> It seems it was all at this time so let's end this 
meeting now & have next one Tue 12th December as planned
[17:20:30] <+jaheikki3> Thanks for your participation, bye!
[17:20:46]  thanks!
[17:20:55]  bye
[17:22:24]  bye
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Giuseppe D'Angelo via Development]

Hello,

On 07/12/2023 09:50, Ville Voutilainen wrote:

Well, this is straightforward in the sense that QNX doesn't support
openssl3 yet.
Dropping OpenSSL1 support is dropping support for TLS on QNX, and we don't
want to do that.


Sure, this is the premise of my mail, revert the change.

What about the rest?

* For how long is QNX going to support OpenSSL 1? Is OpenSSL 3 support 
on the radar? Is there an online resource showing their commitment at 
maintaining it? Is there the possibility of just building+shipping 
OpenSSL 3 outside of what it's provided by the base OS?


* For how long are *we* going to support QNX and OpenSSL 1 on there?

* What about other platforms?

* Can we put this "contract" in the docs?



I don't quite follow why the revert "must" include making OpenSSL1
entirely an opt-in.
That doesn't change anything in how we build our release packages, at
the end of the day.
Innocent users should just build with an OpenSSL3-enabled system.


Innocent users may have their own build scripts that pull OpenSSL 1 and 
build Qt against that, without realizing that they're playing with fire. 
We should never expose users to insecure defaults, hence the opt-in 
flag, and a build error if you ask for autodetection and only OpenSSL 1 
is found.


Thank you,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

[Ville Voutilainen]

On Thu, 30 Nov 2023 at 12:52, Giuseppe D'Angelo via Development
 wrote:
>
> Hi,
>
> OpenSSL 1 has reached EOL last September:
>
> > https://www.openssl.org/blog/blog/2023/09/11/eol-111/
>
>
> Qt has supported OpenSSL 3 for a while, and so last week I pushed a
> patch to drop OpenSSL 1 support from Qt. "This has made a lot of people
> very angry and been widely regarded as a bad move."
>
>
> It turns out that not every platform officially supported by Qt ships
> OpenSSL 3 yet. Some of these platforms are promising to maintain OpenSSL
> 1 for a little while longer, for instance Ubuntu 20.04 LTS:
>
> > https://canonical.com/blog/running-openssl-1-1-1-after-eol-with-ubuntu-pro
>
>
> How to move forward from here: "revert the patch", sure, but also not so
> fast:
>
> * First and foremost, I'd like a semi-formal insurance from Qt SSL
> maintainers that they're willing to maintain OpenSSL 1 code in Qt as
> long as needed. This should be done publicly, in docs + blog posts,
> because users are going to depend on this information.
>
> * For "how long" is that exactly? Also a very good question. Can we
> gather 1) which supported platforms are still offering only OpenSSL 1,
> and 2) for how long do they plan to support OpenSSL 1, and 3) for how
> long Qt would like to support these platforms? (Basically, assessing
> whether the "insurance" above is realistic)
>
> * Then, a plain revert isn't a good idea either: the whole point of the
> original commit is that using OpenSSL 1 is outright dangerous if you
> don't know what you're doing. (Using unmaintained security-sensitive
> code is a terrible idea). Therefore, a revert must also include make
> OpenSSL 1 entirely opt-in (cmake switch), and not using any automatic
> detection whatsoever: users of Qt should never ever be enabling it "by
> accident".

Well, this is straightforward in the sense that QNX doesn't support
openssl3 yet.
Dropping OpenSSL1 support is dropping support for TLS on QNX, and we don't
want to do that.

I don't quite follow why the revert "must" include making OpenSSL1
entirely an opt-in.
That doesn't change anything in how we build our release packages, at
the end of the day.
Innocent users should just build with an OpenSSL3-enabled system.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development