On 4/2/24 4:43 AM, Eddie Chapman wrote: >> Well, they change one thing. It's hard for the security professionals at >> work to deal with things when they are constantly having to respond to the >> three-ring circus. > > This is a complaint I hear very often from the people working at the heart > of things. Stop making noise, shut up, we're overworked here and dealing > with your "complaints" just adds to our stress. I do understand and > sympathise with those feelings, believe me I do, I feel them myself in > other contexts. > > But I hope you understand this is not finding things to nitpick about for > the sake of it. Does the Gentoo dev community want people on the "outside" > to raise their concerns on their mailing list if those persons feel like > said community have got something very wrong, yes or no? If not then put a > note on the mailing list page saying "please don't bother us, we're too > overworked, just post patches" or something to that effect.
I would be delighted to hear reasonable concerns. That's not what I'm referring to by "three-ring circus". >> What does one have to do with the other? Why is it necessary to claim >> that based on some sort of vibe check "there is too much compassion going >> around in our communities, and this must mean that not enough effort is >> being expended on the technical and cleanup aspects"? > > I have not made such a claim, I've said I see lots of technical and > cleanup aspects. I've only stated the things that *are* happening versus > what is not happening at all (literally zilch) and which should be > happening, which is efforts towards a solution *not* involving the xz > utilities. You say that as though a solution *not* involving the xz utilities is a reasonable takeaway from this scenario. In order to demonstrate that such efforts deserve discussion at all, let alone efforts towards solving it, you first need to prove that: - the xz utilities as shipped by Gentoo are something that should be moved away from - the xz utilities as released in 2022, when the backdoor author had just as much access as you or I -- that is, none, aside for the right to submit patches as suggestions -- are something that should be moved away from You have made no effort to justify either approach aside for claiming that for unidentified reasons you believe this scenario demonstrates that the "apparently innocent maintainer" now has an incentive to "downplay the involvement of the bad actor". If you had, I would be infinitely more interested in what you have to say on the topic. Also, if you had started with such. >> Reading in between the lines, e.g. "trying desperately to salvage the >> situation with xz-utils", I suspect you are trying to subtly suggest that >> any second of time where gentoo hasn't yet removed xz-utils from gentoo as >> a dead end is "cavalier". > > Not quite, I've never advocated removing xz-utils at all, more than happy > for it to remain for whoever wants to use it. The only reason I started > this thread is I'm very unhappy about that fact that it is currently > impossible to NOT execute xz utilities on the Gentoo systems I'm > responsible for, without heavy customisation. > > I'm also not demanding anything, let alone demanding anything instantly. > If I have please point out where. Thank you for clarifying. I am now just as convinced as I was yesterday, that you are trying to subtly suggest it, but I'm newly convinced that you're also being mendacious about it. "It is cavalier for Gentoo to allow xz-utils as a package in the @system set" is not meaningfully distinct from "it is cavalier for Gentoo to not work to allow me to depclean xz-utils". >> I understand that you are passionate about your suggestion to make >> portage not validate distfile hashes. > > That's incorrect, I've never suggested Portage should not validate > distfile hashes. The current behaviour is that validating distfile hashes > is something that can be disabled if a user wishes to, and I have no > problem with that at all, would not change a thing. I've said that, in > order to implement what I have suggested, a user would have to disable it, > which is not ideal, but acceptable if the user controls the distfile > distribution. And I only suggested that in order to try and make the idea > more acceptable by not requiring impractical infra changes that would be > needed to generate uncompressed hashes for the Manifests). In other words, you didn't care to find a robust solution, you just want something that you personally can use, and which requires being less secure than using xz-utils. But it's okay! It's not harassing portage devs with unreasonable demands! Because it's *optional*, and by default people would just... use xz-utils. Even though the ***entire premise*** of changing anything here is that xz-utils as shipped by Gentoo is somehow dangerous and users have a valid reason to want to avoid it entirely. If you're going to recommend a solution for users who consider xz-utils to be dangerous, then that solution should, you know, be better than using xz-utils. Not worse and less secure. >> But I don't understand how you think >> it's a solution to the xz-utils problem. For a wide variety of reasons, >> but the simplest one is that your proposal has zero plan of action for >> solving this at the community level and is entirely designed to allow >> "lone wolf" users to use throwaway systems performing >> security-sensitive actions (decompressing and hosting distfiles) in a >> networked environment that has the xz-utils installed, to feed into other >> security-sensitive systems (daily drivers etc.) that don't, but do have to >> trust the artifacts produced by the former. > > I'm not entirely clear what you're trying to say in this paragraph. I am sarcastically saying that your proposal makes things worse and less secure for you, and doesn't even stop you from having to use xz-utils in a context where a malicious xz-utils has the ability to inject attack code into the uncompressed source code .tar files your proposal depends on. > But > what I will say is I've tried very hard in any suggestions I've made to > only suggest things which will NOT change any default behaviour or require > big changes. The average user would not see any change from my revised > suggestions at all. I accepted after the first responses in this thread > that there was no appetite here to stop using xz utils. I then asked the > list about an idea I had just to see how palatable it might be. It was not > supposed to be a concrete plan, I was seeking discussion about how it > might be possible in practise for someone to use Gentoo without > compression and decompression of distfiles. I tried to suggest a solution > that could be an optional feature people could enable if they wanted it. But you should be proposing a change in default behavior! If it's not a change in default behavior then the change helps no one and there's no point in making it. If the change is good enough to make, it should be good enough to propose its use by default, or at least as a recommended change people should be encouraged to make while data is collected for rolling out the change as a switched default. If you want a change that only applies to your personal system, Gentoo already has a solution: make an overlay that contains slightly modified versions of every ebuild in gentoo that has a SRC_URI mentioning *.xz files. No changes to portage needed. Host your own tarballs on your own server in SRC_URI. Validate them with checksums, even. ... Or you could suggest patches to portage that improve the sandbox used to invoke decompression and archive extraction, so that it's "safe" to have xz as a statically linked executable with no accompanying library installed for the purpose of untrusted distfile extraction. >> It's not being cavalier when zero portage developers responded by saying >> "good idea I'll drop everything so I can get right on this and implement >> it". > > I'll just point out that I've never expected nor asked for anyone to > unquestionably accept anything I've said, let alone in the way you have > characterised there that I might have done. I do think that the oss/linux > community as a whole including Gentoo developers should seriously consider > changing direction on this though. And I still think it is cavalier, > simply because by deciding on the current direction that is being taken, > very big (not an exaggeration) risks on behalf of all users are being > taken, while a much safer path for everyone is available but being > completely ignored. I do acknowledge, though, as I have said before, that > this is far from easy in practise. Sorry, but no. When you say that the community's response is "cavalier" because the community is not accepting what you've said, you are inherently working off the belief that the community's failure to accept what you've said is because the community is *wrong* to question your suggestions. If you think the community is wrong to question your suggestions then you should be prepared to defend that point of view, particularly when they are busy trying to coordinate a security response together with security professionals from a wide variety of other distros, commercial vendors, OSS communities, etc. and have limited time to explain to *hundreds* of people who each have their own badly thought out ideas about what the FOSS community should do to solve the problem. Your suggestion is only one such badly thought out idea. However, it stands out from the rest because your suggestion has something that the rest by and large lack: it has an accusation that distros, in this case Gentoo, are being cavalier about security. This attitude of "Gentoo is being cavalier about security" is disproportionately worse than the average user interaction and, as has been noted, is the reason why FOSS maintainers suffer burnout. It has nothing to do with bringing up concerns. It has everything to do with "if you don't agree with me you're being cavalier about MY security as a Gentoo user". Seriously. Please learn to bring up suggestions as suggestions, not as demands. It makes all the difference in the world. -- Eli Schwartz
OpenPGP_0x84818A6819AF4A9B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
