4 ms·

This is just the user-space aspect of the modem, it still has a 40MB proprietary firmware blob that does all the fun stuff. Also running long end-of-life and i

by _rdvw 3y ago

This is just the user-space aspect of the modem, it still has a 40MB proprietary firmware blob that does all the fun stuff. Also running long end-of-life and insecure Linux 3.18: https://github.com/the-modem-distro/quectel_eg25_kernel/blob/linux-3.18.140/Makefile https://github.com/the-modem-distro/quectel_eg25_kernel/blob... I submitted a PR with my CVE auto-patcher which fixed many issues including numerous modem related ones which was ignored and closed: https://github.com/the-modem-distro/quectel_eg25_kernel/pull/7 https://github.com/the-modem-distro/quectel_eg25_kernel/pull...

c-c-c-c-c 3y ago
[flagged]
- _rdvw 3y ago
  I'm happy to see things done right in the form of mainlining the necessary parts, but that takes _years_. Users shouldn't have to suffer with known security issues that have fixes readily available. I've used this tool to support many dozens of end-of-life devices working well over the past six years, and it is even purpose-built for these Android/Qualcomm downstream kernels.
  - tadfisher 3y ago
    Maybe you could rework your process a bit, as a drive-by patchset with 400+ commits is not a great way to start a conversation. Some ideas: - Open an issue or post to the project's mailing list, proposing the use of your tool. - If you don't do so already, have your tool only apply patches to code that is actually compiled for the target, e.g. give it a .config and trace which source files are used in make. - Obtain the hardware for the devices your tool supports and donate your time to test the changes generated by your tool.
    - _rdvw 3y ago
      Only applying patches that may be necessary is absolutely non-trivial to compute, especially with dependent patchsets, kernel trees used by multiple devices, or future changes to their configs. I already provide monthly software updates for 170 devices using this tool which I've personally tested on two dozen devices plus many user reports on others. Making a (near) working PR conversation starter to demonstrate the tool I've spent years of my time on is my contribution. In this case where I didn't have a PinePhone I explicitly found a closest match (Google Pixel 1/marlin iirc) to the kernel at hand and applied my fix database to it as matching to increase the chance that it would be successful. I have absolutely zero doubts that someone can't apply the PR and be up and running in an hour. edit: to be extra clear, I'm not a company selling this tool or anything, it is purely a passion project for me and I do want others to use it or help them use it.
fabrice_d 3y ago
Your PR was not ignored, and the author explained why they could not merge it as-is. After your PR got closed you explained how to create the patchset from kernel.org sources which is the right approach, maybe that happened in other commits?
- _rdvw 3y ago
  If it couldn't be merged as-is that is completely understandable, but why close it then? Why not say "can you tame this back?" instead the response was "this will break things and maybe you added malware".
  - 0x6c6f6c 3y ago
    The project maintainer may not want to keep PRs open that are not acceptable as is. There is zero functional difference between holding the PR open indefinitely (and many times follow-up just never happens) and closing the PR until changes are made and where a new PR is then opened.
    - lucideer 3y ago
      > There is zero functional difference This isn't true though. There's may be no functional difference for the receiver/merger/maintainer but there's a large difference for the submitter - this kind of approach can often be the demotivational difference between finishing and abandoning branch work. Sure, 95% of such PRs might never go anywhere, but with the contribution pool being that small, is there a strong reason to shrink it further? I get that maintainers have a lot on their shoulders & expecting them to be perfect receivers of outside contrib is expecting a lot, but it's also why there's so much on their shoulders.
  - biktor_gj 3y ago
    First things first: I never implied (or wanted to imply) that you were introducing malware in that patchset, just that you could introduce it and I wouldn't be able to find that in a PR so big. Sorry if that came out wrong. Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio. And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline. For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)
palata 3y ago
Respectfully, you really, seriously need to work on your communication skills. You seem to be doing good work and I respect that (I use Mull, for one), but... you systematically sound fairly aggressive and complaining about everybody. Just for that I wouldn't want to contribute to any of your projects, and I wouldn't want to depend too much on them either (who knows who you will piss off next and where your projects will go). For instance, let's look at what you describe here as "my PR was fixing a ton of stuff but it was ignored and closed". First, the title of your PR is "Make the kernel less awful"... really? How would you feel if I opened a PR saying "Make DivestOS suck a little less, but let's be honest, it will still be a piece of shit after that"? Not even mentioning that you say "Untested, but shouldn't require more than a handful drop/reverts". So you just come and drop a huge PR that you haven't tested, and then you complain that others don't pick it up? Before closing your PR, the maintainer said: > Don't get me wrong, it's impressive, but there's no way I'm going to merge this. You can't send someone 424 patches to a repo and expect them to stop everything they're doing for a month and checking them one by one in case just one of them fucks up the entire system (or contains some kind of malicious code), even less so on a 3.18.140 kernel that originally comes from Qualcomm. That is very fair, and I would not call that "being ignored" at all. Keep up the good work, and learn to communicate in a constructive way!
- hospitalJail 3y ago
  Btw this is a great case for Chatgpt. I am also aggressive over the internet. I don't know why. I'm so chill IRL. Ive learned to copypaste my message and ask chatgpt to make it nice, but not eliminate the point. I don't copypaste what it says, but I do find sentences that are nice, but still make my point. Its sooo good.
  - palata 3y ago
    That is an interesting take indeed. And I respect the fact that you realized that you sound aggressive online and took action. I will actually think about that: English is not my first language, and I feel like I sometimes unwillingly sound aggressive.
- _rdvw 3y ago

by _rdvw 3y ago

c-c-c-c-c 3y ago

[flagged]

_rdvw 3y ago
I'm happy to see things done right in the form of mainlining the necessary parts, but that takes _years_. Users shouldn't have to suffer with known security issues that have fixes readily available. I've used this tool to support many dozens of end-of-life devices working well over the past six years, and it is even purpose-built for these Android/Qualcomm downstream kernels.
- tadfisher 3y ago
  Maybe you could rework your process a bit, as a drive-by patchset with 400+ commits is not a great way to start a conversation. Some ideas: - Open an issue or post to the project's mailing list, proposing the use of your tool. - If you don't do so already, have your tool only apply patches to code that is actually compiled for the target, e.g. give it a .config and trace which source files are used in make. - Obtain the hardware for the devices your tool supports and donate your time to test the changes generated by your tool.
  - _rdvw 3y ago
    Only applying patches that may be necessary is absolutely non-trivial to compute, especially with dependent patchsets, kernel trees used by multiple devices, or future changes to their configs. I already provide monthly software updates for 170 devices using this tool which I've personally tested on two dozen devices plus many user reports on others. Making a (near) working PR conversation starter to demonstrate the tool I've spent years of my time on is my contribution. In this case where I didn't have a PinePhone I explicitly found a closest match (Google Pixel 1/marlin iirc) to the kernel at hand and applied my fix database to it as matching to increase the chance that it would be successful. I have absolutely zero doubts that someone can't apply the PR and be up and running in an hour. edit: to be extra clear, I'm not a company selling this tool or anything, it is purely a passion project for me and I do want others to use it or help them use it.

fabrice_d 3y ago

Your PR was not ignored, and the author explained why they could not merge it as-is. After your PR got closed you explained how to create the patchset from kernel.org sources which is the right approach, maybe that happened in other commits?

_rdvw 3y ago
If it couldn't be merged as-is that is completely understandable, but why close it then? Why not say "can you tame this back?" instead the response was "this will break things and maybe you added malware".
- 0x6c6f6c 3y ago
  The project maintainer may not want to keep PRs open that are not acceptable as is. There is zero functional difference between holding the PR open indefinitely (and many times follow-up just never happens) and closing the PR until changes are made and where a new PR is then opened.
  - lucideer 3y ago
    > There is zero functional difference This isn't true though. There's may be no functional difference for the receiver/merger/maintainer but there's a large difference for the submitter - this kind of approach can often be the demotivational difference between finishing and abandoning branch work. Sure, 95% of such PRs might never go anywhere, but with the contribution pool being that small, is there a strong reason to shrink it further? I get that maintainers have a lot on their shoulders & expecting them to be perfect receivers of outside contrib is expecting a lot, but it's also why there's so much on their shoulders.
- biktor_gj 3y ago
  First things first: I never implied (or wanted to imply) that you were introducing malware in that patchset, just that you could introduce it and I wouldn't be able to find that in a PR so big. Sorry if that came out wrong. Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio. And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline. For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)

palata 3y ago

Respectfully, you really, seriously need to work on your communication skills. You seem to be doing good work and I respect that (I use Mull, for one), but... you systematically sound fairly aggressive and complaining about everybody. Just for that I wouldn't want to contribute to any of your projects, and I wouldn't want to depend too much on them either (who knows who you will piss off next and where your projects will go). For instance, let's look at what you describe here as "my PR was fixing a ton of stuff but it was ignored and closed". First, the title of your PR is "Make the kernel less awful"... really? How would you feel if I opened a PR saying "Make DivestOS suck a little less, but let's be honest, it will still be a piece of shit after that"? Not even mentioning that you say "Untested, but shouldn't require more than a handful drop/reverts". So you just come and drop a huge PR that you haven't tested, and then you complain that others don't pick it up? Before closing your PR, the maintainer said: > Don't get me wrong, it's impressive, but there's no way I'm going to merge this. You can't send someone 424 patches to a repo and expect them to stop everything they're doing for a month and checking them one by one in case just one of them fucks up the entire system (or contains some kind of malicious code), even less so on a 3.18.140 kernel that originally comes from Qualcomm. That is very fair, and I would not call that "being ignored" at all. Keep up the good work, and learn to communicate in a constructive way!

hospitalJail 3y ago
Btw this is a great case for Chatgpt. I am also aggressive over the internet. I don't know why. I'm so chill IRL. Ive learned to copypaste my message and ask chatgpt to make it nice, but not eliminate the point. I don't copypaste what it says, but I do find sentences that are nice, but still make my point. Its sooo good.
- palata 3y ago
  That is an interesting take indeed. And I respect the fact that you realized that you sound aggressive online and took action. I will actually think about that: English is not my first language, and I feel like I sometimes unwillingly sound aggressive.
_rdvw 3y ago