Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronize official source code #113

Merged
merged 5 commits into from
Jun 25, 2024
Merged

Synchronize official source code #113

merged 5 commits into from
Jun 25, 2024

Conversation

openwrtdiy
Copy link
Owner

Thanks for your contribution to OpenWrt!

To help keep the codebase consistent and readable,
and to help people review your contribution,
we ask you to follow the rules you find in the wiki at this link
https://openwrt.org/submitting-patches

Please remove this message before posting the pull request.

blocktrron and others added 5 commits June 10, 2024 03:37
On master, the bootwrapper link-address for all simpleImage targets was
relocated to 0x15000000 due to growing kernel size.

This was not done on OpenWrt 23.05, as the decompressed kernel still
fits. However, with the wrapper for the WS-AP3710i, the bootloader
attempts execute in-place with the uImage load-address of 0x1000000. As
the image is compiled without the uImage header in mind, this naturally
fails.

In order to fix this, link the WS-AP3715i simpleImage at 0x15000000 as
done in master. This will force the bootloader to relocate the code to
the proper address and skip XIP.

Signed-off-by: David Bauer <mail@david-bauer.net>
With the introduction of the simpleImage loader, the MAC address is not
set by the bootloader anymore.

Fix this by reading the MAC address from the U-Boot environment
partition.

Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 22f92cc)
The WS-AP3710i does not correctly expose its label-mac on eth0 anymore
since the change to simpleLoader.

Fix this by obtaining the label-mac from the U-Boot environment.

Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit e321e70)
a903d3169193 wifi: mt76: mt7921: fix a potential association failure upon resuming
eb0d0ce344f3 wifi: mt76: mt7921: fix suspend issue on MediaTek COB platform
841bf82e9958 wifi: mt76: fix the issue of missing txpwr settings from ch153 to ch177
ce7ccc540168 wifi: mt76: Remove redundant assignment to variable tidno
a238df940d6f wifi: mt76: mt7915: initialize rssi on adding stations
46c7d1849dbd wifi: mt76: replace skb_put with skb_put_zero
b5640b3153c7 wifi: mt76: fix tx packet loss when scanning on DBDC
7b054e5cb3af wifi: mt76: mt7915: fix mcu command format for mt7915 tx stats
3f27a64a8010 wifi: mt76: mt7915: fix bogus Tx/Rx airtime duration values
4f681a8fbc91 wifi: mt76: mt7915: fix HE PHY capabilities IE for station mode
8ede229eb8b5 wifi: mt76: mt7915: only set MT76_MCU_RESET for the main phy
2330781b8c5f wifi: mt76: mt7996: only set MT76_MCU_RESET for the main phy
e5fb6995e7eb wifi: mt76: mt7915: add support for disabling in-band discovery
b4a917417c85 wifi: mt76: mt7915: add mt7986, mt7916 and mt7981 pre-calibration
2135e201e7a9 mt76: mt7915: add fallback in case of missing precal data

Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 85ad6b9)
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Per the CycloneDX 1.4 spec, the `metadata.timestamp` field contains
the date/time when the BOM was created [1].

Before the change, the value generated by the package-metadata.pl
script would look like this:

	2024-06-03T15:51:10

CycloneDX 1.4 relies on the JSON Schema specification version draft-07,
which defines the `date-time` format [2] as derived from RFC 3339,
section 5.6 [3]. In this format, the `time-offset` component is required,
however in the original version of package-metadata.pl it is omitted.

This is causing problems with OWASP Dependency-Track version 4.11.0 or
newer, where it now validates submitted SBOMs against the JSON schema
by default [4]. SBOMs with incorrect timestamp values are rejected with
the following error:

	{
	    "detail": "Schema validation failed",
	    "errors": [
	        "$.metadata.timestamp: 2024-06-03T15:51:10 is an invalid date-time"
	    ],
	    "status": 400,
	    "title": "The uploaded BOM is invalid"
	}

Add explicit `Z` (UTC) timezone offset in the `timestamp` field
to satisfy the CycloneDX schema.

[1]: https://github.com/CycloneDX/specification/blob/1.4/schema/bom-1.4.schema.json#L116-L121
[2]: https://json-schema.org/draft-07/draft-handrews-json-schema-validation-01#rfc.section.7.3.1
[3]: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
[4]: DependencyTrack/dependency-track#3522

Signed-off-by: Roman Azarenko <roman.azarenko@iopsys.eu>
(cherry picked from commit 2ded629)
Link: openwrt#15693
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
@openwrtdiy openwrtdiy merged commit 30a0e99 into pppoe-23.05 Jun 25, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants