| ▲ | izacus 4 hours ago |
| It's Cyber Resilience Act (Regulation (EU) 2024/2847) - if there's a security patch that shows up in public, then the manufacturers are fined if they don't immediately roll it out as an update ("without undue delay"). I think that's the one that made a lot of OEMs pull back on opensource publishing, because their legal departments want to batch the CVE monitoring and reporting obligations into smaller batches. |
|
| ▲ | microtonal 4 hours ago | parent | next [-] |
| Aren’t most OEMs in violation anyway because Linux (as in the kernel) gets regular security patches and most OEMs are on ancient kernel versions? Also, major Android releases and QPR2s have many security fixes (anything not marked high/critical), yet OEMs are not rolling them out (QPR2) or very late (major releases). Just to say that OEMs were probably violating the act already before Google started withholding source code. I also think it’s an attempt of Google closing up AOSP more, otherwise they wouldn’t make it so darn hard to get updated Pixel kernel trees. |
| |
| ▲ | dathinab 4 hours ago | parent | next [-] | | probably yes withholding security updates seems to avoid a law which requires rolling out security updates seems very much like something which needs to be fixed one way or another | |
| ▲ | imtringued 3 hours ago | parent | prev | next [-] | | This reminds me of the OpenAI hack against Hugging Face. Regulators present an impossible goal to the companies to implement, instead of implementing the goal, the companies try to reward hack their way around it. The end result is that they basically try to make it impossible to know about vulnerabilities because that would start the clock. | | |
| ▲ | microtonal 2 hours ago | parent [-] | | But doing timely security updates is not impossible. Apple does it, GrapheneOS does it, Google does it with Pixel, Samsung is nearly doing it on flagships. But many Android OEMs are probably terrible at software engineering and have their attention spread across multiple SoCs, etc. It’s their own fault. | | |
| ▲ | hardbass 43 minutes ago | parent [-] | | Then they should leave it to others. Release specs and sources and let whoever wants, maintain the firmwares. |
|
| |
| ▲ | izacus 3 hours ago | parent | prev [-] | | I think it's mostly the "you need to monitor CVEs and write report within 24/72 hours" that causes OEMs pain and they prefer to have less work than more. Also - the reality of what you think is ok and what a corporate legal department think its ok is... rarely the same -_- | | |
|
|
| ▲ | arghwhat 4 hours ago | parent | prev | next [-] |
| nit: "without undue delay" does not mean "immediately" under any legal interpretation, only that the timeline should not be longer than necessary. This leaves a lot of wiggle-room in favor of the manufacturer, and mainly rules out that they go "eh, we'll look at all these in half a year maybe". As long as they start the process and it is not absurd from an industry standards perspective, they should be good. They can have slow processes, including being a good bit slower than their peers, without running afoul of "without undue delay". |
| |
| ▲ | imtringued 3 hours ago | parent | next [-] | | They have literal 24 hour and 72 hour deadlines. Obviously, they might put a blind eye to it if you are reliable but delayed the reporting by a day, but the 24 hour and 72 hour deadlines are a fact. You have to initiate the reporting immediately. | | |
| ▲ | arghwhat 2 hours ago | parent | next [-] | | You are mixing unrelated requirements together here. > The CRA requires manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of their product with digital elements. They need to submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours. These deadlines are entirely unrelated to the availability of security fixes and delays in deliverying them. | |
| ▲ | alerighi 3 hours ago | parent | prev [-] | | This is impossible to happen. Security flaws are discovered almost every day (now that they are automating it with AI there are a ton of reports), pretending the manufacturer releases an update in 1 day is nonsense. Just building the code alone it would take a lot of time, and of course you have to test it at least a bit before giving it out to the end users, you can't pretend to rollout on a global scale a nightly build without first at least some level of QA risking bricking user devices. And you have to consider that phone manufacturer doesn't work h24 and 7/7 of course to give out patches. I think that we are fortunate if the whole process takes less than a month, not a day. |
| |
| ▲ | izacus 3 hours ago | parent | prev [-] | | > nit: "without undue delay" does not mean "immediately" under any legal interpretation, only that the timeline should not be longer than necessary. This leaves a lot of wiggle-room in favor of the manufacturer, and mainly rules out that they go "eh, we'll look at all these in half a year maybe". Well, the corporate lawyers think otherwise at those corporations, so I'm not sure how much your interpretation counts :) | | |
| ▲ | arghwhat 2 hours ago | parent [-] | | I do not believe that any corporate lawyer would think that. It does not read like that in neither plain english nor legalese. Maybe the misunderstanding stems from the related common misuse of "as soon as possible" as "immediately"? A corporate lawyer would, however, always suggest to minimize/reduce/delay any legal obligations so as to minimize risk of liability, regardless of whether said obligation is easy to comply with or not. |
|
|
|
| ▲ | aboringusername 3 hours ago | parent | prev [-] |
| From what I see [1] if you search for 'undue delay', it's only: > an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it > without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively > without undue delay and in any event within 24 hours of the manufacturer becoming aware of it > without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident "Sorry your honour, we only became 'aware of it' 2 years later, pinky promise ;)". So any competant authority would have to prove when they 'became aware of it', whatever the test to pass that threshold means. [1]: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng |
