Please don't delete bug tickets

ryrona

Please don't delete bug tickets or forum threads complaining about or reporting on issues in GrapheneOS. Please just lock them instead if you feel the user is not being constructive. It makes it very hard for us who care to look into everything for security and trust reasons to do so, and generally just gives an impression that you are hiding things, which isn't very confidence inspiring.

I wanted to look into what this root certificate issue two users have reported is, but the forum thread was deleted, and I can not find any ticket on the bug tracker about root certificates. And it is just a month ago I had another bug ticket I really wanted to look into that just resulted in a 404 when following the link, and then a statement "we deleted it to avoid confusion" or something like that.

I understand that not every open source project can be driven in the collaborative spirit open source is known for, and I understand GrapheneOS are dealing with a lot of attacks and misinformation, which can be very frustrating to deal with. But deleting bug tickets or threads that actually report on issues, whether valid or not, is not at all helpful for us who actually audit GrapheneOS for security issues, because it makes it very hard to impossible to do that. It also demotivates users from reporting oddities they have observed, which might lead to fewer potential security issues being found and investigated.

GrapheneOS

ryrona

We've repeatedly had to delete issues filed by people aiming to troll or harass the GrapheneOS team. The issue you're referring to was initially filed in good faith when someone had difficulty with a custom root CA they added not working. It was deleted when the person who originally filed it began engaging in unprovoked attacks on the GrapheneOS team. We contacted the 2nd person who posted in that issue with a potentially related problem on Matrix and asked them to make their own issue, which should happen soon. They said they'd file it over the weekend. We can always just file it for them. It's one of the first times we've deleted an issue for this reason. We've had enough of people mistreating our team members and don't plan to tolerate much of it anymore. Attacks on our team trying to get us to do something faster or prioritize something won't be rewarded. We're not interested in continuing to try to help someone resolve an issue if they start attacking us. In the future, we could stick with closing and locking the issue to keep the record of it. We'll take your feedback about that into account. It is not as if this was anything serious but rather it's about adding custom root CAs not working for 2 people for unknown reasons. We'd rather just talk to the 2nd person experiencing it on Matrix and avoid public drama if that's what is needed.

The attacks from the person in that issue thread escalated to them posting attacks on GrapheneOS across platforms including multiple Reddit posts, which were each removed by Reddit moderators without us requesting it. One of those Reddit moderators dislikes us and made a public jab towards us, reigniting past conflict. It has resulted in reconsidering the way the issue tracker works and the extent people can directly interact with it. We could have a place to submit issues and another place only team members and trusted contributors can post what we consider the planned features and valid issue reports for both upstream bugs (some impacting the stock OS + AOSP and others only AOSP) and GrapheneOS-specific issues.

Redundant issues closed as duplicates are deleted over time to make searching the issue tracker easier. Comments in the wrong threads posting a traceback already covered in another thread are often deleted after directing people to the correct issue because then the wrong thread shows up searching for a traceback even if it's marked as hidden. Not doing this cleanup leads to people going to the wrong place and a gradual degradation in us being able to manage it and get useful info from it. It's quite a mess. What tends to happen is people file an issue about a crash and then we get unrelated crash reports there we need to send to the right place or file new issues about because people are trying to be helpful posting in an existing issue but didn't use the right one. Not cleaning it up makes it get much worse.

And it is just a month ago I had another bug ticket I really wanted to look into that just resulted in a 404 when following the link, and then a statement "we deleted it to avoid confusion" or something like that.

You appear to be referring to the Vanadium issue we filed about what we believed might be an upstream Chromium issue in how it handles WebRTC privacy by generating a random salt. This was speculation from us about what may be an issue and we didn't understand it to the extent we do now. We also speculated about removing the salt and leaking hardware information being better but decided that was a bad idea and didn't make sense. This issue was misrepresented as somehow a Vanadium specific issue in someone's proposal for a research project which was published. It was closed a long time ago because we determined the approach of removing the salt wasn't a good idea and we decided it wasn't a serious privacy issue. We still kept it in mind and planned to revisit it at some point when higher priority fingerprinting surface has been handled.

We don't particularly need to have our speculation about what may be a privacy issue and flawed ideas on how we could mitigate it as a public issue in the Vanadium tracker. It was closed a long time ago and we didn't plan to take any action based on it. That's why this was removed. It stops more people misinterpreting it. Perhaps we should have edited and expanded it to explain the context and how it was being misrepresented so people following the link from that paper attacking Vanadium could have the misinformation from there debunked. We didn't consider that until after already deleting it and we can't change that now. GitHub unfortunately doesn't have any non-permanent deletion so deciding to get rid of an issue or comment or permanent.

other8026

This post seems to be referring to a post that was hidden here on the forum recently where the poster was voicing a complaint about an interaction they had on the OS issue tracker. The post was hidden by a member of the moderation team so we can first look into it since we don't yet have all the details and then try to sort everything out in private.

Everyone on the GrapheneOS team takes security reports seriously. None of us will try to hide or shy away from valid reports. There can be various valid reasons to remove issues on the issue tracker or posts on the forum for moderation or similar reasons. If we're dealing with people who are angry or others who are misinformed, sometimes it's best to deal with issues in less public ways. The issue tracker is used for a different purpose, so we may treat issues on the issue tracker differently than we do in other places.

Having said that, it does make sense that for those who aren't aware of the reasoning behind things being removed, it may appear that we're trying to "hide" something, even if we're not. Regardless, we'll take your suggestion into consideration and hopefully things can be improved in away that works for everyone.

ryrona

other8026 But you removed the bug ticket from the issue tracker too? Despite there being two users reporting on the same issue? I am just curious about what the issue or observed behavior was, since it involved root certificates.

GrapheneOS

ryrona A user was unable to get the OS to trust the root certificate they added. We were unable to replicate an issue and it appeared likely that they were running into standard Android restrictions. Another user had a similar problem and checked on the stock OS with the same device where they confirmed it worked. We reopened the issue, followed by the person who filed it attacking us so we decided to address it with the 2nd person who experienced it elsewhere and deleted the issue of the person being nasty.

ryrona

GrapheneOS In the future, we could stick with closing and locking the issue to keep the record of it. We'll take your feedback about that into account.

Thank you.

GrapheneOS It is not as if this was anything serious but rather it's about adding custom root CAs not working for 2 people for unknown reasons.

Yeah, in that case it is not anything I would care to look into. But I couldn't tell because all that was said in the deleted forum thread was that it was about an issue with a root certificate. That is why I wanted to look into the bug ticket, so I could tell whether it was something with potential security implications or not. (Still it is good if people can install their own root CAs so they can do MITM attacks to audit actual communication for security issues.)

GrapheneOS Not doing this cleanup leads to people going to the wrong place and a gradual degradation in us being able to manage it and get useful info from it. It's quite a mess.

I understand, but deleting things also remove traceability and break links and so. I know some projects only allow vetted members to add things to their bug tracker, and then they have an e-mail or some other means where others can make bug reports, sometimes even anonymously, and things reported there are added to the bug tracker if the person managing the e-mail address judge this is an actual issue that needs to be looked into by developers. Could maybe be something to consider to keep it all tidy, and never feel the need to delete anything.

GrapheneOS You appear to be referring to the Vanadium issue we filed about what we believed might be an upstream Chromium issue in how it handles WebRTC privacy by generating a random salt.

Yeah, this sounds very familiar, that was probably it.

GrapheneOS Perhaps we should have edited and expanded it to explain the context and how it was being misrepresented so people following the link from that paper attacking Vanadium could have the misinformation from there debunked. We didn't consider that until after already deleting it and we can't change that now.

Yeah, that would have been way better. Because when I and others who are interested could still read about it. You could just have edited the original post and added some bold text why the issue and comments posted there isn't to be considered, just a sentence or two, while keeping the original text intact.

tw-hx

GrapheneOS

Thanks @ryrona for sharing your thoughts on this issue and @GrapheneOS on your considered response above. I briefly saw commentary on these forums from @kfish682 about a root certificate issue, it appears their thread and user account here have since both been deleted.

I would also like to advocate for a "Never delete security issues" policy for GrapheneOS. It's entirely fair to mark a bug as INVALID or DUPLICATE and close the issue if it's considered an upstream issue, already reported, or similar of course; no-one wants a bugtracker clogged with irrelevant open issues.

I have been reflecting on my recent report of a regression in the 20241117+20241118 builds where Bluetooth contacts were shared with devices without user permission. Although upstream AOSP is far from perfect in this regard, those builds introduced GrapheneOS's first attempt to improve upstream's behaviour but it accidentally made the problem worse.

I spent several hours digging through the GOS source to find how the regression occurred, and slowly typing a Github issue on my phone (as I was travelling with a rental car -- connecting my phone to it brought my attention to the issue), so perhaps the wording wasn't perfect and I did struggle with tabbing between all the relevant pages. I think initially it was perceived as purely an upstream problem and I received a rapid series of emails in response noting that it was therefore misinformation and the bug report was marked as invalid, closed and then deleted entirely.

Luckily we managed to work through the issue on these forums as linked above, and as the full nature of the regression was understood it was patched. As things calmed down the developers noted it was "Probably the worst regression we've caused" (which is fine -- mistakes happen to everyone). Ultimately the fix had a good outcome for the project and subsequent builds have been more secure for everyone.

However I worry what happens if a competent security researcher finds a zero-day in GrapheneOS, files an issue, and it gets deleted based on a misinterpretation, perception that they are ill-mannered or similar. Potentially if they get offended, they could sell it on the vulnerability black market, and decline to report any further issues they discover, which would be a bad outcome for all. Better to leave issues open for preservation and attribution to the original reporter(s), and work collectively to clarify the security impact (if any) of the report.

DeletedUser69

It is not really my place to say this but this is a fantastic example how valuable R/D and own personal time gets spent trying to defend someone's beliefs, views and decisions and I know it means nothing but you have my respect.