Re: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Volker Hilsheimer]

Thank you all! It’s an honour, and I’m looking forward to your contributions :)

Volker


> On 17 Feb 2022, at 15:19, Richard Gustavsen  wrote:
> 
> This has now taken effect, and the Wiki has been updated 
> (https://wiki.qt.io/Maintainers).
> 
> Congratulations Volker!
> 
> Best Regards,
> Richard Moe Gustavsen
> Principal Engineer
> The Qt Company
> Oslo, Norway
> 
>> On 25 Jan 2022, at 09:38, Richard Gustavsen  wrote:
>> 
>> Hi all!
>> 
>> I would like to propose a change in the maintenance of Qt Widgets [1]. I’m 
>> the current maintainer of the module, but I’m happy to inform you that 
>> Volker Hilsheimer has agreed to join me as a co-maintainer. Volker is one of 
>> the biggest contributors to Widgets [2], and has been helping out 
>> maintaining the module for a long time already. So let’s make it formal as 
>> well!
>> 
>> [1] https://wiki.qt.io/Maintainers#Qt_Maintainers
>> [2] 
>> https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged
>> 
>> Best Regards,
>> Richard Moe Gustavsen
>> Principal Engineer
>> The Qt Company
>> Oslo, Norway
>> 
>> ___
>> 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 forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Thiago Macieira]

On Thursday, 17 February 2022 02:53:11 PST Marc Mutz wrote:
>   2.  that brings up back to The Other Discussion™, about C++20 types in the
> ABI, which isn't really about C++20 types, after all, but about symbols
> only C++20 code would need/could use
> 
> I'm not sure where we left off on (2), but it's unlikely that anything we
> decide will be retroactively applied to Qt 6.2, isn't it?

I don't have a problem about using any type in our ABI, so long as it's ALWAYS 
there and that no one who performed an acceptable upgrade would find a linker 
issue.

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



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

Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

[Cristián Maureira-Fredes]

Hello,

Forgot to wrap up this discussion :P
but thanks for your comments,
and congratulations Sona for being the
new maintainer of Qt5Compat.

Cheers

On 1/18/22 15:10, Cristián Maureira-Fredes wrote:

Hello,

I would like to nominate Sona as maintainer [1]
for the qt5compat module, which at the moment doesn't
have one. Even if it's a special module we have around
only for Qt6, we need a responsible person in charge of it.

She has been working mainly in qtbase in the last years
and took care of many tasks when the module was created [2].

Due to her contributions in qtbase and other modules [3],
I firmly believe she will manage to maintain it.

Cheers


[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2] 
https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+repo:qt/qt5compat+status:merged 

[3] 
https://codereview.qt-project.org/q/owner:sona.kurazyan%2540qt.io+status:merged 





--
Dr. Cristián Maureira-Fredes
R Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Richard Gustavsen]

This has now taken effect, and the Wiki has been updated 
(https://wiki.qt.io/Maintainers).

Congratulations Volker!

Best Regards,
Richard Moe Gustavsen
Principal Engineer
The Qt Company
Oslo, Norway

On 25 Jan 2022, at 09:38, Richard Gustavsen 
mailto:richard.gustav...@qt.io>> wrote:

Hi all!

I would like to propose a change in the maintenance of Qt Widgets [1]. I’m the 
current maintainer of the module, but I’m happy to inform you that Volker 
Hilsheimer has agreed to join me as a co-maintainer. Volker is one of the 
biggest contributors to Widgets [2], and has been helping out maintaining the 
module for a long time already. So let’s make it formal as well!

[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2] 
https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged

Best Regards,
Richard Moe Gustavsen
Principal Engineer
The Qt Company
Oslo, Norway

___
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 forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Marc Mutz]

Hi Thiago,

> By the way, how often is this done? What's the exposure in the real world?

Does FTBFS of qtwayland count?  IOW: Clang and GCC found this one for me, I 
didn't look.

> The pre-6.3 implementation could be #if __cplusplus <= 2020

Two comments:

  1.  possibly, with __cpp_impl_three_way_comparison instead (__cplusplus is 
unreliable), but
  2.  that brings up back to The Other Discussion™, about C++20 types in the 
ABI, which isn't really about C++20 types, after all, but about symbols only 
C++20 code would need/could use

I'm not sure where we left off on (2), but it's unlikely that anything we 
decide will be retroactively applied to Qt 6.2, isn't it?

Thanks,
Marc


Marc Mutz

Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany

marc.m...@qt.io

www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen

Sitz der Gesellschaft: Berlin,

Registergericht: Amtsgericht Charlottenburg,

HRB 144331 B

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/qt-company.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube.png] 


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

[Development] [Announce] Security advisory: QProcess

[List for announcements regarding Qt releases and development]

Recently, the Qt Project's security team was made aware of an issue regarding 
QProcess and determined it to be a security issue on Unix-based platforms only. 
We do not believe this to be a considerable risk for applications as the 
likelihood of it being triggered is minimal.

Specifically, the problem is around using QProcess to start an application 
without having an absolute path, and as a result, it depends on it finding it 
in the PATH environment variable. As a result, it may be possible for an 
attacker to place their copy of the executable in question inside the 
working/current directory for the QProcess and have it invoked that instead.

This situation is expected on Windows because it will search that directory 
first before the PATH environment variable finds the executable in question. 
However, it is not normal on Unix-based platforms to search the working/current 
directory if it cannot find it in the PATH environment variable. Therefore, it 
could enable an attacker to place a malicious executable there with the same 
name.

If you are using QProcess with an absolute or relative path, then this is not a 
problem; it will invoke that one specifically, but if you are using it like: 

QProcess p;
p.start("application", args); 

it could run into this problem.

Patches are available for the currently supported versions of Qt and Qt 5.12 
can be found here:

dev: https://codereview.qt-project.org/c/qt/qtbase/+/393113
Qt 6.2: https://codereview.qt-project.org/c/qt/qtbase/+/394914 or 
https://download.qt.io/official_releases/qt/6.2/CVE-2022-25255-qprocess6-2.diff
Qt 5.15: https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/394919 or 
https://download.qt.io/official_releases/qt/5.15/CVE-2022-25255-qprocess5-15.diff
Qt 5.12: https://codereview.qt-project.org/c/qt/qtbase/+/396020

If you prefer not to patch Qt, you can get around this by ensuring a complete 
path for your application instead of inside QProcess. You can utilize 
QStandardPaths::findExecutable() for this purpose as this will search your PATH 
environment variable and, as a result, will give you a safe path to use.

The official CVE report for this can be found here: 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25255

Kind regards,
Andy
--
Andy Shaw
The Qt Company

___
Announce mailing list
annou...@qt-project.org
https://lists.qt-project.org/listinfo/announce
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Lars Knoll]

> On 16 Feb 2022, at 18:10, Thiago Macieira  wrote:
> 
> On Tuesday, 15 February 2022 07:54:07 PST Marc Mutz wrote:
>> https://bugreports.qt.io/browse/QTBUG-100845
>> 
>> The QWaylandBufferRef class has a very annoying bug in that its relational
>> operators cannot compare `const` objects (only on the RHS). That's because
>> these operators are implemented as members, but are not const. Since
>> they're not const, they cannot be called with a const LHS...
> 
> By the way, how often is this done? What's the exposure in the real world?

Wayland Compositor is not the most often used module in Qt. I think most users 
are on embedded devices. That also means I wouldn’t be overly concerned about a 
FW BC break in that module. Still it’s good if we can avoid it.
> 
> The pre-6.3 implementation could be #if __cplusplus <= 2020

That could actually be a solution for 6.2. We keep the old API if you compile 
in C++17 mode and only enable the new methods in C++20 mode. Requires a bit of 
work on our side to make sure the symbols are in the libraries as required, but 
otherwise it’s basically about what we expose in the header.

Cheers,
Lars

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel DPG 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