| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QtRemoteObjects serialization is built on top of QDataStream, but
QDataStream is not secure. Mark all files parsing data as security
critical.
The security is dependent on the backend used. The local and QNX
backends communicate only locally but are insecure on a compromised
host. The TCP backend is by default insecure, but it supports TLS,
and can be secure if that is used.
The two files in the repparser directory are used for parsing, but
only at build time, and are therefore kept at security significant.
The remaining files are marked as security signifcant.
QUIP: 23
Task-number: QTBUG-135570
Pick-to: 6.10 6.9 6.8
Change-Id: I11176c036d95f8c706bd05e1cab1ba499003f683
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
#pragma once was never allowed for installed headers¹ and syncqt.cpp
will now start to enforce this, so port the existing users in this
module to traditional header guards.
¹ https://lists.qt-project.org/pipermail/development/2022-October/043121.html
Amends 0fbfa7affa2aa22d338135d6f52ef3d3d4145766.
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: Id38cd34f97946e7f7d5033f431876ea8e8b06978
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I315d7ce1d6c6c3497afdfe8b61a113fdc181c935
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
See script in qtbase/util/includeprivate for the rules.
Since these files are being touched anyway, I also ran the
updatecopyright.pl script too.
Change-Id: Ib056b47dde3341ef9a52ffff13ef677e471674b6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extends the QList<*> fix to work with associative containers as well.
Note, this doesn't support enums as keys (to be added in a future commit)
There are two use-cases which should be supported by a fix.
1) Proxy, where the parameter is stored, but then forward to downstream
replicas which can be compiled. In this case, the ransformation needs
to support conversion back to the declared type.
2) Dynamic replicas being used from QML. In this case, the dynamic type
should be made available to QML in a way that is equivalent to the
declared type.
Dynamic storage/QML support are from the type QtROAssociativeContainer.
This class is derived from QVariantMap, but stores a few extra members to
allow forwarding without losing type information.
Over-the-wire transfer is via a new class (QAS_), which stores elements
in a QByteArray based on the valueType, not the container. Since the type
will always be fully known at the source, we can use metatype detection to
separate out the problematic types (an associative container of Q_GADGET
types), and convert those to QAS_ containers for sending.
Note: there is one additional piece needed. When we send the definition
of a dynamic type (needed for the creation of the dynamic metaobject), we
need to change the type of any member or parameter that is a such a
container to QtROAssociativeContainer.
Pick-to: 6.2
Change-Id: Ib50a01b4f9a3ecaa25a5a933feb6ed843e104b15
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
Qt6 fixes the original test case, as it now generates metatype info at
compile time for container classes of all primitive types. `subclass.rep`
was modified to include the type QList<MyPOD> as a property, which did
crash in Qt6, because PODs can have their metaObjects created at runtime,
which do not generate container<POD> metatypes.
There are two use-cases which should be supported by a fix.
1) Proxy, where the parameter is stored, but then forward to downstream
replicas which can be compiled. In this case, transforming to something
that works dynamically should support conversion back to the declared
type.
2) Dynamic replicas being used from QML. In this case, the dynamic type
should be made available to QML in a way that is equivalent to the
declared type.
Dynamic storage and QML support are from the type QtROSequentialContainer.
This class is derived from QVariant list, but stores a few extra members
allow forwarding without losing type information.
Over-the-wire transfer is via a new class (QSQ_), which stores the elements
in a QByteArray based on the valueType, not the container. Since the type
will always be fully known at the source, we can use metatype detection to
separate out the problematic types (a sequential container of Q_GADGET
types), and convert those to QSQ_ containers for sending.
Note: there is one additional piece needed. When we send the definition of
a dynamic type (needed for the creation of the dynamic metaobject), we need
to change the type of any member or parameter that is a such a container
to QtROSequentialContainer.
Pick-to: 6.2
Change-Id: Ie2ca53bcbeb4ca0e38c672b5ce951742f625711a
Reviewed-by: Michael Brasser <michael.brasser@live.com>
|
