Gregory's ServerToday, they published the Android Security Bulletin for October with the security patch backports to the initial releases of Android 12, 12L, 13 and 14. There should be a monthly release based on Android 14 QPR3 today or tomorrow. If not, we'll do a release with the backports.
|
11 comments
 Recent examples where we could have waited if we knew the release date in advance: August early ASB release: https://grapheneos.org/releases#2024080500 August monthly release: https://grapheneos.org/releases#2024080600 July early ASB release: https://grapheneos.org/releases#2024070200 July monthly release: https://grapheneos.org/releases#2024070201 For months with quarterly and yearly releases, it's common for our early ASB release approach to get those patches to our users days or even weeks early. However, the recent months where they released on Tuesday instead of Monday wasted our time without getting much from it. Fixing conflicts for the backports can take a lot of time and often requires very skilled work to do it properly as it will for one of the patches this month. Doing an extra OS release also takes a lot of our resources. It takes a lot of local compute time and testing effort. This shouldn't be something we need to spend resources on because we should know the official release schedule and should have early access. It's harming Android more than GrapheneOS since these kinds of artificial issues inflicted on us are exactly why we stopped contributing. @GrapheneOS You folks are doing incredible work. I see that you accept donations through the GrapheneOS Foundation, are you looking for help in areas other than financial? @elricofmelnibone Yes, we need help in other areas. It would be great if there were more people doing Alpha and Beta testing well where they do thorough testing after releases are announced in the chat room. We need quick feedback about regressions and for it to be separated from info about existing issues which already existed. More contributors to the code would be nice and has been our main way to hire people. Hiring people not contributing already hasn't actually worked out well yet. @elricofmelnibone GrapheneOS is also under attack from groups trying to harm it including shady organizations pretending to have private and secure mobile devices who feel threatened by a far better option being available for free. There are a couple YouTubers who joined in us this to promote themselves and essentially directed their large communities to harm us across platforms spreading fabricated stories and misinformation about GrapheneOS. It would be best if our community countered this. @elricofmelnibone We refute it when we see it, but it would be far better if we had a community which was far more active at defending the project against these attacks. It would avoid us needing to spend nearly as much time on it as we do and would also help to protect us from getting attacked for debunking misinformation. A lot of the attacks are based on making false claims and then claiming our team in insane, delusional, etc. after posting detailed replies debunking low effort lies. @elricofmelnibone There are people actively trying to harm GrapheneOS through getting very low quality news sites to repeat the attacks and then trying to reference that from Wikipedia, etc. Almost all of this involves people posting dishonest attacks referencing other people doing the same in cycles. This is really the main area we need help so we can focus on development and much less on defending ourselves. It's harder for people to help us with the spurious legal system attacks, etc. @GrapheneOS @elricofmelnibone I'm doing the best I can using my account @Andromxda@lemmy.dbzer0.com on Lemmy, the federated Reddit alternative, to refute any false claims about GrapheneOS and Android security in general Unfortunately there is a lot of misinformation from people who do not understand the topic at all I haven't seen that much harassment on Lemmy, just people who aren't well informed, and don't realize it |
We've started preparing a release based on the backports in case we need it. One of the patches has major conflicts since these are meant for the initial Android 14 not Android 14 QPR3. It's unfortunate we have to waste resources because they won't share this information with us.