Re: [Development] Security-relevant 3rd party components bundled with Qt

[Marc Mutz via Development]

On 20.09.22 14:47, Volker Hilsheimer wrote:
[...]
> https://wiki.qt.io/Third_Party_Code_in_Qt
[...]

Sorry for being late to the discussion, but a wiki page will _always_ be 
stale. And it cannot answer the question differently for different branches.

When we started using SPDX, I thought it was so as to automate the 
creation of Qt's SBOM? If we haven't done that, yet, start there.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

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

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] Security-relevant 3rd party components bundled with Qt

[Volker Hilsheimer via Development]

That’s an excellent idea indeed.

And the attribution file already able to point at the upstream (albeit 
optional; I guess we can’t make it mandatory), and a comment entry that could 
in turn include information about how to update things, makes that a pretty 
complete container of all relevant information.

Volker


On 22 Feb 2023, at 12:21, Kai Köhne  wrote:

Hi,

Does moving the information closer to the code make sense? Most of the 
information provided in the wiki is already part of the qt_attribution.json 
files that we use to generate the official documentation about third party 
modules. What’s missing is the ‘process untrusted content’ flag, which is easy 
to add:

https://codereview.qt-project.org/c/meta/quips/+/461983

Tell me what you think.

Regards

kai

From: Development 
mailto:development-boun...@qt-project.org>> 
On Behalf Of Volker Hilsheimer via Development
Sent: Friday, January 20, 2023 9:58 AM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] Security-relevant 3rd party components bundled with 
Qt

On 1 Nov 2022, at 09:55, Volker Hilsheimer via Development 
mailto:development@qt-project.org>> wrote:

On 20 Sep 2022, at 14:47, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:
[…]

Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).


Hi again,


Thanks for populating that page with information about 3rd party components 
processing untrusted content.

As a next step, could those of you who are upgrading such components as part of 
the release process, please provide links to the respective upstream, and 
instructions on what is involved in the upgrading of the bundled sources?

Hi,

That page still misses information for a lot of 3rd party modules about where 
to find the upstream and the update instructions. That makes it very difficult 
for our release team to follow up on the 3rd party update.

Third Party Code in Qt - Qt Wiki<https://wiki.qt.io/Third_Party_Code_in_Qt>
wiki.qt.io<https://wiki.qt.io/Third_Party_Code_in_Qt>
<https://wiki.qt.io/Third_Party_Code_in_Qt>

We need information about

QtNetwork:
- public suffix list

QtGui:
- harfbuzz-ng
- libpng, libjpeg
- sqlite

Qt Imageformats:
- libwebp

Qt Multimedia
- ffmpeg
- eigen
- pffft
- resonance audio

Qt Quick3D
- assimp
- tinyexr


Thanks,
Volker


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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Kai Köhne via Development]

Hi,

Does moving the information closer to the code make sense? Most of the 
information provided in the wiki is already part of the qt_attribution.json 
files that we use to generate the official documentation about third party 
modules. What’s missing is the ‘process untrusted content’ flag, which is easy 
to add:

https://codereview.qt-project.org/c/meta/quips/+/461983

Tell me what you think.

Regards

kai

From: Development  On Behalf Of Volker 
Hilsheimer via Development
Sent: Friday, January 20, 2023 9:58 AM
To: development@qt-project.org
Subject: Re: [Development] Security-relevant 3rd party components bundled with 
Qt

On 1 Nov 2022, at 09:55, Volker Hilsheimer via Development 
mailto:development@qt-project.org>> wrote:

On 20 Sep 2022, at 14:47, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:
[…]

Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).


Hi again,


Thanks for populating that page with information about 3rd party components 
processing untrusted content.

As a next step, could those of you who are upgrading such components as part of 
the release process, please provide links to the respective upstream, and 
instructions on what is involved in the upgrading of the bundled sources?

Hi,

That page still misses information for a lot of 3rd party modules about where 
to find the upstream and the update instructions. That makes it very difficult 
for our release team to follow up on the 3rd party update.

Third Party Code in Qt - Qt Wiki<https://wiki.qt.io/Third_Party_Code_in_Qt>
wiki.qt.io<https://wiki.qt.io/Third_Party_Code_in_Qt>
[favicon.ico]<https://wiki.qt.io/Third_Party_Code_in_Qt>

We need information about

QtNetwork:
- public suffix list

QtGui:
- harfbuzz-ng
- libpng, libjpeg
- sqlite

Qt Imageformats:
- libwebp

Qt Multimedia
- ffmpeg
- eigen
- pffft
- resonance audio

Qt Quick3D
- assimp
- tinyexr


Thanks,
Volker

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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Volker Hilsheimer via Development]

On 1 Nov 2022, at 09:55, Volker Hilsheimer via Development 
 wrote:

On 20 Sep 2022, at 14:47, Volker Hilsheimer  wrote:
[…]
Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).


Hi again,


Thanks for populating that page with information about 3rd party components 
processing untrusted content.

As a next step, could those of you who are upgrading such components as part of 
the release process, please provide links to the respective upstream, and 
instructions on what is involved in the upgrading of the bundled sources?

Hi,

That page still misses information for a lot of 3rd party modules about where 
to find the upstream and the update instructions. That makes it very difficult 
for our release team to follow up on the 3rd party update.


Third Party Code in Qt - Qt Wiki
wiki.qt.io
[favicon.ico]

We need information about

QtNetwork:
- public suffix list

QtGui:
- harfbuzz-ng
- libpng, libjpeg
- sqlite

Qt Imageformats:
- libwebp

Qt Multimedia
- ffmpeg
- eigen
- pffft
- resonance audio

Qt Quick3D
- assimp
- tinyexr


Thanks,
Volker

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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Volker Hilsheimer via Development]

> On 20 Sep 2022, at 14:47, Volker Hilsheimer  wrote:
[…]
> Those components should then be watched closer, and always get updated to the 
> latest version, perhaps even for patch releases. To that end, I’ve started to 
> collect a list of such components on
> 
> https://wiki.qt.io/Third_Party_Code_in_Qt
> 
> and would appreciate if you could have a look and add missing components to 
> that page, esp if you are in charge of some of them. I’ve included a column 
> that describes what kind of patches we apply when we update the 3rd party 
> code (and this is perhaps a good opportunity to see if all of those are still 
> necessary).


Hi again,


Thanks for populating that page with information about 3rd party components 
processing untrusted content.

As a next step, could those of you who are upgrading such components as part of 
the release process, please provide links to the respective upstream, and 
instructions on what is involved in the upgrading of the bundled sources?


Thanks a lot,

Volker

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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Volker Hilsheimer via Development]

> On 7 Oct 2022, at 22:08, Robert Löhning via Development 
>  wrote:
> 
> Am 20.09.22 um 14:47 schrieb Volker Hilsheimer:
>> Hi,
>> Some of the 3rd party components we bundle in Qt are directly involved in 
>> code paths that are designed to process untrusted data. Following up on the 
>> situation with freetype [1] and the discussion we had during summer [2], it 
>> would help know which of the 3rd party components we bundle today have a 
>> security relevant surface. All components process data, but many only 
>> process data that the application developer has full control over (for 
>> example, we explicitly state that you should not load any untrusted QML code 
>> or content [3]). Those that are designed to process data from anywhere are 
>> the ones that are most interesting here.
>> Those components should then be watched closer, and always get updated to 
>> the latest version, perhaps even for patch releases. To that end, I’ve 
>> started to collect a list of such components on
>> https://wiki.qt.io/Third_Party_Code_in_Qt
>> and would appreciate if you could have a look and add missing components to 
>> that page, esp if you are in charge of some of them. I’ve included a column 
>> that describes what kind of patches we apply when we update the 3rd party 
>> code (and this is perhaps a good opportunity to see if all of those are 
>> still necessary).
>> In the line of the previous discussion [1], we can then start investigating 
>> our options for those 3rd party components; for instance, can we build them 
>> some of them as shared libraries so that they can be easily updated? On 
>> which platforms are some of them available as system libraries or SDKs, and 
>> do we test that those work in CI?
>> Thanks,
>> Volker
>> PS: Given the nature of Qt WebEngine, we can probably skip that particular 
>> repository in this exercise.
>> [1] https://lists.qt-project.org/pipermail/development/2022-July/042795.html
>> [2] https://lists.qt-project.org/pipermail/development/2022-July/042729.html
>> [3] https://doc.qt.io/qt-6/qtqml-documents-networktransparency.html
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> Hi,
> 
> thank you for this initiative Volker.
> 
> Would it make sense to add a column to that table containing the contact info 
> of the respective 3rd party component's maintainer(s) and/or bug tracker? 
> It's awkward to have found an issue and not know whom to tell about it.

Sure, add what you think is useful.


> By the way: If anybody knows how to reach a maintainer of libtiff, please let 
> me know.

http://www.libtiff.org specifies t...@remotesensing.org as the mailing list 
address, and names a few individuals. Based on 
https://www.asmail.be/msg0054916394.html it would seem that you found that 
already though.

Volker



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

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Robert Löhning via Development]

Am 20.09.22 um 14:47 schrieb Volker Hilsheimer:

Hi,


Some of the 3rd party components we bundle in Qt are directly involved in code 
paths that are designed to process untrusted data. Following up on the 
situation with freetype [1] and the discussion we had during summer [2], it 
would help know which of the 3rd party components we bundle today have a 
security relevant surface. All components process data, but many only process 
data that the application developer has full control over (for example, we 
explicitly state that you should not load any untrusted QML code or content 
[3]). Those that are designed to process data from anywhere are the ones that 
are most interesting here.

Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).

In the line of the previous discussion [1], we can then start investigating our 
options for those 3rd party components; for instance, can we build them some of 
them as shared libraries so that they can be easily updated? On which platforms 
are some of them available as system libraries or SDKs, and do we test that 
those work in CI?


Thanks,
Volker

PS: Given the nature of Qt WebEngine, we can probably skip that particular 
repository in this exercise.

[1] https://lists.qt-project.org/pipermail/development/2022-July/042795.html
[2] https://lists.qt-project.org/pipermail/development/2022-July/042729.html
[3] https://doc.qt.io/qt-6/qtqml-documents-networktransparency.html

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


Hi,

thank you for this initiative Volker.

Would it make sense to add a column to that table containing the contact 
info of the respective 3rd party component's maintainer(s) and/or bug 
tracker? It's awkward to have found an issue and not know whom to tell 
about it.


By the way: If anybody knows how to reach a maintainer of libtiff, 
please let me know.


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

[Development] Security-relevant 3rd party components bundled with Qt

[Volker Hilsheimer]

Hi,


Some of the 3rd party components we bundle in Qt are directly involved in code 
paths that are designed to process untrusted data. Following up on the 
situation with freetype [1] and the discussion we had during summer [2], it 
would help know which of the 3rd party components we bundle today have a 
security relevant surface. All components process data, but many only process 
data that the application developer has full control over (for example, we 
explicitly state that you should not load any untrusted QML code or content 
[3]). Those that are designed to process data from anywhere are the ones that 
are most interesting here.

Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).

In the line of the previous discussion [1], we can then start investigating our 
options for those 3rd party components; for instance, can we build them some of 
them as shared libraries so that they can be easily updated? On which platforms 
are some of them available as system libraries or SDKs, and do we test that 
those work in CI?


Thanks,
Volker

PS: Given the nature of Qt WebEngine, we can probably skip that particular 
repository in this exercise.

[1] https://lists.qt-project.org/pipermail/development/2022-July/042795.html
[2] https://lists.qt-project.org/pipermail/development/2022-July/042729.html
[3] https://doc.qt.io/qt-6/qtqml-documents-networktransparency.html

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