Re: USB controller enumeration on APU3 is random since the update to kernel 6.6
On 18 July 2024 09:53:14 UTC, Florian Eckert wrote: > > I found a commit [1] in the Linux kernel that makes the USB > controller probing asynchronous and therefore not deterministic as > before. I have reverted the commit on my build and now nothing > changes in the controller numbering. This is not a solution, but > I now know what the problem is. With a new kernel, the numbering > can be completely different again. > > From my point of view, that's a general problem, that USB controller > does not have a fix sysfs path. In my case, I explicitly refer to > a USB device sysfs path in the network configuration that the > modemmanager should use. I can't work with serial number, pid, vid. > I think also the udev service will also not help there. > > The question is how to get a unambiguous that is the same after every > boot even if the kernel changes the probing behavior. On the PCI bus > there is always unambiguous number. > > [...] > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69a1c9a9b273271f2a2674bcc117336a9bb0a4b4 Might it be best to file a bug report against the Linux kernel? After all, the commit message suggests the developer didn't anticipate this commit causing breakage. Yet it seems the commit is causing serious breakage, likely to stop many people's routers, PCs or other devices to stop being able to use peripherals (network adapters, printers, cameras, who knows what else?) as expected, with no easy workaround. Sorry if I've misunderstood. Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On Sun, Apr 16, 2023 at 12:59:49PM +0300, Arınç ÜNAL wrote: > On 15.04.2023 20:02, Sam Kuper wrote: >> On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: >>> These are the ideas I've been thinking about for the future of >>> OpenWrt for a while. It looks complete enough to share it with all >>> of you. [...] >>> >>> https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb >> >> Please can you post the contents of that page as an email in this >> thread? [...] > > Sure. Here's a markdown version below. Thank you. > Keep in mind you did not send this mail to me, I've only seen it by > manually checking the mailing list. Well, you did say, "You can make a comment on Notion or discuss it here" :) And there was no indication that you weren't subscribed to the list. Cheers, Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: > These are the ideas I've been thinking about for the future of OpenWrt > for a while. It looks complete enough to share it with all of you. > [...] > > https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb Please can you post the contents of that page as an email in this thread? Doing so will yield the following advantages: 1. People (like me) whose browsers/OSes are set up to accommodate accessibility issues will be able to read it. (Currently, if I visit that URL I only get a blank page. Maybe that is fixable in some way but it would probably take a lot of work, whereas a plain text email would be completely accessible to me.) 2. People reading the mailing list archives will be able to make sense of the discussion, even if the URL above has succumbed to entropy in the meantime. Thank you, Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Thu, Jan 20, 2022 at 10:42:15AM +0100, Paul Spooren wrote: >> Must confess: I was unaware of the ~16k issue body character limit... > > I discussed this with Drew (sourcehut developer) Thanks! That means there's a chance it will be documented and, if possible, fixed/improved. Incidentally, is this limit actually a problem for OpenWRT? (E.g. what % of bug reports would be affected?) >> # BROKEN HANDLING OF USER ACCOUNT DELETIONS >> >> [...] > > I think they are in a bit of a pickle there. Yes, GitHub messed up there. > If you delete everything a lot of issues miss comments and stop making > sense. Indeed. That would not be best practice at all, nor did I suggest it as a solution. > If you rename the the user account “aparcar” to a random string like > “mystery-blob-64”, other users can still “recreate” the deleted user > behavior by specifically looking for that _new_ name. Yes, best practice solution 2 is not *perfect*. But it's still a better solution than GitHub's current approach. Under solution 2, only people who already knew the original username of the contributor would be able to connect that username to the new one. (Anyone else would have to rely on those people, rather than GitHub, to make the connection.) Those people would have been aware of the original username's contributions anyway, so they would not gain any new information from GitHub as a result. (I.e. the user who had left GitHub would not suffer a reduction in privacy.) So, if GitHub followed solution 2, then GitHub would be upholding its legal responsibilities (e.g. GDPR Article 17 "right to erasure", etc). Especially if, having performed the replacement of the old name with the new one in all instances, GitHub then deleted its internal record of the connection between the old and new usernames. > Their solution seems to combine “anonymity" with usability (aka not > ruining issue discussions entirely). Alas, no. GitHub's solution combines: - *haphazard pseudonymity* (since the original username still appears in at-mentions, thereby potentially breaching GDPR Article 17, etc), and - *incomprehensibility* (both because "ghost" users can't be distinguished from each other; and because former users are referred to as "ghost" in some places and by their original usernames in others, even within the same thread). >> Worse still, because GitHub is proprietary and doesn't have a good >> way for users to report GitHub bugs or submit patches to fix them, >> bugs like this tend to go undiscussed and unfixed for years, leading >> to progressive corruption in GitHub discussions. > > They have a forum[0] and a “Discussion” thing[1] > > [0]: https://github.community OK, that's moderately new. (Just over 4 years old: https://github.blog/2017-11-01-connect-with-developers-around-the-world-on-the-github-community-forum/ .) It doesn't seem to be searchable. (At least not for some users.) Nor does it seem possible to post there without an account - and sign-up is unavailable for some users. > [1]: https://github.com/github/feedback/discussions OK, seems that's even newer. (Only just over a year old: https://github.com/github/feedback/commit/7f7cc0d6934fba7acc211f19a430b49f026e .) Again, it does not seem to be possible to post there without an account, and again, sign-up is unavailable for some users. >> # BROKEN SEARCH >> >> [...] > > This critique came up multiple times, are you aware of a better search > implementation? I’d be keen to find something better. From my > experience bugs.openwrt.org (aka flyspray) doesn’t do a much better > job here. Two counterarguments: - IME, Flyspray's search is far better than GitHub's. I haven't encountered search bugs in Flyspray like the one I kept encountering at GitHub. Can you give an example of a Flyspray search bug that is as severe? - Also, GitHub's issue/PR search bugs can't be fixed by users. Nor has Microsoft shown interest in fixing the one I mentioned. So that bug will continue impeding projects that depend on GitHub for issue-tracking or PRs. Any reasonably mature free software bug-tracker is an improvement over GitHub in this regard. >> # ACCESSIBILITY, PRIVACY, AND ETHICS PROBLEMS >> >> As previously discussed, e.g.: >> >> https://lists.openwrt.org/pipermail/openwrt-devel/2022-January/037546.html >> >> Understand that moving OpenWRT's issue-hosting to GitHub would make it >> impossible for some users to subscribe to OpenWRT's bug tracker to >> receive bug reports by email. > > I’m not familiar with Internet connectivity in Syria, Crimea and North > Korea, do you know if sr.ht and codeberg.org are reachable from over > there? The point isn't about whether governments of those territories block users from access to GitHub (or SourceHut, or Codeberg, or whatever). It's about whether the site owners (Microsoft; sr.ht LLC; Codeberg e.V.) prevent people in those territories
Re: Re: Switch issues and CI to GitHub
On Tue, Jan 25, 2022 at 09:45:52PM +0200, Sergey Ponomarev wrote: > Well, we may *speculate* and try to minimise risks but that's what I > tried to say: it's counterproductive. Avoiding unnecessary risks is productive. It's one of the ways in which projects and organisations stay afloat. > At least GH is big enough so that it can protect its users [...] Now > imagine that OpenWrt or SourceHut or whatewer website will be blocked. > Who will try to dispute? That is a mischaracterisation. AFAICT, GitHub is not (in general) blocked *by* Crimea. Rather, GitHub itself blocks users *in* Crimea (i.e. connecting from Crimea) from using *some* GitHub features: https://docs.github.com/en/github/site-policy/github-and-trade-controls#what-is-available-and-not-available GitHub is not "big enough" to protect users *from GitHub itself*, nor (given that it is headquartered in the USA) *from US Law*. > But hey, the GH CEO Nat Friedman even, while being a jew, personally > worked hard to unblock GH in Iran > https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/ Again a mischaracterisation. That issue didn't relate to GitHub being blocked *by* Iran. Rather, GitHub previously blocked users *in* Iran (i.e. connecting from Iran) from using some or all GitHub features. (BTW, Nat Friedman isn't GitHub's CEO anymore: https://www.theregister.com/2021/11/03/github_ceo_quits/ Also, I'm not sure he's Jewish, nor why that would be relevant.) > I just want to say that I personally agree with this concern and still > for me it looks like GH is at least not a worse option even from this > point of view. Codeberg and SourceHut both seem to be better than GitHub on this front. Best wishes, Sam -- 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: Re: Switch issues and CI to GitHub
On Tue, Jan 25, 2022 at 06:56:04PM +0200, Sergey Ponomarev wrote: > Speaking about GitHub and access to it from sanctioned territories > this is a really big concern. [..] Thank you for corroborating that concern. Some news reports, think-tank analysis, and legal guidance providers suggest the current sanctions will be extended in unspecified ways, if conflict escalates further in the region. If that happens, I would *speculate* that for instance GitHub might end up blocking Russia. "Washington is trying to maintain transatlantic unity to build a credible threat of sanctions as a deterrence against Moscow." https://www.theguardian.com/world/2022/jan/25/us-uk-and-europe-totally-united-in-the-face-of-russia-threat-to-ukraine-biden-says "If [Russia] launches a [new] military assault against Ukraine, Western sanctions should target the Russian economy in a major way. ... If the Kremlin choses lesser forms of aggression, consider strong sanctions anyway ... the United States and the European Union (EU) should use all options at their disposal, including intensified export controls." https://www.atlanticcouncil.org/blogs/new-atlanticist/what-if-russia-invades-ukraine-again-consider-these-options-for-sanctions-escalation/ "In order to prepare [for possible imminent sanctions, Western] businesses should do the following: - Identify all of their activities which relate to Russia and/or Russian counterparties and/or Russian origin goods - Review (and expand if necessary) existing KYC to identify all Russian counterparties and their beneficial owners ..." https://www.lexology.com/library/detail.aspx?g=839e7b81-ee92-40bb-87ca-4d9e96eeccb8 > But let's be honest: that's not only GitHub but any website in the US > or in NATO countries, I may be wrong, but I think some code/issue-hosting sites, including in the USA or in other NATO jurisdictions, are accessible from sanctioned territories. Potentially, that means SourceHut or CodeBerg would be better solutions than GitHub in this (and other) respects. Certainly, I could find nothing in their terms and conditions to indicate that they block users by territory: https://codeberg.org/codeberg/org/src/branch/main/TermsOfUse.md https://codeberg.org/codeberg/org/src/branch/main/PrivacyPolicy.md https://codeberg.org/codeberg/org/src/branch/main/en/bylaws.md https://codeberg.org/codeberg/org/src/branch/main/Imprint.md https://man.sr.ht/terms.md https://man.sr.ht/privacy.md (Basically, IIUC - IANAL - sanctions are intended as deterrents to commercial activities. Non-profit or volunteer activities are less affected. I would *hope* that humanitarian activities - like developing free software that extends the usable life of computer and network infrastructure - would remain unaffected by sanctions, except insofar as commercial US hosts like GitHub might be barred from involvement.) I will write to SourceHut and CodeBerg to ask whether they block users by territory. Sam -- 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: Switch issues and CI to GitHub
On Tue, Jan 18, 2022 at 03:38:43PM +0100, Paul Spooren wrote:
> ## Bug Tracker
>
> I looked today into migrating issues from bugs.openwrt.org over to
> GitHub.com, codeberg.org (GiTea) and todo.sr.ht (Sourcehut). [..]
>
> While sr.ht allows to import the large collection of issues, each
> message is limited to about 16.000 characters which would require us
> to truncate existing tasks and comments (and instead have them on some
> paste service). This limit is likely tied to the first class email
> support, users without an account can write to a special email address
> and create tickets without registering at all. Try it by sending
> something to ~aparcar/openwrt-bugs-import-tes...@todo.sr.ht
>
> [..] If we decide to move there, tools like gh2srht[3] would allow a
> quick migration. To get a feel what the bug tracker over at sr.ht
> would look like I migrated as much as possible, feel free to have a
> look[4].
A big thank you for doing this.
Must confess: I was unaware of the ~16k issue body character limit when
I proposed SourceHut. Did you find a public bug report or feature
request about that? (I looked just now. Could not find one myself, but
perhaps my search-fu is off today.)
If not, I will aim to post one, referencing this discussion thread.
Thanks again,
Sam
> A quick bug tracker conclusion, I'd be happy to use codeberg.org for
> issue tracking. Both sr.ht and codeberg.org are FOSS, GitHub not so
> much. [..]
GitHub not at all, last time I checked.
> As an immediate action, we might as well close down bugs.openwrt.org
> and open issues on GitHub.com without any migration of existing
> issues. Both users and developers already know the workflows over
> there and issues have a higher visibility. A migration away from
> GitHub over to coderberg or sr.ht is possible with much less effort
> than migrating away from flyspray.
I wish to caution against this.
Here are some reasons not to use GitHub for hosting issue/bug-reports.
# BROKEN HANDLING OF USER ACCOUNT DELETIONS
Best practice for handling user account deletions is to either:
1. If the user is happy for a record of their contributions to remain
attributed to them:
Leave the username shown unchanged in the remaining webpages where
it was used, so that at-mentions ("@username") within discussions
still work (aren't broken), and quotations remain correctly
attributed ("username commented MMM DD, ").
Or...
2. If the user is *not* happy for that:
Replace all instances of the username (at-mentions, quotation
attributions, etc) with a non-personally-identifying pseudonym, e.g.
"user12345".
This, too, retains comprehensibility and avoids link-breakage.
GitHub does neither.
Instead, GitHub replaces *some but not all* instances of a deleted
user's username with "Ghost". That can make it difficult to follow a
discussion (bug report, pull request, etc) featuring a now-deleted user.
See e.g. https://github.com/GothenburgBitFactory/taskwarrior/issues/2088
. If you didn't know that the comments therein that are now attributed
to "Ghost" were in fact made by me, it would be a confusing discussion
to follow.
(I later closed my GitHub account due to the increasing accessibility
problems I encountered on GitHub.)
That would be bad enough. But because *every* deleted user account is
processed this way by GitHub, it effectively conflates *all* deleted
users into one confusing account. For instance, the "Ghost" account
here is *not* me: https://github.com/matrix-org/synapse/issues/5778 .
But a third party would be unable to know that.
This is especially problematic if more than one now-deleted user
contributed to a single discussion. Both user's posts would now be
attributed - by GitHub's incompetence - to the same user, making it look
as though one, rather than several, people made those comments. (I
don't have an example at hand, but I'd be amazed if this hasn't happened
several times now, given GitHub's size.)
Worse still, because GitHub is proprietary and doesn't have a good way
for users to report GitHub bugs or submit patches to fix them, bugs like
this tend to go undiscussed and unfixed for years, leading to
progressive corruption in GitHub discussions.
# BROKEN SEARCH
There is no way within GitHub to avoid irrelevant search results. For
instance, if I search in the TaskWarrior repo for
is:issue in:title "TW-10"
I get results like "[TW-1733] taskwarrior 2.5.0 can not compile FreeBSD
10.1", because they have a "TW" and a "10" in the title. In other
words, GitHub fails to perform exact string matching.
Try it yourself:
https://github.com/GothenburgBitFactory/taskwarrior/issues?utf8=%E2%9C%93&q=is%3Aissue+in%3Atitle+%22TW-10%22
This makes GitHub's search feature a real pain to use.
Again, because GitHub is proprietary and lacks good ways to track or fix
GitHub bugs, ones like this go unfixed for years.
# ACCESSIBILITY, PRIVACY, AND ETHICS PROBLEMS
As previ
Re: Switch issues and CI to GitHub
On Sat, Jan 08, 2022 at 08:02:30PM +0100, Bjørn Mork wrote: > Sam Kuper writes: >> Not everyone has, or can have, a Microsoft (GitHub) account. > > Please explain. > > These terms are pretty much identical: > > > https://docs.github.com/en/github/site-policy/github-terms-of-service#b-account-terms > https://man.sr.ht/terms.md#account-terms > > You must be > a) human, > b) age 13 or older, and > c) obey US law. > > So who exactly can have a SourceHut account but not a Github account? At least anyone who: - doesn't run proprietary JavaScript; or - boycotts PRISM participants (e.g. Microsoft); or - boycotts GitHub or Microsoft for other reasons; or - accesses via Tor (IIRC - some time ago now). Also, people in the following territories have limited or no GitHub access: - Syria - Crimea - North Korea. People in those territories potentially have far more need of trustworthy routers, whose code is under their own control, than people almost anywhere else in the world. Developers there perhaps also need more than most to have chances to improve their skills, so as to build/maintain local infrastructure or to emigrate to an employer in a more hospitable country. Sam -- 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: Switch issues and CI to GitHub
On Sat, Jan 08, 2022 at 10:31:01AM -0600, Lao Shaw wrote: > github is used by so many open source projects and it becomes the de > facto git repo platform for many, This is a tragedy. > what makes openwrt so special to the point that github is not good > enough and your idea will do better (for long term with reliability > and easy to maintain)? what exactly is that and why all those OSS > projects are fine with it. This is majoritarian thinking. It's like architects neglecting, for centuries, to include step-free access in public buildings, because "Most people are OK with it." It excludes others. Not everyone has, or can have, a Microsoft (GitHub) account. Not everyone uses proprietary JavaScript or is otherwise able to report bugs or submit patches GitHub. > Move the CI and repos and issues and even discussions to github No, please DO NOT move OpenWRT core infrastructure to GitHub. > so the resource-limited core developers can focus on evolving openwrt > itself, instead of spending cycles on its infrastructure. If OpenWRT devs/maintainers want to outsource code/bug-hosting, please look at accessible FOSS hosts like SourceHut, as previously mentioned. Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: > Instead of maintaining flyspray and the server, I’d like to export all > flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. Please don't do this. GitHub has substantial accessibility and privacy flaws, compared to other options - and fails ethical code/bug-hosting criteria: https://www.gnu.org/software/repo-criteria-evaluation.html Please either stick with existing arrangements, or go with an ethical, accessible code/bug-host (e.g. SourceHut https://sr.ht ). Thanks, Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: missing email header
On Thu, Feb 18, 2021 at 07:46:47AM -0800, Brian Norris wrote: > On Thu, Feb 18, 2021 at 1:57 AM David Woodhouse wrote: >> On Wed, 2021-02-17 at 21:52 -0800, Brian Norris wrote: >>> They've suggested the mailman admin apply a patch ;) >> >> I believe I did so yesterday. > > [..] Awesome, thanks. Thank you, David, for this. (And for maintaining infradead generally!) Best, Sam -- 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: Patchwork and DMARC emails.
On Wed, Feb 17, 2021 at 02:47:57PM +0100, Etan Kissling wrote: > On 08.02.21, 10:33, Rosen Penev wrote: >>> My patches don't end up in Patchwork for some reason. >> It's because of DMARC. [..] > > Thanks for the hint about DMARC leading to Patchwork issues. [..] > > It seems that the OpenWrt mailing list breaks the signature by adding > the 'openwrt-devel mailing list' footer. IIUC, the OpenWrt mailing list software (Mailman 2.1.29, last time I checked) does not "break the signature". Instead, it wraps the original message and modifies the "From:" header before distributing the mail to list subscribers. That wrapped message is then (either by Mailman or by the MTA, I'm not sure) provided with a new signature that is valid for the domain in the new "From:" header. This might seem odd, but it is a very common and reasonable workaround for a fundamental flaw in DMARC. See: DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the "d=" tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. [..] Unfortunately this conflicts with the ways a number of mailing lists and other services have operated for many years. A number of approaches have been proposed: [..] 3. Take ownership of the email message by changing the RFC5322.From address to one in the mailing list's domain, and adding a DKIM signature for that domain. [For example:] B. Replace From: address, set Reply-To: to message author - Change the RFC5322.From address to an address within the mailing list's domain: u...@example.com => addr...@mailinglistdomain.com . - Set or change the RFC5322.ReplyTo address to the message author. - Add DKIM signature using the mailing list's domain. Source: https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F Also see: https://wiki.list.org/DEV/DMARC > For other mailing lists that do not modify email subject and body, > Patchwork has no problems with DMARC. Example: > https://patchwork.ozlabs.org/project/netfilter-devel/patch/a355cb9d-9b07-4d62-a228-a37c2660c...@apple.com/ > for mailing list: netfilter-de...@vger.kernel.org I don't know which headers Patchwork requires in order to be able to process an email correctly, but if it requires a non-empty "Subject:" header, then see: https://mail.python.org/archives/list/mailman-us...@python.org/thread/ZVM6I4UTDKHY4EKNLIBIWE4JNC2PYLIS/ Sam -- 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: Job board support on openwrt.org?
On Sat, Jan 23, 2021 at 06:57:53PM -0500, Etienne Champetier wrote: > Le sam. 23 janv. 2021 à 18:09, Sam Kuper a écrit : >> I suggest that if a vote is held, it should be a three-way vote >> between the following outcomes (which should probably be mutually >> exclusive): >> >> - OpenWRT Jobs wiki page; >> >> - openwrt-jobs mailing list; > > - OpenWrt Jobs forum section, with a "non endorsement" disclaimer at > the top >> >> - Do nothing. Thanks, fair point. I forgot the forum. (I mostly avoid Discourse.) So, a vote between four possible outcomes. -- 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: Job board support on openwrt.org?
On Sat, Jan 23, 2021 at 02:55:05PM +, Ted Hess wrote: > [T]here must be some sort of criteria (contributions, legitimate > business site or references) to get your name/outfit listed. And, as > Daniel said, we don't want to be in the business of certifying > contractors. Those two sentences seem to be slightly contradictory ;) Anyway, an alternative approach to the whole question of how to connect potential clients and contractors would be a mailing list, e.g.: openwrt-j...@openwrt.org . This would be a place for potential *clients/employers* to post jobs/tenders (to which potential contractors/employees could then reply on- or off-list). It would therefore place responsibility for establishing the credentials of the would-be employee or contractor entirely onto the potential employer or client, rather than onto the OpenWRT project. I.e. it is an inversion of the wiki page idea. I suggest that if a vote is held, it should be a three-way vote between the following outcomes (which should probably be mutually exclusive): - OpenWRT Jobs wiki page; - openwrt-jobs mailing list; - Do nothing. Sam P.S. I don't have an opinion on whether such a vote should be under FPTP or AV or Condorcet or some other voting method. For reference, I think Debian uses "Condorcet/Clone Proof SSD": https://www.debian.org/vote/2003/vote_0002 . -- 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: [PATCH] Revert "build: switch VERSION_REPO to HTTPS"
On Wed, Nov 25, 2020 at 03:11:24PM +0100, Petr Štetiar wrote: > Baptiste Jonglez [2020-11-25 12:41:18]: >> For the imagebuilder, it increases the *total* build time (not just >> download time!) by +50%: >> >> http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031406.html > > I don't consider 10 seconds dramatic increase of time, but it of > course depends on your use case. If you aim for faster builds you can > disable the HTTPS (one sed command) by yourself, proxy/cache the > downloads etc. > > One of the project's goal is standard installation secure by default, > which for me means HTTPS in this case and I'm willing to make this 10 > second tradeoff. +1 >> On a device, I suspect it will be much worse but I can't currently >> test that. It shouldn't be too hard, just make sure to clean opkg >> files between each test to have a proper apple-to-apple comparison. > > You hardly download 100 packages on device. You don't care if it takes > two minutes, because you're not doing it every day, it's running in > the background etc. +1 >> The main problem is the lack of persistent connection, which means >> doing a full expensive TLS exchange for each separate file download, >> however small it is. It's a lot of crypto for a small CPU on >> devices, > > You can turn off HTTPS if you prefer speed over maximum security +1 >> Thus, it's not reasonable to have this by default in a release. > > I don't agree. It has to be default in the next release :-) +1 >> I'm working on adding persistent connection support to opkg but it's >> not straightforward. > > Great, thanks! +1 Thanks to both of you for your efforts. I know everyone is trying to strike good trade-offs, but security should be prioritised by default. Thanks again, Sam -- 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: A proposal of https certificate assignment system for luci
On Mon, Oct 05, 2020 at 12:34:14PM -0400, Michael Richardson wrote: > Stefan Lippers-Hollmann wrote: >> On 2020-10-04, abnoeh wrote: >>> Few months ago there was some debate for how we handle certificate >>> for luci page: make user to click though certificate warning is not >>> that great for security so here is a proposal for autometically >>> assign a worldwide unique subdomain and how to make valid >>> certificate for it, and make sure we and connect to the device he is >>> expecting. It's a nice idea. Would be great to make it (or something like it) workable. The difficulties it raises are typical IoT security issues for which the world is only starting (& often still failing) to create solutions.[0] >> The elephant in the room remains, how do you propose to deal with >> firstboot conditions? Not every internet connection can be >> auto-detected [..] >> >> For these, the user will have to accept a self-signed certificate at >> least once for doing the initial configuration - at which point they >> can just stick to the already accepted self-signed certificate as >> well. > > There are really three use cases. I count four (see below). > 1) hardware that comes with openwrt. There is a manufacturer >controlled first boot. (This is relatively easy, and I have >running code) if we can build that subordinate CA that issues for >longer than the 90 days that the device is likely going to be in a >box (in a warehouse). The 90-day limitation (presumably referring to the validity duration of Let's Encrypt certificates) is a very good point. As of September 2020, maximum HTTPS certificate validity duration is currently 1 year, (well, 397 or 398 days).[1] Would even this be long enough? Maybe some pre-flashed routers end up being stored for >398 days before being shipped to customers.[2] > 2) hardware that didn't come with (this version) of openwrt, but is >first flashed. This probably a common case for most readers of >this list, and yes, we are probably smart enough to deal with >self-signed certificate the first time. >But, we are a small group. Exactly. If a user is flashing OpenWRT for the first time, & either doesn't understand the certificate warning &/or is following installation instructions don't mention it, they might think something has gone wrong, & might then either give up or waste time troubleshooting. It's extra usuability friction. > 3) [..] 4) hardware that is not connected to the Internet. Any security-conscious user, setting up a router for the first time, is likely to keep it disconnected from the Internet (either physically, or firewalled/blocked by an upstream device) until sure it has been configured to their requirements. Also, routers used in some local networks should not have or need an Internet gateway. This use-case (4) is probably the hardest one to solve, from an SSL/TLS certificate validity perspective. Sam [0]: https://dev.to/danielkun/where-is-https-for-iot-49ao https://neosmart.net/blog/2017/lets-stop-punishing-iot-devices-that-embrace-https-shall-we/ https://medium.com/@flynam/securing-your-iot-device-using-ssl-4643110ab901 https://www.ssl.com/article/securing-the-internet-of-things-iot-with-ssl-tls/ https://comodosslstore.com/resources/iot-ssl-certificates-for-connected-device-security-all-you-need-to-know/ [1]: https://www.globalsign.com/en/blog/maximum-ssltls-certificate-validity-now-one-year https://news.gandi.net/en/2020/07/the-maximum-duration-of-ssl-certificates-soon-to-be-reduced-to-1-year/ [2]: https://www.techrepublic.com/article/expiring-security-certificates-may-start-shutting-down-iot-devices/ -- 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: A proposal of https certificate assignment system for luci
On Thu, Oct 08, 2020 at 12:10:17AM +0200, Alberto Bursi wrote: > On 07/10/20 15:34, abnoeh wrote: >>> However, I think you are assuming a RA/DHCP-based WAN connection. >>> For PPPoE (which is still a thing in a lot of places, including >>> developing world, where last mile is often wifi), this won't work >>> that well. >> >> at the end entire reason we need certificate is we having a >> webserver, and all luci will do at the backend is running uci >> conmmand, can we run luci on client side, and send uci command to >> ssh, wrap it all under the name of "easy-installer"? >> >> if we don't have webserver we don't need a certificate. or uhttpd, in >> fact. > > Yeah, this is why Android/iOS apps should be considered as a way to > approach this issue. Not everybody (especially in the developing world, see above) has an Android or iOS device. Also, such an app would still have to either: 1. disregard certificate errors, or 2. handle old (& maybe even revoked) OpenWRT CA signatures/certificates, or 3. be subject to the same limitations as a web browser, defeating the point of an app. I guess you had 1 or 2 in mind, and I can see the appeal - I'm not dismissing your suggestion. However, an app might not be quite the panacea you imagine. 1 would be a security risk for app users, & 2 requires potentially uncomfortable trade-offs between security & usability thus again slightly defeating the point of an app. Ultimate, SSL/TLS on IoT is a hard problem: the two technologies are currently not *fully* mutually compatible without imposing some burden on the user. -- 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: Policy on BUILD_PATENTED
On Tue, Aug 11, 2020 at 01:30:08AM +0100, Mauro Mozzarelli wrote: > Citizens of the European Union are major contributors to OpenWrt and > other Open Source projects, The European Union, after several years of > debate. listened to its citizens, not corporations, and has put into > law that freedom from software patents that allows us all to > contribute to the community without fear of litigation nor constraints > imposed from monopolistic organizations. > > The EU and its citizens are too important stakeholders. EU law, and EU > citizens' will must too be respected. Mauro, I may be wrong, but I don't think anyone in this thread trying to deny the rights or freedoms of EU citizens, nor expressing disagreement with EU law on software patents. Rather, I think they are trying to point out that OpenWRT must also accommodate developers and users who live in jurisdictions that, sadly, do not grant them the same rights and freedoms as the EU does. I hope that one day more jurisdictions will take a European approach to software patents; but in the meantime, it would be tragic if a person in e.g. the USA were to inadvertently get into serious legal trouble simply by developing or using OpenWRT. So, the question is how to avoid that sort of tragedy. Ideally, the answer would still uphold user and developer rights to the maximum extent that each jurisdiction will permit. I see only two broad approaches available to avoiding the tragedy: 1. "Lowest common denominator". Any software that might place a developer or user in legal jeopardy, wherever they are in the world, should be excluded from distribution in OpenWRT. (I personally dislike this approach, because although it would avoid the tragedy mentioned above, it fails to uphold user and developer rights to the maximum extent that each jurisdiction will permit.) 2. "Selector switches". OpenWRT should contain a mechanism to allow the user/developer to choose whether or not to enable (and ideally, whether or not to even *receive*) patent-encumbered code. (I personally think this is the better approach.) I can see two ways to implement the "selector switches" approach: 2a. Compile-time switch. (This seems to be the current approach.) 2b. Separate package repositories. (This seems to be your proposed approach.) As I mentioned in a separate message in this thread, I suppport your proposal of (IIUC) a separate repo for patent-encumbered software, i.e. 2b above. I think that is better than a compile-time switch (2a above) for several reasons: - Usability. For instance, if a user downloads a binary of OpenWRT, then the installation/setup interface for that binary could ask the user whether or not to enable repositories other than the default (and perhaps explain to them the implications of this). This would not be easy to achieve with a compile time option. - Codebase hygiene. If the primary OpenWRT Git repo or package repo contains patent-encumbered code (which I think might be the case at the moment?), then this could put in jeopardy those OpenWRT developers who live in jurisdictions that uphold software patents, even if those developers never enable the relevant compile-time option. (I.e. because they would still be receiving/distributing patent-encumbered code, which might count as an infringement.) But if patent-encumbered code is kept cleanly separate from the primary OpenWRT Git repo and package repo, then any developer or user who wishes to completely avoid patent-encumbered code can easily do so; and likewise, any developer or user who wishes to install or hack on patent-encumbered code can equally easily do so. For maximum safety and choice for users and developers, I propose that OpenWRT adopts the following variant of approach 2b: Package repository name | Enabled | Non-free | Patented | by | software | software | default? | allowed? | allowed? +==+==+= main| Yes | No | No +--+--+- non-free* | No | Yes | No +--+--+- patent-encumbered | No** | No | Yes +--+--+- non-free-patent-encumbered* | No | Yes | Yes * By "non-free" here, I mean software that is non-free (i.e. does not uphold the Four Freedoms) for reasons *other* than patent encumbrance. Closed-source binary BLOBs, for example. ** I suppose it would be possible in principle, in future, to distribute "-eu" builds that have the patent-encumbered repository
Re: Policy on BUILD_PATENTED
On Mon, Aug 10, 2020 at 09:36:08AM +0100, Mauro Mozzarelli wrote: > If there is a minority who is unable to use parts of this software, Worth considering: do we know for sure that it's a minority? And is it even relevant whether it is a minority or a majority, as long as we know that some developers and some users do live or work in jurisdictions where software patents are litigiously upheld? > we can make it easy for that minority to be able to strip those > software components (or they can propose and implement changes that > achieve that themselves), but in no way limit or prevent everyone from > making use of it. IIUC, you are suggesting the creation of a new package repository through which OpenWRT devs who are based in countries (e.g. EU countries) that don't uphold software patents could distribute patent-encumbered software. Users would then be able to decide whether or not to enable that repo. This would be a *little* like Debian's "non-free" repository, insofar as it separates some packages into a different repository than usual (Debian's default repo is called "main") based on their legal status: https://www.debian.org/doc/debian-policy/ch-archive#s-non-free . I emphasised "little" in the previous sentence because Debian's non-free repo was based on copyright (not patents), whereas your proposal AIUI is based on patents (not copyright). See, e.g.: On Mon, Jul 11, 2005 at 11:10:57AM +0100, Daniel James wrote: > [..] As a short-term measure, I suggest that the xmms package in > Debian is split into xmms and xmms-mpg123 with the latter package > moving to non-free. I have cc'd the maintainers of the xmms > package in Debian. This is generally not regarded as an appropriate use of non-free; patent-encumbered works cause problems whether they're shipped in non-free or in main. [..] Steve Langasek Source: https://lists.debian.org/debian-legal/2005/07/msg00082.html To me, as an OpenWRT user, your proposal seems reasonable, but IANAL. It would seem wise for OpenWRT devs to seek advice on the proposal, from SPI and/or SFC. Best wishes, Sam -- 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: Policy on BUILD_PATENTED
On Sun, Aug 09, 2020 at 01:21:26PM -0700, Rosen Penev wrote: > On Sun, Aug 9, 2020 at 6:09 AM Sam Kuper wrote: >> On Sun, Aug 09, 2020 at 10:55:37AM +0100, Sam Kuper wrote: >>> On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: >>>> Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : >>>>> Whenever discussion about patents arise, I usually point to >>>>> Fedora whose parent company is Red Hat, which is based in the US. >>>>> There are many things that they do not distribute that OpenWrt >>>>> does for legal reasons. Should Fedora's practices be mirrored or >>>>> should a more liberal policy regarding patented functionality be >>>>> taken? >>> >>> For OpenWRT at least, might Debian be a more appropriate exemplar >>> than Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is >>> represented in some sense by SPI: >>> https://www.spi-inc.org/projects/debian/ . >>> >>> The debian-legal mailing list archives can be searched for the >>> decisions taken by the debian-legal team, and the reasoning behind >>> those decisions: https://lists.debian.org/debian-legal/ . >> >> Here is an example of discussion on that list, that is on a similar >> topic to the original question in this thread: patent-encumbered >> software. It also speaks to differences between the Debian and Red >> Hat policies. >> >> (The example is 15 years old, so perhaps not representative of >> current policy. I'm just giving it as an example.) >> >> [The] reason Debian continues to include the mp3 decoder library >> is that this patent, like so many other software patents, does >> not appear to be actively enforced. This is the standard Debian >> uses in deciding whether to distribute the software; Red Hat >> evidently uses a different standard. > > Yep. And this is the issue. Which standard is to be followed, Red > Hat's or Debian? [..] > > I'd like a decision on this issue. [..] Yes; that's why I suggested contacting SPI and/or SFC.* Those organisations exist to help libre software projects to thrive. They might be able to provide suitable legal advice to ensure that if OpenWRT adopts a policy on how to deal with patented software, that policy would be a well-informed one that provides the maximum benefit to OpenWRT's users, within the OpenWRT devs' risk appetite. I'm not an OpenWRT dev, so I don't think it would be appropriate for me to contact SPI or SFC on behalf of OpenWRT; but you seem to be, so perhaps you should? Maybe CC, into that message, any other devs who are interested in formulating an OpenWRT patent policy (and at least CC the SPI OpenWRT liaisons, Imre Kaloz and John Crispin)? And if you get any useful info from SPI or SFC, then maybe use it to help formulate an OpenWRT patent policy RFC and post it to this mailing list (e.g. as a follow-up to this thread)? (For an example of a recent OpenWRT RFC thread, see Paul Spooren's thread on PKG_RELEASE policy. To find the latter in your inbox, search for Message-ID 5ee96304-afff-c527-4c52-a9704bb9b...@aparcar.org .) Good luck, Sam * Note 1: SFC is not to be confused with SFLC. They are different organisations run by different people. Note 2: I would not recommend contacting SFLC, for the reasons given by Matthew Garrett: https://mjg59.dreamwidth.org/49370.html . This creates a possible difficulty, insofar as SPI currently lists SFLC as its legal advisor: https://www.spi-inc.org/corporate/board/ . A reasonable solution to that difficulty would be that if you do contact SPI, you could say in that message that you would prefer SPI not to contact SFLC on your behalf without first checking with you. -- 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: Policy on BUILD_PATENTED
On Sun, Aug 09, 2020 at 10:55:37AM +0100, Sam Kuper wrote: > On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: >> Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : >>> Whenever discussion about patents arise, I usually point to Fedora >>> whose parent company is Red Hat, which is based in the US. There are >>> many things that they do not distribute that OpenWrt does for legal >>> reasons. Should Fedora's practices be mirrored or should a more >>> liberal policy regarding patented functionality be taken? > > For OpenWRT at least, might Debian be a more appropriate exemplar than > Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is represented > in some sense by SPI: https://www.spi-inc.org/projects/debian/ . > > The debian-legal mailing list archives can be searched for the > decisions taken by the debian-legal team, and the reasoning behind > those decisions: https://lists.debian.org/debian-legal/ . Here is an example of discussion on that list, that is on a similar topic to the original question in this thread: patent-encumbered software. It also speaks to differences between the Debian and Red Hat policies. (The example is 15 years old, so perhaps not representative of current policy. I'm just giving it as an example.) [The] reason Debian continues to include the mp3 decoder library is that this patent, like so many other software patents, does not appear to be actively enforced. This is the standard Debian uses in deciding whether to distribute the software; Red Hat evidently uses a different standard. Source: https://lists.debian.org/debian-legal/2005/07/msg00082.html -- 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: Policy on BUILD_PATENTED
On Mon, Aug 03, 2020 at 07:11:13PM +0300, Etienne Champetier wrote: > Le lun. 3 août 2020 à 00:04, Rosen Penev a écrit : >> The remerged OpenWrt project is legally represented by the Software >> in the Public Interest (SPI) - an US 501(c)(3) non-profit >> organization which is managing our OpenWrt trademark, handling our >> donations and helping us with legal problems. > > Software Freedom Conservancy (future replacement of SPI) is also US > based > >> Whenever discussion about patents arise, I usually point to Fedora >> whose parent company is Red Hat, which is based in the US. There are >> many things that they do not distribute that OpenWrt does for legal >> reasons. Should Fedora's practices be mirrored or should a more >> liberal policy regarding patented functionality be taken? For OpenWRT at least, might Debian be a more appropriate exemplar than Fedora? Unlike Fedora AFAIK, but like OpenWRT, Debian is represented in some sense by SPI: https://www.spi-inc.org/projects/debian/ . The debian-legal mailing list archives can be searched for the decisions taken by the debian-legal team, and the reasoning behind those decisions: https://lists.debian.org/debian-legal/ . In cases where doubt still remains, OpenWRT devs should probably consult with staff of the SPI (currently, the project liaisons are listed as John Crispin and Imre Kaloz: https://www.spi-inc.org/projects/openwrt/ ) and/or with staff of the Software Freedom Conservancy. IMO, this should be done via a publicly archived mailing list, for transparency. -- 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
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: 'tr' character class support?
Dear all, I'm not an OpenWRT dev, just a lurker on the mailing list & a sometime user of OpenWRT. (Thank you to all the devs & maintainers of OpenWRT & packages, btw.) So, my view might not count for much, but ... On Fri, Jul 10, 2020 at 09:36:03PM -0400, Eric Luehrsen wrote: > I did a comparison, which gave about a 500 byte increase [..] I'd say > that difference is acceptable [..] > > Unless there is an overwhelming size cost, basic POSIX binaries should > be provided "POSIX'ly correct" by default. [..] On Sat, Jul 11, 2020 at 11:26:23AM -0700, Jordan Geoghegan wrote: > On 2020-07-11 06:08, Magnus Kroken wrote: >> [..] Making tr compliant when it's there anyway and has this small >> cost is good. [..] > > [..] I agree about having to make certain sacrifices in order to > remain usable on smaller devices, the only reason I brought it up was > due to the dangerous way in which 'tr' was configured to ignore > character classes and treat all characters literally, rather than at > least printing an error. I'm glad to see you've decided to re-enable > tr POSIX stuff. Thanks :) ... I agree with Eric, Magnus & Jordan: POSIX-compliance is *definitely* worth implementing when the size cost is negligible, as it is in this case. It will reduce the risk of bugs in cases where: - OpenWRT devs or package maintainers, e.g. new ones, might assume POSIX-compliant `tr` behaviour (& might forget to test for non-compliance); or - third-party package authors do likewise. Such bugs could end up having subtle & insidious effects, hard to diagnose. So, I would be grateful if the OpenWRT devs would make the suggested change to the default Busybox compilation option. (I say this as someone who owns one or two 4/32 devices, so please don't think I'm not conscious of size constraints.) > I'm not sure if there's any interest in making use of tr+classes for > base system scripts, but I'd be happy to go through and start cleaning > stuff up if there is interest. > > Attached please find a patch for > "package/network/services/hostapd/files/hostapd.sh" [..] I also agree with Jordan's suggestion to fix OpenWRT base system scripts so that they would use `tr` classes instead of attempting to work around the current POSIX non-compliance by using literal ranges. This way, users - especially users who change locales - will be less likely to experience bugs. We're not in the pre-Unicode, pre-globalisation era anymore. OpenWRT is used internationally & no user should be penalised for switching locales or performing other innocent actions that could trigger bugs with the current scripts. So, I would also be glad if Jordan's suggestion (& patch) could be accepted. Thank you for hearing me out, & thanks again for developing/maintaining OpenWRT! Sam -- 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
