all 41 comments

sorted by: hot top controversial new old
[–] 111 points 3 weeks ago* (3 children)

i dont want to sound like a dick but they really should've just forked the LineageOS apps that are maintained like they did with seedvault. this feels like theyre reinventing the wheel, or NIH

  • source
  • hideshow 3 child comments
  • [–] 46 points 3 weeks ago (2 children)

    Would be great if those two could play nicely. Lineage features with GOS security would be the bees knees.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 85 points 3 weeks ago* (last edited 3 weeks ago) (12 children)

    They could just... work with the community and use preexisting community apps

    That is not how they role I guess

  • source
  • hideshow 12 child comments
  • [–] 1 point 2 days ago

    Seeming how the developers respond to things, I feel like they would easily start a flame war with someone.

    But you sometimes need to have crazy opinionated people to run a project, that way you know their goals won't change and they aren't going to sell out easily.

  • source
  • parent
  • [–] 33 points 3 weeks ago (6 children)

    The maintainers are very picky and cynical about privacy & security. For better or for worse

  • source
  • parent
  • hideshow 6 child comments
  • [+] -14 points 3 weeks ago (4 children)

    More like the maintainers want to be the center of attention

    There are plenty of other projects they could work with that would genuinely make Graphene better but they don't because they want to pretend like they are some exclusive clud. In reality almost all of the Graphene OS features are either built into AOSP or are easy to implement via an app from F-droid

  • source
  • parent
  • hideshow 4 child comments
  • [–] 11 points 3 weeks ago

    No, most of Graphenes features are not implemented in AOSP. There are a lot of CVE patches from Graphene that land in AOSP, but it doesn't have any of the hardening or sandboxing that makes GrapheneOS what it is.

  • source
  • parent
  • https://grapheneos.org/releases#2026090700

    All of the Android 17 security patches from the current September 2026, October 2026, November 2026, December 2026, January 2027, February 2027 and March 2027 Android Security Bulletins are included in the 2026090701 security preview release. List of additional fixed CVEs:

    A short list of existing CVEs not available to the public

    • Critical: CVE-2026-28591, CVE-2026-28604, CVE-2026-28639, CVE-2026-28653, CVE-2026-28662, CVE-2026-28666, CVE-2026-45515, CVE-2026-45531, CVE-2026-49879, CVE-2026-49882, CVE-2026-49884, CVE-2026-49918, CVE-2026-49921, CVE-2026-49926, CVE-2026-49927, CVE-2026-49932, CVE-2026-49933, CVE-2026-55256, CVE-2026-55265, CVE-2026-55268, CVE-2026-55269, CVE-2026-55273, CVE-2026-55277, CVE-2026-55280, CVE-2026-58814, CVE-2026-58820, CVE-2026-58823, CVE-2026-58835, CVE-2026-58865, CVE-2026-58868, CVE-2026-58876, CVE-2026-58880, CVE-2026-58882, CVE-2026-58984
    • High: CVE-2025-22424, CVE-2025-22426, CVE-2025-22442, CVE-2025-48564, CVE-2025-48565, CVE-2025-48566, CVE-2025-48600, CVE-2026-0053, CVE-2026-28581, CVE-2026-28582, CVE-2026-28584, CVE-2026-28588, CVE-2026-28593, CVE-2026-28594, CVE-2026-28599, CVE-2026-28600, CVE-2026-28602, CVE-2026-28603, CVE-2026-28606, CVE-2026-28607, CVE-2026-28612, CVE-2026-28613, CVE-2026-28614, CVE-2026-28617, CVE-2026-28619, CVE-2026-28620, CVE-2026-28622, CVE-2026-28623, CVE-2026-28624, CVE-2026-28626, CVE-2026-28627, CVE-2026-28630, CVE-2026-28631, CVE-2026-28633, CVE-2026-28634, CVE-2026-28635, CVE-2026-28638, CVE-2026-28643, CVE-2026-28645, CVE-2026-28650, CVE-2026-28652, CVE-2026-28655, CVE-2026-28657, CVE-2026-28658, CVE-2026-28660, CVE-2026-28663, CVE-2026-28664, CVE-2026-28665, CVE-2026-28667, CVE-2026-28668, CVE-2026-28671, CVE-2026-45513, CVE-2026-45514, CVE-2026-45517, CVE-2026-45518, CVE-2026-45519, CVE-2026-45520, CVE-2026-45521, CVE-2026-45522, CVE-2026-45523, CVE-2026-45524, CVE-2026-45525, CVE-2026-45527, CVE-2026-45528, CVE-2026-45529, CVE-2026-49878, CVE-2026-49880, CVE-2026-49881, CVE-2026-49885, CVE-2026-49887, CVE-2026-49895, CVE-2026-49896, CVE-2026-49912, CVE-2026-49913, CVE-2026-49914, CVE-2026-49923, CVE-2026-49924, CVE-2026-49925, CVE-2026-49931, CVE-2026-49934, CVE-2026-49935, CVE-2026-49937, CVE-2026-55257, CVE-2026-55260, CVE-2026-55261, CVE-2026-55262, CVE-2026-55263, CVE-2026-55264, CVE-2026-55266, CVE-2026-55270, CVE-2026-55271, CVE-2026-55272, CVE-2026-55274, CVE-2026-55278, CVE-2026-55279, CVE-2026-55282, CVE-2026-55284, CVE-2026-55286, CVE-2026-55287, CVE-2026-55288, CVE-2026-55289, CVE-2026-55290, CVE-2026-55292, CVE-2026-55294, CVE-2026-58815, CVE-2026-58817, CVE-2026-58821, CVE-2026-58822, CVE-2026-58834, CVE-2026-58836, CVE-2026-58837, CVE-2026-58838, CVE-2026-58841, CVE-2026-58853, CVE-2026-58854, CVE-2026-58856, CVE-2026-58857, CVE-2026-58859, CVE-2026-58866, CVE-2026-58867, CVE-2026-58868, CVE-2026-58869, CVE-2026-58870, CVE-2026-58871, CVE-2026-58872, CVE-2026-58875, CVE-2026-58877, CVE-2026-58879, CVE-2026-58883, CVE-2026-58884, CVE-2026-58885, CVE-2026-58886, CVE-2026-58933, CVE-2026-58934, CVE-2026-58935, CVE-2026-58937, CVE-2026-58938, CVE-2026-58943, CVE-2026-58944, CVE-2026-58945, CVE-2026-58946, CVE-2026-58949, CVE-2026-58951, CVE-2026-58953, CVE-2026-58954, CVE-2026-58955, CVE-2026-58956, CVE-2026-58957, CVE-2026-58958, CVE-2026-58960, CVE-2026-58961, CVE-2026-58962, CVE-2026-58963, CVE-2026-58964, CVE-2026-58965, CVE-2026-58966, CVE-2026-58968, CVE-2026-58969, CVE-2026-58970, CVE-2026-58971, CVE-2026-58972, CVE-2026-58973, CVE-2026-58974, CVE-2026-58975, CVE-2026-58976, CVE-2026-58978, CVE-2026-58979, CVE-2026-58985, CVE-2026-58986, CVE-2026-58988, CVE-2026-58990, CVE-2026-58993, CVE-2026-58994, CVE-2026-58995, CVE-2026-58997, CVE-2026-58998, CVE-2026-59000, CVE-2026-59001, CVE-2026-59002, CVE-2026-59003, CVE-2026-59004, CVE-2026-59005, CVE-2026-59006, CVE-2026-59007, CVE-2026-59008, CVE-2026-59011, CVE-2026-59013, CVE-2026-59014, CVE-2026-59015, CVE-2026-59016, CVE-2026-59017, CVE-2026-59020, CVE-2026-59021, CVE-2026-59022, CVE-2026-59023, CVE-2026-59028, CVE-2026-59032
    • Unclassified: CVE-2026-58994

  • source
  • parent
  • [–] 14 points 3 weeks ago (3 children)

    When you have a unique goal and set of constraints that are not shared by most users and are actually opposed to the interests of most users and developers it’s not a good idea to try to add them into an existing general purpose project.

    Part of the memory tagging support of graphene for example is that the applications need to actually support it too. You can force them to deal with it, but that causes instability and crashes.

    Shouldn’t all applications support memory tagging? Well that would be nice but it makes everything slower and only a few schizoid weirdos want it. Clearly the better option is to rewrite the basic system apps that everyone expects to support all the optional security features graphene requires.

    Bear in mind graphenes security competition is ios. The system applications in ios all got rewritten to support emte when apple rolled out os level support for it combined with concurrent releases of new hardware with silicon support.

    They’re playing a different game than the aosp community.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 3 weeks ago (1 child)

    They could just add optional support upstream behind a compilation flag.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 3 weeks ago

    Maybe.

    I think graphene is so far removed from aosp in terms of goals and strategy that would be a pretty big commitment of resources.

    If you haven’t ever done upstreaming in an open source project, there’s a pretty big support commitment involved if the thing your work could be part of has insider scope than your own project.

    Which is pretty much the exact situation graphene is in.

    And if the graphene people are serious about security then giving aosp their (just my own hypothetical) emte enabled apps runs a good chance of providing a false sense of security to the users of those apps when not on graphene.

    This isn’t hypothetical btw, I had to dig through datasheets to prove that the old pixels don’t have emte to some random commenter a week or so ago even though just the most cursory understanding of arm mte versions and release schedules would make that obvious.

    The point isn’t to say people are stupid or that person was stupid, but that often people will assume the best even when it opens them up to a huge blind spot. One of the best security (and safety) practices is to make your secure component incompatible with insecure ones. That way it’s impossible for someone to point to the thick low awg nema 5-20 extension cord without acknowledging the cheater plug they used to get it into a two prong outlet with no wide neutral.

  • source
  • parent
  • [–] 43 points 3 weeks ago (3 children)

    Hopefully we can get a calendar app!!

    Cheers to the GOS team, doing the lord's work truly.

  • source
  • hideshow 3 child comments
  • [–] 6 points 3 weeks ago (2 children)

    Etar isn't half bad. But yeah I wouldn't complain if they improve the landscape.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 15 points 3 weeks ago* (last edited 3 weeks ago) (5 children)

    It's a big ask, but might that include the browser?
    They could contribute dev time to the Servo browser project.

  • source
  • hideshow 5 child comments
  • [–] 13 points 3 weeks ago
    [–] 3 points 3 weeks ago (6 children)

    Excellent. Does it run on the basic Tracfone devices? otherwise, they need to get on the road to compatibility.

  • source
  • hideshow 6 child comments
  • [–] 12 points 3 weeks ago (5 children)

    GrapheneOS is very picky about what phones are supported, which is why up to now only certain pixels are supported, as well as Motorola phones in the future.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 3 weeks ago (4 children)

    I guess Motorola phone will be my next phone.

  • source
  • parent
  • hideshow 4 child comments
  • [–] -2 points 3 weeks ago (5 children)

    From recent posts on the Fediverse I'm afraid their slopping these apps ...

  • source
  • hideshow 5 child comments
  • [–] 6 points 3 weeks ago (4 children)
  • [–] 4 points 3 weeks ago (3 children)

    In the announcement threaded, they replied they us AI code analysis and code review tools to review security.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 12 points 3 weeks ago (1 child)

    I hate AI, absolutely. without question.

    however, code reviews and security reviews are in the top 5 acceptable uses for an LLM.

    why? because I can't be bothered to read the newbies 10k lines of changes for a CSS rule change.

    do I review the review? absolutely! does it make any changes to the code? absolutely NOT.

  • source
  • parent
  • hideshow 1 child comment