Neither QCoapConnection nor QCoapQUdpConnection are public classes, and
there is no QCoapClient constructor (or other API) that would accept a
connection-instance.
Task-number: QTBUG-139697
Pick-to: 6.10 6.9 6.8
Change-Id: I3024d886299175401557a0b30987e98ab80b956f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The \generatelist command takes an optional argument
that affect how the members are listed, for example,
`classesbymodule` which creates an annotated list of
the classes in a named C++ module.
`groupsbymodule` is not recognized or documented. QDoc
falls back to generating a list of all members of a
group in this case. While the end result is correct,
this relies on an undocumented feature that is likely
to change and break.
Replace these instances with an explicit \annotatedlist
command that produces the same output.
Pick-to: 6.10
Task-number: QTBUG-138901
Change-Id: I0c23dac38445e41940907cf32a6da6fe3b769f7f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The previous commits identified and marked all security-critical files.
This commit marks the rest of the module with the default security
level (i.e. significant).
Fixes: QTBUG-135752
Pick-to: 6.10 6.9 6.8
Change-Id: I5ca76189504a2dfa1143def36abaafcca14bbcf5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The QCoapResourceDiscoveryReplyPrivate::resourcesFromCoreLinkList()
method parses the resource discovery reply according to the CoRE Link
Format.
Task-number: QTBUG-135752
Pick-to: 6.10 6.9 6.8
Change-Id: I274c6ea467ccafe8d8bef1230a87d0c12d79dbc8
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The docs clearly mention that a null device is treated as empty content.
However, the code was simply returning a nullptr in such case instead
of posting an actual request with an empty data.
As a drive-by, update the docs to actually mention that if the original
request has a payload, it will be used in such case. That is how the
QBA overload behaves.
[ChangeLog][Important Behavior Changes][QCoapClient] The post() overload
that takes a QIODevice* now behaves according to the documentation.
Specifically, if the provided QIODevice* is null, it will act as if an
empty QByteArray was provided instead of simply returning nullptr.
Change-Id: If8848515c71bd48f15e7672be6e184f903ce576d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Various methods in this file parse and adjust the user-provided URL.
However, they do it by using the public QUrl APIs only. Since QUrl
itself is security-critical, this file can be marked with the default
security score.
Task-number: QTBUG-135752
Pick-to: 6.10 6.9 6.8
Change-Id: I556a5b171aa0b1944688d5d87ab2279c13277ec3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The QCoapInternalMessage::setFromDescriptiveBlockOption() method
implements a part of the CoAP protocol, so mark qcoapinternalmessage.cpp
as security-critical.
The QCoapInternalReply class has createFromFrame() and nextBlockToSend()
methods that implement parts of the CoAP protocol, so mark
qcoapinternalreply.cpp as security-critical.
The QCoapInternalRequest class contains multiple methods that
implement the CoAP protocol (e.g. toQByteArray() or blockOption()), so
mark qcoapinternalrequest.cpp as security-critical.
The QCoapProtocol class implements the high-level details of the CoAP
protocol. It does not directly parse the data or generate the frames,
but contains the logic to call the proper low-level implementation.
Therefor, mark it as security-critical as well.
Task-number: QTBUG-135752
Pick-to: 6.10 6.9 6.8
Change-Id: I84855b6c352356f6163f7310b2d7075fd86bc9d4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... instead of an int. The int variable had a risk of overflow, which
is technically an UB. However, in practice it would have silently
resulted in a negative value.
The only usage of the variable is a call to QString::mid(), which
handles the negative second parameter as "provide data until the end
of the string".
Pick-to: 6.10 6.9 6.8 6.5
Change-Id: Ic95de0ceba09e02b726ab90407d637c449da2ccd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QCoapReply is a QIODevice, but it was not obvious if readData() is
implemented properly, or if it also needed to update pos().
This patch adds a unit test that checks a chunked read from the reply.
The test passes, so nothing needs to be fixed in the implementation.
Pick-to: 6.10 6.9 6.8 6.5
Change-Id: I0642718f21a31cf978a733bc3bc742ad1eb47b3a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It's faster when we know that we operate on pointers.
Change-Id: I1366c96159ff65186f2aa67d397772b5a4d4c5bd
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
There's no need to call get() once the request was created. It will
simply result in unnecessary copy of the request.
We can call sendRequest() directly instead.
Change-Id: I313a186478b4f2e9701c46e83d80c091f5a64a5f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The earliest we can move this is right after `BuildInternals`. This
allows us to add function calls before navigating the `find_package`
tree of the dependents.
Task-number: QTBUG-135233
Change-Id: I6330c79688c3b5fe566165ffb90658092a8c96b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is the result of running util/normalize on the code base. The
following manual edits were needed:
(none)
Pick-to: 6.10 6.9 6.8 6.5
Change-Id: Ia18b3968bc164a8dce5e7cca7653c759646cc4da
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>