Re: Release goals for 20.XX
On 31.07.20 21:49, Stefan Lippers-Hollmann wrote: I don't think this is going to happen for a 20.xy.0 release, basically there are only two platforms for this on the horizon at the moment: I am holding my patches back on purpose to not interfere with the release. AX will be a post 20.x thing John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 20.XX
Hi [Disclaimer: I'm not an OpenWrt developer] On 2020-07-31, bapti...@bitsofnetworks.org wrote: [...] > Possibly missing goals are: > > 1) major feature: 802.11ax and ath11k support? > >I don't know the current state of this. I don't think this is going to happen for a 20.xy.0 release, basically there are only two platforms for this on the horizon at the moment: - QCA ipq807x/ ath11k: so far ath11k is exclusively available for the ipq807x SOC family (dedicated PCIe/ m.2 cards have just appeared on the market, PCIe support for ath11k is not completely merged upstream yet), but while basic -incomplete- target support already exists in master, not a single device is supported at this point (missing parts, PCIe, ethernet, ath11k technically also isn't available in master so far). While there is quite some interest and activity around this target, predominantly around the Xiaomi AX3600, I don't think this will make it soon (enough) for a 20.xy.0 stable release - not ruling it out completely, but a lot would have to happen in short time. - Mediatek mt7915e 802.11ax wireless The first devices of this kind appear to favour the older mips based mt7621a SOC, so support for these could appear quite quickly - depending on the current state of mt7615e support in the mt76 driver (it's still very new/ under development, no idea how far that has been developed at this point), but so far none of these routers/ APs is support by OpenWrt yet (and I'm not aware of any pending pull requests adding support for these either). A more natural (faster) combination would be the mt7622 ARMv8 SOC, but this is also a rather new target with few supported devices whose practical support is also just shaping up (none of those come with mt7915e WLAN at this moment either). So far I haven't seen any mt7622a+mt7915e on the market (nor any announcements) yet. Both 802.11ax contenders will probably have to wait for a 21.xy.0, even though ipq807x might be close. [...] > 3) organisational: switch to gitlab? > >While there was a vote about it, I don't know if this is planned >for 20.XX. I think it makes sense: we could start using gitlab to >track 20.XX bug reports, and possibly drop 18.06 bug reports from >flyspray. But if it is not ready, it should probably not block the >20.XX release. This has imho no direct relation to the release, it's mostly invisible behind the curtain for the ordinary user - their interaction with the git repositories is close to zero, bugs are only filed at bugs.openwrt.org anyways, the binary repos pushed from downloads.openwrt.org and the canonical location of the git repos is git.openwrt.org (github is just a mirror and the package feeds are a different question alltogether). This migration to gitlab can happen at any point and doesn't need to be tied to a release. Regards Stefan Lippers-Hollmann ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 20.XX
On Fri, Jul 31, 2020 at 01:37:00PM +0200, bapti...@bitsofnetworks.org wrote: > 3) organisational: switch to gitlab? > >While there was a vote about it, Hi, do you happen to have a link to that discussion/vote? >I don't know if this is planned for 20.XX. I think it makes sense: >we could start using gitlab to track 20.XX bug reports, and >possibly drop 18.06 bug reports from flyspray. But if it is not >ready, it should probably not block the 20.XX release. I would encourage delaying such a move. My reason is that although Gitlab is free as in freedom (good!), it does rely on client-side JavaScript for much of the functionality of its web pages (bad!). (By "the functionality in its web pages", I mean as opposed to, say, the functionality exposed through its API.) This means that any visitor/developer who needs to interact with a Gitlab instance via its webpages is forced to increase their attack surface by enabling JavaScript in their browser. This in turn means that if the server running the Gitlab instance gets compromised by an attacker, then the attacker would be able to pivot to visitors/developers' workstations or laptops by serving JavaScript-based malware. This might in principle allow the attacker to e.g.: - steal the visitor's/developer's private keys if present in the cache or RAM of that person's PC;[1] or - gain privileged code execution on that person's PC,[2] allowing for installation of a remote access tool (RAT) and consequent ability to exfiltrate private keys or otherwise masquerade as the PC's owner. Clearly, such an attack if carried out would have serious implications for the future integrity of OpenWRT. Such malware, especially if it exploits unfixable hardware vulnerabilities in client CPUs (e.g. Spectre, Meltdown, etc) can be protected against by disabling JavaScript in one's web-browser. But although this protection works well when visiting the *current* OpenWRT websites (wiki, bug tracker, etc), it would *NOT* be viable if OpenWRT switches to Gitlab. (This is because of Gitlab's reliance on client-side JavaScript, as mentioned earlier.) Sadly, this is not only theoretical. Attacks along roughly these lines are known to have been conducted in the past, in order to insert vulnerabilities into networks and codebases.[3] OpenWRT is widely used, especially by people who value security and therefore choose it over proprietary alternatives. Consequently, it is a "target-rich environment". For this reason, I would urge the OpenWRT devs *not* to switch to any web-based software that requires visitors to browse with JavaScript enabled. All best, Sam [1] "Research showed that microarchitectural attacks like cache attacks can be performed through websites using JavaScript. ... However, the W3C and browser vendors responded to this significant threat by eliminating fine-grained timers from JavaScript. ... We demonstrate the inefficacy of this mitigation by finding and evaluating a wide range of new sources of timing information. We develop measurement methods that exceed the resolution of official timing sources by 3 to 4 orders of magnitude on all major browsers, and even more on Tor browser. Our timing measurements do not only re-enable previous attacks to their full extent but also allow implementing new attacks." https://gruss.cc/files/fantastictimers.pdf [2] "side-channel attacks allow to detect the exact location of kernel data structures or derandomize ASLR in JavaScript. A combination of a software bug and the knowledge of these addresses can lead to privileged code execution." https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-lipp.pdf "We demonstrate a fully automated attack that requires nothing but a website with JavaScript to trigger faults on remote hardware. Thereby we can gain unrestricted access to systems of website visitors. We show that the attack works on off-the-shelf systems. Existing countermeasures fail to protect against this new Rowhammer attack." https://link.springer.com/chapter/10.1007%2F978-3-319-40667-1_15 [3] https://theintercept.com/2014/03/20/inside-nsa-secret-efforts-hunt-hack-system-administrators/ https://theintercept.com/document/2014/03/20/hunt-sys-admins/ https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/ -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Release goals for 20.XX
> 3) organisational: switch to gitlab? > >While there was a vote about it, I don't know if this is planned >for 20.XX. I think it makes sense: we could start using gitlab to >track 20.XX bug reports, and possibly drop 18.06 bug reports from >flyspray. But if it is not ready, it should probably not block the >20.XX release. I personally don't think we should link this to the release. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Release goals for 20.XX
Hi, Following the experiment with 19.07.4 release goals [1], here is a set of release goals for the next 20.XX major release: https://openwrt.org/docs/guide-developer/releases/goals/20.xx This is mostly based on the meeting notes of the last dev meeting posted by Hauke, as well as various discussions. According to my understanding, all the release goals above have reached consensus or a vote to be included in 20.XX. Please adjust / discuss if this is not the case. Some goals need references. Possibly missing goals are: 1) major feature: 802.11ax and ath11k support? I don't know the current state of this. 2) major feature: 802.11ad / 60 GHz support? Again, I haven't followed progress here. 3) organisational: switch to gitlab? While there was a vote about it, I don't know if this is planned for 20.XX. I think it makes sense: we could start using gitlab to track 20.XX bug reports, and possibly drop 18.06 bug reports from flyspray. But if it is not ready, it should probably not block the 20.XX release. Baptiste [1] https://openwrt.org/docs/guide-developer/releases/goals/19.07.4 signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
