1. 7

    Millions of US Government employees succeed at encrypted email every day.

    1. 6

      … as long as they are only emailing each other. True, but completely beside the point.

      1. 1

        Is it true? Is one in 300 or so Americans working for the government? In a capacity with mandatory encrypted email? Could be, but I gotta ask.

        1. 2

          Definitely not 1 in 300. Most intra-gov emails are definitely unencrypted. I had interpreted the comment as “some government employees…”

          1. 1

            There are close to 3 million civilian federal employees. I have no idea how well they deal with PGP though.

            1. 7

              Not at all. The majority of federal agencies use Exchange, and ~all federal agencies use ID cards with X.509 certs, so many use S/MIME for signed/encrypted emails.

              There’s a few important caveats:

              a) It’s actually relatively rare for people to use this; it’s not on by default. People really only use encryption for sending PII. I’m not sure I ever saw anyone (besides myself) use signing besides that. (Not true, now that I think about, at DoD signing was pretty common. Nowhere else though.)

              b) There’s 0 support for cross-agency encrypted emails. Key management is handled through Exchange’s GAL, so there’s no way for someone at the State Department to send someone at the VA an encrypted email on the unclassified networks, period. Cross agency signature verification sometimes works, depending on the vagueries of path building.

          2. 1

            ZixCorp lets you email others outside the system. They get a link to a secure portal, authenticate with out-of-band credentials, and then get the message. Maybe combine that with Keybase for OOB stuff.

          3. 5

            Joe Q. Average’s kid sister does not work for the US government, mind you.

            1. 3

              We had encrypted e-mail when I was a staff worker at a University. It involved getting a Comodo client side SSL cert and loading it in to the Active Directory GAL. My director accidentally revoked his cold cert by requesting a new one. Someone at a conference the next week talked about getting multiple client SSL certs and I said, “You can’t. It revkos your old ones and you can no longer decrypt your old mail.” Other people chimed in experiencing the same thing and we discovered it was a bug together.

              Other than at that University and one small open source shop that e-mailed us password with PGP encrypted emails, I’ve only used encrypted e-mails with one other person.

              1. 1

                The trick is using mail guards/gateways and putting crypto in usable proxy in front of legacy clients with similar workflow. Then, IT/ITSEC depts manage it for them. Proven model that isnt followed by FOSS alternatives.

              1. 3

                The ease with which Active Record allows SQL injecting yourself is pretty stunning to me. https://rails-sqli.org/ highlights the various methods that take arguments that look like they’re safe, but can actually be arbitrary SQL.

                Granted I have a bias (I’m an emeritus Django core developer), but to me there’s a sharp contrast with the Django ORM, which doesn’t take strings-that-can-be-SQL anywhere in the ORM API, except methods that take exclusively SQL, like raw() or extra(). In my experience this is a much more fool-proof API, I’ve reviewed a lot of Django applications, and I can count the number of SQL injection vulnerabilities on one hand.

                1. 2

                  Although I mostly like it, I though it was funny when they replaced Agile buzzword with a slogan about DevSecOps or something. From one hype train to another?

                  1. 1

                    If the only people who are on the hype train are early adopters who know what they’re doing, then it can almost work as a strategy.

                    1. 1

                      That’s true for a lot of things. I dont think we should call it a hype train in those cases, though. More like an early adopter advantage.

                  1. 5

                    The last paragraph feels like a real non-sequitur to me:

                    That is the first localhost root hole in quite a long time.

                    This vulnerability existed for however long it’d been since it was introduced, regardless of when OpenBSD found out or shipped a fix. If the complaint is that they didn’t find out soon enough, it’s important to acknowledge that finding out sooner would not have changed the fact of the vulnerability existing.

                    1. 14

                      I am coming out of Lobsters retirement to say this…

                      “Only two remote holes in the default install, in a heck of a long time!” is the tagline front and center of the OpenBSD website. This new line is too similar to not be an attempt at a “cute” homage and nothing more.

                      it’s important to acknowledge that finding out sooner would not have changed the fact of the vulnerability existing.

                      I think it’s less important to point out obvious facts, than it is to highlight that the existence of this vulnerability may have led to undetected, and still active exploits of it. In other words, the severity of a root hole should not be understated.

                      1. 9

                        I am coming out of Lobsters retirement to say this…

                        I was wondering where you went. Missed your comments. Feel free rejoin any time and otherwise enjoy your retirement. :)

                      2. 5

                        I think it is a reference to OpenBSD’s slogan “Only two remote holes in the default install, in a heck of a long time!”, probably it shouldn’t be taken at face value.

                        1. 1

                          I’m confused too. Wouldn’t it have affected 6.3?

                          1. 2

                            It does.

                        1. 4

                          Peter Theil has a philosophy degree from Stanford. Brett Kavanaugh has a cum laude history degree from Yale.

                          1. 13

                            This is an incredibly lazy form of argument. You can’t disprove an observation about a trend with a counter-example. Counter-examples disprove universal quantification, not statistical deltas.

                            I see this pattern a lot, and we shouldn’t treat it as if it’s a compelling refutation.

                            1. 1

                              by golly! all them big words and everything. So, if you need it spelled out: neither the original post nor my response had anything to do with either universal quantification or statistical deltas, whatever they may be in this context. The original argument, which I see too often, is based on the theory that there is some magical ingredient in humanities that is necessarily missing in a STEM education. As far as I can see, however, it is as easy to absorb an arrogant and dismissive attitude and a tendency to use fancy nomenclature in lieu of thinking and open discussion from humanities courses as from science classes. And I think the underlying problem could and should also be addressed within science/engineering education which is taught in a narrow way. You should learn critical thinking and how to collaborate in engineering school, just as you should in a philosophy department, but it’s not only possible, but the standard, not to learn those in either program. As an example: I really like what Olin college is trying to do http://www.olin.edu/discover-olin

                              1. 1

                                Don’t get caught up in the labels. I didn’t read the article as you need a liberal arts degree to address the problems identified. I read it as simply suggesting putting more emphasis on humanities. To quote the person of focus in the article, “Students of computer science go on to be the next leaders and creators in the world, and must understand how code intersects with human behaviour, privacy, safety, vulnerability, equality, and many other factors.”

                                1. 3

                                  I agree with that and think it’s important, but I don’t believe that adding a generic humanities course or two,or 100, can do it or is necessarily even the right approach. To teach people to be responsible citizens is a complex project. I plead guilty to assuming too much about what Baker meant. I have seen an argument that the humanities program is key to deeper understanding a lot and I think that’s a superficial and maybe reductionist approach.

                            2. 3

                              I don’t think Brett Kavanaugh is in the audience being targetted by the message in the article.

                              1. 14

                                The point is that humanities graduates don’t magically fix the issues of misinformation - they can be just as flawed and politically biased as anyone else.

                                Really we need to optimise for hiring those with “moral backbone”, make them feel able to say “no”, and then listen to employees when they do. I feel part of this can be fixed by regulating and licensing employees similarly to how line engineers need to be licensed. When your personal license to work is on the line, you have a strong incentive to be rigorous in your work and to say no when your employer asks you to work inappropriately. When engineers say no, these decisions are often respected and engineers have a strong network of support where they will often be backed up in their decisions if they are made for the right reasons, even when that runs counter to the business arms aims.

                                1. 0

                                  Those two were intended as counter-examples.

                                  1. 4

                                    The examples were also unnecessarily political, especially for lobste.rs. It distracts from whatever point you are trying to make.

                                    1. 0

                                      How does it distract from the point?

                                      1. 3

                                        By using polarizing figures, you run the risk of the debate steering away from the actual point either parties were trying to make, and right into the realm of partisanship. It becomes hard, then, to exit the “no u” dead end that the discussion becomes. It’s usually frustrating for all parties involved, except maybe the trolls.

                              1. 3

                                There seems to be a weird implicit premise of an obligation to publicly disclose every vulnerability, even if it wasn’t exploited.

                                That’s emphatically not the world we’re in, Google, Facebook, Twitter, your bank, etc. all fix hundreds of vulnerabilities a year, without telling the public about a “potential breach”. While it’d be nice to know about them, it’d also be dangerous, absent some additional policy change, it’d provide a strong incentive to not look for bugs.

                                1. 5

                                  even if it wasn’t exploited.

                                  We have no reason to believe it wasn’t exploited. “However, Google says that it has no evidence to suggest any third-party developers were aware of the bug or abused it” (from the unpaywalled Verge article) is not the same as ‘Google says that it has evidence it wasn’t abused’. Firstly, why on earth would we believe Google when they say this? Secondly, is there any reason to suggest that any exploit would leave evidence? Google doesn’t have evidence it was exploited, okay, so what? It probably still was. Until they produce firm evidence it wasn’t exploited they have an obligation to tell us.

                                  Anyway this wasn’t a vulnerability. Having vulnerable software installed then fixing it is not the same as exposing data publicly that should be private.

                                  1. 2

                                    If you find and fix a vulnerability, it’s rare that you can say for certain that it wasn’t exploited. If there is even the slightest chance that it may have been exploited, then it is dangerous not to let people know that you had a vulnerability, as it prevents them taking steps to minimise the damage. As an example, if I know that a third party may have had an opportunity to obtain my payment card details, I can cancel the card even if the potential attacker doesn’t appear to have used it yet.

                                  1. 69

                                    I’m kind of speechless. This looks truly genuine, and it makes me hopeful for the Linux kernel community (and all the other open-source communities it influences!) in a way I hadn’t predicted would ever happen.

                                    1. 9

                                      I feel quite the opposite. I think it’s very sad that the reddit/twitter bandwagon of people that never actually contribute anything to open source but love to rip those that do to shreds have finally go to him.

                                      1. 50

                                        This argument is a classic to be found in all of those discussions, but doesn’t hold any water.

                                        • Coraline Ada, the woman who’s work the now adopted Code of Conduct is based on, is the primary author of 25 Ruby gems, regular contributor, very welcome as a speaker in the Ruby world.
                                        • Sage Sharp, known for their angry good-bye from the Linux kernel and outspoken critic of Linus, has been author and maintainer of the USB-3.0 implementation in the kernel. Sage also lead intern groups working on the Kernel through Outreachy.
                                        • Matthew Garret, also a very outspoken critic, has been maintaining kernel power management modules and is constantly working on Linux related issues ever since.

                                        The no-contribution Twitter crowd, right?

                                        The list could go on and on. Find another angle, this one insults the intelligence of everyone at the discussion table. It only works if you don’t name names, if you do, you suddenly find that these people do contribute.

                                        Finally, as someone managing a huge FOSS project with > 100 maintainers, I think this gatekeeping isn’t part of open standards. If your project is open and contribution is free to everyone, the barrier for criticising your projects methods and practices should be as low as the barrier for contributing anything else: as close to zero as possible. This is also important for practices to travel between projects.

                                        1. 7

                                          And very recently, Alexander Popov, no lightweight by any measure. https://lwn.net/SubscriberLink/764325/09702eb949176f55/.

                                          1. 1

                                            I’m sympathetic to Torvalds critique, if not his wording. It seems bizarre to just live with kernel code that uses uninitialized data structures and doesn’t cross check pointers and hope that some complex mechanism will ameliorate the problem.

                                            1. 6

                                              Sure, his technical arguments were probably sound, as usual, but his abuse of Popov left the latter “emotionally dead for weeks”. Popov might’ve gotten the fixes made and thus the patch committed much sooner had Linus not abused him so the project also loses.

                                              1. 3

                                                I am not convinced the patch ever became worthwhile - but I agree that Linus’s argument style was counterproductive and abusive.

                                        2. 23

                                          I think you’ve got a selection bias in which criticism you’re seeing. From my perspective, the people who I hear take the most issue with Linus’s conduct are largely people who’ve quit kernel development as a result of it, or people with many years of OSS experience (such as myself).

                                          1. 5

                                            I’m not an advocate of the absurdly excessive personal attacks for which Linus is known but at the same time I think quitting kernel development because of those personal attacks shows a lack of awareness of how OSS and specifically Linux operates. The reality is that Linux is Linus’s project and he’s incentivized to take your patches to make his project better, not to build a cooperative community. The community, if one could call it that, is incidental to Linus’s incentives.

                                            If a person quits because of Linus’s behavior, it signals to me that their motivation had something to do with the approval of others and unfortunately those motivations are incompatible with Linux’s development process. Linus’s insults are just the tip of the iceberg when it comes to all the other problems that will arise due to the mismatched expectations. A famous example was when Ingo Molnar rewrote Con Konlivas’s CFS, or the multiple times grsecurity’s patches were rewritten by others.

                                            Linus basically doesn’t owe anyone anything, and it’s not because he’s a jerk (though maybe he is), it’s because of the emergent social phenomena around OSS. Similarly, no one owes Linus anything. Many actors out there are using Linux to facilitate their billions of revenue and not paying Linus anything. If you write code and put it out there, there is no obligation that what you want to happen with it will happen, and it’s not unlikely that what happens with it will hurt your ego. If someone quits kernel development because of Linus’s behavior, they really should reexamine why they want to write OSS code in the first place and whether or not OSS development is the best way to reach their goals.

                                            All that said I don’t necessarily disagree with Linus’s recent decision. It shows a conscious effort on his part to change the strategy used to sustain the project. I’m only criticizing those who may have mismatched expectations of the potential outcomes in OSS work.

                                            1. 3

                                              The reality is that Linux is Linus’s project and he’s incentivized to take your patches to make his project better, not to build a cooperative community.

                                              Linus is an employee of the Linux Foundations, a nonprofit corporation with stakeholders like Red Hat, Google, and Intel, and he owes his employers their money’s worth as much as anybody else who works for hire.

                                              I would agree with you if this was still the Linux that wasn’t going to become a big thing like Hurd. But Linus chose to remain the project lead even as the job became less technical and more political, and when they decided to pay him to work on it full-time, he accepted. There’s money, there’s a trademark, and there’s inertia undermining any claim that the situation is totally voluntary and that nobody owes anybody anything.

                                              And that’s before we even consider the fact that there is a huge and informal web of soft obligations because human beings don’t work the way you say they do.

                                              1. 1

                                                Linus owns the trademark and even if he didn’t work for the Linux Foundation he would still be the maintainer of Linux. The entire development structure is centered on him. No company could successfully and sustainably fork Linux if Linus decided to operate against their goals.

                                                I made no claim as to how human beings work. My claim is simply that OSS is essentially a free-for-all and those that aren’t acutely aware of that and incorrectly treat OSS like a traditional organization that has inbuilt obligations to their well-being will be inevitably burned. Linux is not a cathedral, it’s a bazaar. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

                                          2. 6

                                            Are you talking about the crowd that is currently lambasting him for “yielding to the SJWs”?

                                            1. 9

                                              No I’m talking about the much larger crowd of people applauding him for ‘moderating himself’ and other such nonsense. I’m talking about the huge crowd of people that act like every message he sends is a scathing personal attack on someone for indenting something incorrectly.

                                              1. 11

                                                Well, perhaps it’s just that our perception of the (ultimately utterly pointless) social media reactions is colored by our preconceptions. I’ve mostly seen people praise and defend him.

                                                I’m not sure what the resistance is about. It seems to me that all these CoCs are just a way of codifying “don’t be an asshole”, and it’s perplexing that people get so angry about it. But it cannot be that, right? Surely you and others are not against “don’t be an asshole” as a work ethic?

                                                If not that, then what? I’ve listened to Sam Harris quite a lot recently, so I have some feeling about the problem of identity politics et al, especially in the US. I’m just still not exactly convinced, because I don’t see it happening. Perhaps it’s not that big a problem in Europe?

                                                1. 10

                                                  I’m not sure what the resistance is about. It seems to me that all these CoCs are just a way of codifying “don’t be an asshole”, and it’s perplexing that people get so angry about it. But it cannot be that, right? Surely you and others are not against “don’t be an asshole” as a work ethic?

                                                  I think a lot of this is related to the “hacker identity” which is strongly tied up with counterculture, stepping outside/dismissing/rebelling against social conventions. For example, in the genre of cyberpunk (which I’d consider a hacker’s dream world, even if it’s a dystopia) there is almost no law and order or even anarchy, everyone does their own thing and your skill is the only thing that counts.

                                                  So I think a lot of the reaction is “who are you to come in and police the way we’ve always been doing things?”. I suppose a lot of these people claiming are seen as outside intruders enforcing their “outside” morals on the hacker “community” at alrge (if there is even such a thing). For this reason I think it’s important that people like Linus, who are truly regarded as being “from” the community, are signaling that change needs to come. We’re all human, not machines.

                                                  1. 8

                                                    I think there are two big issues. One is that “hacker culture” has historically attracted people with social issues. I know that it appealed to me as an unpopular, nerdy, shy kid: I didn’t have a lot of outlets, so computers and the Internet helped me form my personality. That’s great; I don’t know where I’d be without it. That leads into the second issue, though, which is that it’s utterly dismissive of all the traditions we call the “humanities.” I am lucky, I think, in that I’ve always been “into” literature, philosophy, theology, and so on, and could balance my computer-nerddom with those fields. (In fact, my only college degree is a BA in English.) Without that tempering influence, it’s very easy to get caught up in an aspiration-to-Spock sort of behavioral cycle.

                                                  2. 5

                                                    Surely you and others are not against “don’t be an asshole” as a work ethic?

                                                    Who defines what an ‘asshole’ is?

                                                    My problem is that Codes of Conduct explicitly and implicitly privelege some groups but not others for protection, and that even when de jure they protect some groups, de facto they do not.

                                                    Moreover, I find the idea that we should generally value social etiquette more than technical excellence to be troublesome. Are there people who are so socially rude that they should be shunned? Sure. But should shunning be our go-to? I don’t think so.

                                                    1. 5

                                                      I find the idea that we should generally value social etiquette more than technical excellence to be troublesome.

                                                      Is that what’s actually happening? I thought this was about valuing both.

                                                    2. 2

                                                      It seems to me that all these CoCs are just a way of codifying “don’t be an asshole”, and it’s perplexing that people get so angry about it.

                                                      I can’t speak for all opponents, but for me at least I disagree with it being “codified”, or rather formalized what essentially isn’t formal. People contributing to software won’t just suddenly become good people because there is a CoC. It’s like wanting to prevent a husband from abusing his wife by requiring him to hold up his hands whenever they are in the same room.

                                                      What I usually fear from these kinds of things is that they one the one hand subvert genuine communities, customs and practices, while possibly encouraging the harmful parts of these communities to discreetly and dishonestly live on, much harder to fight or criticize. Essentially it’s taking a passive stance towards real issues people should actively and collectively oppose – say harassment or insulting people.

                                                      Turning issues of civility and decency into rules, especially if these are too vague, always bears the danger of being on the one hand abused by those trying to evade then (“oh, that’s not what I meant”) and on the other hand by those enforcing them (“rules are rules”)…

                                                      But then again, I’m not a Linux contributer (although I would be honored to managed to get there one day), and I can just hope it turns out well for them, and the issue doesn’t get instrumentalised.

                                                      1. 4

                                                        People contributing to software won’t just suddenly become good people because there is a CoC. It’s like wanting to prevent a husband from abusing his wife by requiring him to hold up his hands whenever they are in the same room.

                                                        I find that analogy deeply flawed (and somewhat bizarre). The CoC doesn’t require anyone to do anything as ridiculous as hold their hands in the air while in the same room as their wife.

                                                        Essentially it’s taking a passive stance towards real issues people should actively and collectively oppose – say harassment or insulting people.

                                                        So you’re saying that rather than having a CoC it would be better if, every time Linus or some other kernel developer was offensive, other developers stepped in and told them off? How do you make that happen? Do you not think the CoC is a step towards making that happen?

                                                        1. 1

                                                          The CoC doesn’t require anyone to do anything as ridiculous as hold their hands in the air while in the same room as their wife

                                                          Of course not literally, but for many people they have to adjust their own behavior in unusual (and often enough unknown) ways. I’ve experienced communities on the Internet which banned their users for using any phrase that has to do with eyesight disabilities (e.g “I can’t see what’s wrong”), and most people simply just didn’t know about this.

                                                          And the point of my analogy still remains, the issue with the husband beating his wife isn’t that he can but that he wants to, consciously or unconsciously. Just saying “Don’t” won’t help solve the problems in the long term, just suppresses them.

                                                          So you’re saying that rather than having a CoC it would be better if, every time Linus or some other kernel developer was offensive, other developers stepped in and told them off?

                                                          The way I see it, this would obviously be better. This means that the community has a strong sense of internal solidarity and openness that they manage to enforce by their own means. Essentially this means that the goals of the CoC come naturally and authentically to the members.

                                                          How do you make that happen? Do you not think the CoC is a step towards making that happen?

                                                          I really can’t say, nor do I know. Nothing I’m saying is authoritative or really substantial, I’m just trying to give a more reasonable criticism of codes of conducts than certain other people in this thread.

                                                          1. 7

                                                            Just saying “Don’t” won’t help solve the problems in the long term, just suppresses them.

                                                            Suppressing the problem does help, though. I don’t want to continue the husband/wife analogy as I find it distasteful, but once you establish norms of good (or at least better) behaviour, people do adjust. And by having the CoC, even though it doesn’t cover every case, it sets up some basic guidelines about what will and won’t be accepted - so you remove the excuse of “no this is fine, everyone talks this way, deal with it” from the outset. This alone can make people who otherwise feel vulnerable, and/or belong to marginalised groups etc, to feel more comfortable.

                                                            I’d prefer we didn’t need CoCs, but clearly we need something to make development groups less unpleasant to participate in. And even if you don’t think they’re effective, I can’t see how they hurt.

                                                            1. 1

                                                              I guess we just have different views on the question if issues are to be addressed or suppressed (in my eyes willfully ignored). But that’s fine. There’s more I could say, but I won’t for the sake of brevity, except that a CoC should (imo) be always the last resort when everything else has failed. A kind of martial law. Since they aren’t just guidelines or tips, but can justify very drastic behavior.

                                                              1. 2

                                                                I guess we just have different views on the question if issues are to be addressed or suppressed

                                                                I think that’s a mis-characterization. We both seem to think that offensive behaviour should be addressed by other people stepping in as appropriate, but I see the CoC as prompting this to happen, whereas you are saying that you don’t know how to make it happen and that the existence of a CoC will make people suppress their bad behaviour and that this is bad (for some reason which I’m not clear on).

                                                                I would say that the existence of a CoC may make people suppress an urge to spout off an offensive rant against another developer, and that’s a good thing. I also think that it lends a stronger position to anyone who does step in when offensive behaviour does occur (despite the existence of the CoC). I think it’s more likely that, rather than completely suppressing offensive behaviour, the CoC causes more people to respond and challenge such behaviour, which is the outcome that we both seem to think is ideal (and which leads to less of the behaviour occurring in future). Now if you disagree that the CoC will lead to that happening, that’s fine, but:

                                                                A kind of martial law. Since they aren’t just guidelines or tips, but can justify very drastic behavior.

                                                                That’s just ridiculous. A CoC is nothing like martial law. The only behaviour it justifies is that of stepping in to control other, offensive, behaviour:

                                                                … to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

                                                                Maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

                                                                These are the only behaviours that are actually “justified”, to use your word, rather than expressly prohibited, by the CoC. I think saying these are “drastic” and comparing to martial law is clearly an immense level of exaggeration.

                                                                1. 1

                                                                  but I see the CoC as prompting this to happen, whereas you are saying that you don’t know how to make it happen and that the existence of a CoC will make people suppress their bad behaviour and that this is bad (for some reason which I’m not clear on).

                                                                  I don’t want this to go on for too long, so I’ll just quickly clarify my two main points:

                                                                  • banning obvious misbehavior won’t change people, it will at best make them be quiet, at worst invite them to a passive aggressive game of trying to evade the rules while still trying to be mean or hurtful.
                                                                  • a CoC is a principally passive stance, where active action is necessary trying to address and resolve issues. Suppressing discussion where necessary may (again) lead to a overall harmful atmosphere, especially towards those not used to these, usually American, norms (because of different backgrounds, cultures, standards).

                                                                  So it’s not that it’s irrelevant, but that it may go wrong, specifically when applied to quickly or without introduction. But again, maybe not.

                                                                  A CoC is nothing like martial law.

                                                                  You’re right, I should have put “martial law” in quotes. My point is that it shouldn’t be a permanent solution, but as you said try to push a community in a better direction, “stabilize” a situation so to speak. Even here between us we see how different background, invoke different images and connotations with examples as simple as metaphors.

                                                                  1. 1

                                                                    You’re right, I should have put “martial law” in quotes. My point is that it shouldn’t be a permanent solution

                                                                    Ok, I understand now what you meant.

                                                                    banning obvious misbehavior won’t change people

                                                                    I am not sure that I agree with this. For one thing, “obvious misbehaviour” may be generally understood but is not obvious to everyone. You will see many people arguing that Linus’ rants are perfectly acceptable, for various reasons. By making a clear statement that “behaviour X is wrong” you are removing the doubt.

                                                                    at worst invite them to a passive aggressive game of trying to evade the rules while still trying to be mean or hurtful

                                                                    I believe that the Contributors’ Covenant deliberately avoids trying to produce an exhaustive list of disallowed behaviour, precisely so that the rules can’t be avoided in this way. Yes, there will always be some problematic individuals who push the limits regardless. But is it better that they are at least constrained in this way, rather than being able to be openly offensive? I think so. And I think this anyway is somewhat irrelevant to the issue of a CoC; even if you generally enforce good behaviour without a CoC, there can always be trouble-makers who test the limits.

                                                                    a CoC is a principally passive stance, where active action is necessary trying to address and resolve issues. Suppressing discussion where necessary may (again) lead to a overall harmful atmosphere

                                                                    A CoC is just a document, so it is passive in that sense, yes. But it doesn’t prevent any affirmative action - it encourages it.

                                                                    What this seems to boil down to, if I’m reading you correctly, is that you’re saying that it’s better to allow offensive behaviour to occur - and then to have the perpetrator reprimanded - than it is to document what is considered offensive behaviour so that it will be deliberately avoided. I cannot see how that is better. If someone’s response to a rule is to try to find underhanded ways to work around that rule, what difference does it make whether the rule is written down or enforced only by-the-way?

                                                                    1. 1

                                                                      For one thing, “obvious misbehaviour” may be generally understood but is not obvious to everyone. You will see many people arguing that Linus’ rants are perfectly acceptable, for various reasons.

                                                                      Ok, but these people would say these rants are good because they are brutal or some kind of “not nice”. Nobody, or at least nobody I’ve seen, claims that Linus is always “kind” and “civil” and people are just misunderstanding him.

                                                                      Yes, there will always be some problematic individuals who push the limits regardless. But is it better that they are at least constrained in this way, rather than being able to be openly offensive? I think so. And I think this anyway is somewhat irrelevant to the issue of a CoC; even if you generally enforce good behaviour without a CoC, there can always be trouble-makers who test the limits.

                                                                      I get your point. I still belive there to be a difference between the two cases – maybe not immediately visible, but on a more symbolic level. In the first case the trouble-maker stands in conflict with the (official, formal) document and will try to defend his or her behavior on semantic issues and misreadings, while in the second case the conflict is more direct with the “community”. This is not to say that no rules should be made or no behavior should be sanctioned – just that in the long term this should be a internal and organic (eg. self-made (maybe even unofficial) “community guidelines”, that serve to introduce new members) process not ordained from above.

                                                                      you’re saying that it’s better to allow offensive behaviour to occur - and then to have the perpetrator reprimanded - than it is to document what is considered offensive behaviour so that it will be deliberately avoided

                                                                      I wouln’t phrase it that way, since to me many of these terms are too vague. Anyways, in my eyes this seems to be unrelated to CoC: from my experience most people encounter a CoC not by reading it before they do anything, but by people using it as “legislation” – they make a mistake and are then banned and excluded – often enough permanently because it’s just the easiest thing for moderators to do. Either way, the “offensive act” has taken place – with a quick and formal process leading to confusion on the one side and a honest attempt to point out what a person has done (on a case-to-case basis) in the other.

                                                                      1. 1

                                                                        For one thing, “obvious misbehaviour” may be generally understood but is not obvious to everyone. You will see many people arguing that Linus’ rants are perfectly acceptable, for various reasons.

                                                                        Ok, but these people would say these rants are good because they are brutal or some kind of “not nice”. Nobody, or at least nobody I’ve seen, claims that Linus is always “kind” and “civil” and people are just misunderstanding him.

                                                                        That’s my point. The CoC makes it clear that we are expected to be civil. Therefore if anyone goes on an uncivil rant, you can’t claim that it’s ok because [whatever reason], as it’s been explicitly stated that it’s not acceptable. You’re making the community rules about what certain unacceptable behaviour explicit, and removing the inevitable and fruitless debates over whether it’s ok to swear at someone for submitting a bad patch etc.

                                                                        Whereas now, people don’t understand that it’s not ok to be uncivil.

                                                                        Either way, the “offensive act” has taken place – with a quick and formal process leading to confusion on the one side and a honest attempt to point out what a person has done (on a case-to-case basis) in the other.

                                                                        Other than anecdotal examples where it may have been the case with some unknown number of other projects (links to relevant mailing list posts would be interesting to see), I don’t see any evidence that a CoC will necessarily lead to confusion nor to people being wantonly banned from participating for one-off infractions; I certainly don’t think it’s designed or intended for that.

                                                            2. 2

                                                              I’ve experienced communities on the Internet which banned their users for using any phrase that has to do with eyesight disabilities (e.g “I can’t see what’s wrong”), and most people simply just didn’t know about this.

                                                              As a visually impaired person with several friends who are totally blind, this strikes me as ridiculous. I have no problem with such everyday use of “see” and related words. I think my blind friends would agree.

                                                      2. 9

                                                        What’s so bad about people in positions of power to stop being abusive? Isn’t it something to applaud?

                                                    3. 2

                                                      It’s possible the CoC, the heart-warming public statement and Linus taking a time-out is a double-blind.

                                                      Well he could actually be a little burnt out as well, which is also totally fine.

                                                      I totally support him which ever way the pendulum falls.

                                                  1. 6

                                                    Author here.

                                                    I wanted to make this for a few reasons:

                                                    • I noticed no one had implemented 9p in rust yet and rust is cool (although another person started working on it while I was)
                                                    • I wanted to give everyone a standard base to build upon if they were to make differing server implementations, so there could at least be some shared code.

                                                    I’ve still got some cleanup to do on this crate, and I have a fairly simple in-memory filesystem server that I’ve been using for testing that I’ll publish soon as a separate crate.

                                                    1. 4

                                                      I had also started working on my own version, but never got far. So thank you for this. Do you have a link to that other implementation?

                                                      1. 3

                                                        They stopped working on it a while ago, and I took over the crate name on crates.io– they’ve since deleted the repo, but you can browse the source from docs.rs:

                                                        https://docs.rs/crate/nine/0.1.2/source/

                                                      2. 4

                                                        FWIW, I believe crosvm (the ChromeOS hypervisor written in Rust) has an implementation of 9p: https://chromium.googlesource.com/chromiumos/platform/crosvm/+/refs/heads/master/p9/

                                                        1. 3

                                                          Interesting! I wonder what they use it for.

                                                          1. 4

                                                            File sharing between the host and the guest I believe. My understanding is that 9p is a relatively common choice for that, for whatever reason.

                                                            1. 3

                                                              Ah, that makes sense. That’s because there’s 9p support built into the linux kernel for it, and it can work with virtio to provide very low overhead for the file sharing.

                                                      1. 7

                                                        I’m not familiar with the size of the OpenBSD kernel, can anyone give a sense of what fraction of the kernel 226 syscalls is?

                                                        1. 9

                                                          That’s pretty close to every syscall I believe. The last syscall is 330, but there are several large gaps.

                                                          http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/syscalls.master?rev=1.188&content-type=text/x-cvsweb-markup

                                                          1. 12

                                                            syscalls like ioctl() trigger so many code paths that it would make sense to count each ioctl type as a separate syscall for purposes of fuzzing.

                                                          2. 1

                                                            I second this question. That’s a big number for security-focused OS. Might be reasonable, too, given it’s monolithic kernel with batteries included. I did a quick check on the site. Didn’t see a full list of system calls.

                                                          1. -3

                                                            “Considered Harmful” Essays Considered Harmful (I think “considered dangerous” falls in the same category)

                                                            It’s not difficult to use C correctly. Don’t blame your vulnerabilities on C when the real culprit is your own sloth.

                                                            I’ll concede that C (and it’s API) has quite a few foot guns, but I’ve learned how to avoid them pretty effectively, and I should be able to expect the same from kernel devs. The whole “rewrite everything in <insert promising new lang here>” mentality doesn’t work for large projects (like kernels). To rewrite the Linux kernel in Rust would take months (even if you had all hands on deck). And, who’s to say that Rust wouldn’t change incompatibly three times in the middle?

                                                            1. 21

                                                              It’s not difficult to use C correctly.

                                                              [citation needed]

                                                              There is no evidence to suggest that large codebases written in C can maintain memory safety in the face of that. The counter evidence, that writing code in C/C++ tends to produce large volumes of vulnerabilities, for reasons that are explained by language choice, is plentify. To whit, every major OS (Windows, Linux, macOS), every major browser (Chrome, Firefox, Edge, Safari), every major anti-virus program, every major image parsing library, I can keep going for a while.

                                                              Denialism about the dangers of memory unsafety is not productive, we need to move on to discussing how we address this.

                                                              1. 0

                                                                There is no evidence to suggest that large codebases written in C can maintain memory safety in the face of that.

                                                                Using C correctly means not making large codebases. C isn’t a language for programming in the large.

                                                                1. -1

                                                                  there is no evidence that large codebases in any language produces anything better.

                                                                  1. 7

                                                                    Yes there is. The default, failure mode of safe languages doing common things is not potential code injection. The default for C language is. Given same bug count, using C will lead to more severe problems. The field results confirm that from fuzzing to CVE’s.

                                                                    1. 4

                                                                      Yes there is. The default, failure mode of safe languages doing common things is not potential code injection.

                                                                      I don’t think this is wrong, exactly, but there’s a 100 exploits related to python pickle, etc. as counterexamples. And java serialize, etc.

                                                                      1. 3

                                                                        Do the memory-safe parts have the memory errors of C (a) at all or (b) as much? And do libraries in concurrency safe languages show same or less races as equivalent in multithreaded C?

                                                                        You’re going to find vulnerabilities in all of them. My side are saying C amplifies that number by default or others greatly reduce it by default. That’s all we’re saying. I think the evidence is already supporting that.

                                                                        1. 1

                                                                          amplify requires some comparative numbers.

                                                                          1. 2

                                                                            The numbers on using C are that the common operations lead to piles of vulnerabilities with code injection. This happens a lot on average. It happens less with veterans but still happens. That’s irrefutable. The numbers on safe languages show the problems mostly lead to compiler failures or DOS’s from runtime checks. The burden of proof is on your side given your side’s stuff is getting smashed the hardest all the time whether the app is small or big.

                                                                            What numbers do you have showing C is safer for average developer than Ada, Rust and so on? And I’m especially interested in fuzzing results of software to see how many potentially lead to code injection among new, half-ass, or just time-constrained programmers in C vs the same in safe, systems languages.

                                                                            1. 1

                                                                              you don’t even have good examples of large scale systems built using some other language that are substantially safer. Until you do, it’s just folklore.

                                                                      2. 0

                                                                        I see a real shortage of example of large-scale systems constructed in any language that are secure and bug free but I am happy to look at references. Like what do we have comparable to Qmail written in something better that has fewer bugs? I know that C has numerous limitations, but in CS we tend to embrace projects that claim a win by hiding a problem by e.g. using pragmas to do the things that are the most buggy as if pushing the problem into the corner made it go away.

                                                                        And the code injection bugs I see are all example of bad engineering - not of bad programming.

                                                                        1. 3

                                                                          There’s bugs and there’s serious bugs that the language causes. The latter are what hackers hit the most. The latter are what we’re talking about, not just bugs in general. The size of the program also doesnt matter since the safe language is immune to the latter by design. Scaling code up just increases odds of severe vulnerabilities in the unsafe, control language.

                                                                          Java and .NET apps are what to look at if you want big ones. Very few CVE’s posted on the apps of the kind you see in C apps. The ones that are posted are usually in C/C++ runtimes or support libraries of such languages. That just illustrates the problem more. The languages whose runtimes arent C have fewer of those since they’re immune or contain them by design.

                                                                          1. 1

                                                                            My impression is that a) the reasons that those c/c++ runtimes show up so much is that these language delegate the most dangerous code such as parsing of raw input or packets or complex interaction with the OS to the C/C++ runtimes where it is possible to do that work and b) the same errors show up in different form in different languages. The massive prevalence of scripting exploits is not due to C but to lazy interface construction where, for example, user inputs are treated as parts of database scripts etc etc. I do not think that “do all the hard stuff in pragmas or C libraries” actually does limit vulnerabilities.

                                                                            1. 1

                                                                              “where it is possible to do that work”

                                                                              The first part is true. That part isn’t. They think lower-level language is better for speed, bit handling, or OS interface. The second part implies you need C to do that work. There’s systems languages which can do that work with more safety than C. So, it’s “possible to do that work” in them without C’s drawbacks. Many low-level programs and OS’s were written in PL/0, PL/S, Ada, Modula-2, Oberon, Modula-3, Clay, and so on. They’re safe by default turning it off only where you need to. C doesn’t do that since it’s designers didn’t care when they were hacking on a PDP-11 for personal use.

                                                                              “b) the same errors show up in different form in different languages. The massive prevalence of scripting exploits is not due to C but to lazy interface construction where, for example, user inputs are treated as parts of database scripts etc etc.”

                                                                              Aside from something language-specific, the logic errors that happen in scripting languages can happen in C, too. You get those errors plus C’s errors plus the catastrophic effect that comes with them being in C. Let’s say you wrote the interpreter in Ada or Rust with safety-checks on. Most of the errors in the interpreter won’t lead to hacks. The extensions would have same property if building on base language like how extensions to C-based programs are often in C having same problems. Platforms like Java that built libraries on C are hit heavily in those C dependencies.

                                                                              Additionally, the extensions could leverage aspects of these languages, such as type or module systems, designed for knocking out integration errors. Finally, if it’s Ada 2012 and SPARK, they can eliminate runtime checks in performance-critical code by using the provers to show they’re not needed if specific pre-conditions pass early on. Unlike Frama-C, they get a good baseline on code they hurried and highest assurance of what they proved.

                                                                              1. 1

                                                                                Data would help. These arguments by what seems sensible to different people don’t go anywhere.

                                                                  2. 16

                                                                    To rewrite the Linux kernel in Rust would take months (even if you had all hands on deck).

                                                                    Months? It would take at least 10 years, regardless of headcount.

                                                                    I’ve learned how to avoid them pretty effectively, and I should be able to expect the same from kernel devs.

                                                                    I’m impressed with your abilities, but then something nags me about the order-of-magnitude mistake in your rewrite estimate. Hmm.

                                                                    1. 13

                                                                      It’s not difficult to use C correctly. Don’t blame your vulnerabilities on C when the real culprit is your own sloth. I’ll concede that C (and it’s API) has quite a few foot guns, but I’ve learned how to avoid them pretty effectively, and I should be able to expect the same from kernel devs. The whole “rewrite everything in ” mentality doesn’t work for large projects (like kernels). To rewrite the Linux kernel in Rust would take months (even if you had all hands on deck). And, who’s to say that Rust wouldn’t change incompatibly three times in the middle?

                                                                      I suggest you read the linked article first. The title is clickbait but the content is solid. No one even mentioned Rust or anything else… The guy talks on their effort to reduce the foot guns in the kernel code…

                                                                      Here is a quote for the lazy:

                                                                      Kees Cook gave a presentation on some of the dangers that come with programs written in C. In particular, of course, the Linux kernel is mostly written in C, which means that the security of our systems rests on a somewhat dangerous foundation. But there are things that can be done to help firm things up by “Making C Less Dangerous” as the title of his talk suggested.

                                                                      1. 4

                                                                        I suggest you read the linked article first.

                                                                        Ok, you got me, I only skimmed the article and I didn’t see any mention of rewrite until the comments (it was literally the first response to the second comment). Although I do hear that mentality about other large projects (such as Firefox) as well. I guess I should’ve said “Clickbait considered harmful” ;-)

                                                                        I’ve read some more of the article and he seems to know what he’s talking about but I would like to see the original talk.

                                                                        As far as reducing foot guns, I guess Linux did start out as just one guy so I can understand a lot of foot shooting, but it’s been years and I would’ve thought that things like VLAs would’ve been avoided in the kernel. Then agian, I’ve never worked on a project as large as Linux so i guess I’m not the best judge of such things.

                                                                        1. 4

                                                                          Ok, you got me, I only skimmed the article and I didn’t see any mention of rewrite until the comments (it was literally the first response to the second comment). Although I do hear that mentality about other large projects (such as Firefox) as well.

                                                                          Agreed. It’s annoying as hell, and the loud-mouths never do the work.

                                                                          I guess I should’ve said “Clickbait considered harmful” ;-)

                                                                          Funny because the talk is titled ‘Making C Less Dangerous’ - the lwn reporter is actually responsible for the horrible title that misrepresents the content and invites rewrite talks. I think this is the first time I’m using the lobste.rs ‘suggest’ a new title option to rename the link to ‘Making C Less Dangerous’ disrespecting the reporters chosen title. This is an abstract of the talk so keep the title close to the content.

                                                                      2. 7

                                                                        Literally 20+ years of unending computer security exploits disagree with you.

                                                                      1. 7

                                                                        I think Go and Rust did a lot of work towards helping people think about construction, by not having it!

                                                                        Both allow you to instantiate a struct by it’s fields. If you want to do something more complicated, you write a function, with a normal signature.

                                                                        1. 2

                                                                          And this is what you end up doing even in C++ if you an initialization routine that can fail: a static function that constructs an object or fails. You mark the constructor as private so it can only be created with these static functions.

                                                                          The problem with this approach is that it leaves inexperienced programmers with another gun to shoot themselves with. If they neglect to handle failure cases in the constructor, the object can get into a state that was not reasoned about.

                                                                          Best to keep it simple by having only one way to create objects, like in Go and Rust.

                                                                          1. 1

                                                                            I think this situation would be avoided in C++ if it allowed either an initializer list, or a constructor body, but not both. As a rule of thumb, if I already have an initializer list, and I need to do something in the body of my constructor, I do my best to factor that into a separate class.

                                                                        1. 1

                                                                          We don’t want to get submissions for every CVE and, if we do get CVEs, we probably want them tagged security.

                                                                          1. 16

                                                                            while I agree with you in this case, I don’t particularly like the “I speak for everyone” stance you seem to be taking here.

                                                                            1. 9

                                                                              This one is somewhat notable for being the first (?) RCE in Rust, a very safety-focused language. However, the CVE entry itself is almost useless, and the previously-linked blog post (mentioned by @Freaky) is a much better article to link and discuss.

                                                                              1. 4

                                                                                Second. There was a security vulnerability affecting rustdoc plugins.

                                                                            2. 4

                                                                              Do you think an additional CVE tag would make sense? Given there’s upvotes some people seem to be interested.

                                                                              1. 2

                                                                                That’d be a good meta tag proposal thread.

                                                                              2. 4

                                                                                Yeah, I’d rather not have them at all. Maybe a detailed, tech write-up of discovery, implementation, and mitigation of new classes of vulnerability with wide impact. Meltdown/Spectre or Return-oriented Programming are examples. Then, we see only the deep stuff with vulnerability-listing sites having the regular stuff for people using that stuff.

                                                                                1. 5

                                                                                  seems like a CVE especially arbitrary code execution is worth posting. my 2 cents

                                                                                  1. 5

                                                                                    There are a lot of potentially-RCE bugs (type confusion, use after free, buffer overflow write), if there was a lobsters thread for each of them, there’d be no room for anything else.

                                                                                    Here’s a list a short from the past year or two, from one source: https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Type%3DBug-Security+label%3AStability-Memory-AddressSanitizer&sort=-modified&colspec=ID+Type+Component+Status+Library+Reported+Owner+Summary+Modified&cells=ids

                                                                                    1. 2

                                                                                      i’m fully aware of that. What I was commenting on was Rust having one of these RCE-type bugs, which, to me, is worthy of discussion. I think its weird to police these like their some kind of existential threat to the community, especially given how much enlightenment can be gained by discussion of their individual circumstances.

                                                                                      1. -2

                                                                                        But that’s not Rust, the perfect language that is supposed to save the world from security vulnerabilities.

                                                                                        1. 4

                                                                                          Rust is not and never claimed to be perfect. On the other hand, Rust is and claims to be better than C++ with respect to security vulnerabilities.

                                                                                          1. 0

                                                                                            It claims few things - from the rustlang website:

                                                                                            Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

                                                                                            None of those claims are really true.

                                                                                            It’s clearly not fast enough if you need unsafe to get real performance - which is the reason this cve was possible.

                                                                                            It’s clearly not preventing segfaults - which this cve shows.

                                                                                            It also can’t prevent deadlocks so it is not guaranteeing thread safety.

                                                                                            I like rustlang but the claims it makes are mostly incorrect or overblown.

                                                                                            1. 2

                                                                                              Unsafe Rust is part of Rust. I grant you that “safe Rust is blazingly fast” may not be “really true”.

                                                                                              Rust prevents segfaults. It just does not prevent all segfaults. For example, a DOM fuzzer was run on Chrome and Firefox and found segfaults, but the same fuzzer run for the same time on Servo found none.

                                                                                              I grant you on deadlocks. But “Rust prevents data race” is true.

                                                                                          2. 2

                                                                                            I’m just going to link my previous commentary: https://lobste.rs/s/7b0gab/how_rust_s_standard_library_was#c_njpoza

                                                                                    1. 27

                                                                                      Sometimes I like to think that I know how computers work, and then I read something written by someone who actually does and I’m humbled most completely.

                                                                                      1. 11

                                                                                        A lot of this complexity seems down to the way Windows works, though. As a Linux user, the amount of somewhat confusing/crufty stuff going on in a typical Windows install boggles the mind; it’s almost as bad as Emacs.

                                                                                        1. 11

                                                                                          I guess to me it doesn’t feel like there’s much Windows specific complexity here, just a generally complex issue; a bug in v8’s sandboxed runtime and how it interacts with low-level OS-provided virtual memory protection and specific lock contention behavior, which only expressed itself by happenstance for the OP.

                                                                                          Some of this stuff just feels like irreducible complexity, though my lack of familiarity with Windowsisms (function naming style, non-fair locks, etc.) probably doesn’t help there.

                                                                                          1. 5

                                                                                            How does CFG work with chrome on linux?

                                                                                            1. 2

                                                                                              Do you mean CFI?

                                                                                              CFG is MS’s Control Flow Guard, it’s a combination of compile-time instrumentation from MSVC and runtime integration with the OS. CFI on Linux (via clang/LLVM), in contrast, is entirely compile time AFAIK, with basically no runtime support.

                                                                                              See:

                                                                                              for more details on the differences.

                                                                                              1. 2

                                                                                                Yes and no. :) The linux CFI implementation doesn’t include the jit protection feature in CFG that’s implicated in the bug, so I’m not sure it’s fair to characterize this as “cruft”.

                                                                                                1. 2

                                                                                                  The CFI implementation in llvm isn’t a “linux CFI implementation.” :)

                                                                                                  As OpenBSD moves towards llvm on all architectures, it can take advantage of CFI, just as HardenedBSD already does. :)

                                                                                                2. 1

                                                                                                  llvm’s implementation of CFI does have the beginnings of a runtime support library (libclang_rt.cfi). HardenedBSD is working on integrating Cross-DSO CFI from llvm, which is what uses the support library.

                                                                                              2. 4

                                                                                                Linux just hasit’s own weirdnesses in other places.

                                                                                                That said, memory management seems to be a source of strange behaviour regardless of OS.

                                                                                            1. 51

                                                                                              It’s pretty subtle, but I think it’s important to notice that here Rust is being fundamentally held to a higher bar (which is fair, to be clear).

                                                                                              The C vulnerabilities are basically all the case that on specific user input, they materialize.

                                                                                              The Rust vulnerabilities are “if you use this API in this particular way” they materialize. (This is also the case for a lot of the Python RCEs, the only way to trigger them is to execute arbitrary Python code.)

                                                                                              That’s a big advancement! Unless they’re in common patterns, the vulnerable code won’t actually be exploitable.

                                                                                              I think this observation is supported by real world evidence. Consider Domato, which is a DOM fuzzer for browsers. When Project Zero folks ran it for 100,000,000 iterations on each major browser, it found vulnerabilities in all of them. So far, when it’s been run against rust, it finds a bunch of panics, but not vulnerabilities as far as I can tell: https://github.com/servo/servo/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+domato

                                                                                              Rust should continue to aim higher: less need for unsafe, better abstractions for writing safe unsafe code, and clearer semantics for unsafe code. But I think it’s important to be clear that Rust has already significantly raised the bar.

                                                                                              1. 10

                                                                                                The security researcher also recommended we consider using GPG signing for Homebrew/homebrew-core. The Homebrew project leadership committee took a vote on this and it was rejected non-unanimously due to workflow concerns.

                                                                                                This is incredibly sad and makes me wonder what part of the workflow would have been impacted. Git automatically signs the commits I make for me once I have entered my password once, thanks to gpg-agent.

                                                                                                1. 3

                                                                                                  They have a bot which commits hashes for updated binary artifacts. If all commits needed to be signed, it’d need an active key, and now you have a GPG key on the Jenkins server, leaving you no better off.

                                                                                                  1. 2

                                                                                                    But gpg cannot work with multiple smartcards at the same time, so maybe that’s a reason for some people. Either way there are simpler ways to deal with signing than gpg

                                                                                                    1. 1

                                                                                                      GPG signing wouldn’t have fixed this vulnerability as such, since presumably the same people not thinking about the visibility of the bot’s token would have equally failed to think about the visibility of the bot’s hypothetical private key

                                                                                                    1. 3

                                                                                                      Just finished Raven Rock, by Garrett Graff. It’s the history of the US’s continuity of government/continuity of operations/continuity of the presidency plans (primarily in the context of nuclear war), from Truman through the Obama Administration.

                                                                                                      It’s a fascinating combination of politics, technology, and social issues. If you’ve ever found the “football” or the “gold card” to be a neat idea, you’ll like this book.

                                                                                                      And the opening chapter is the perfect story to drag you in: someone doing radio ops/control tower work for Air Force one, on the day Nixon resigns, hearing that the plane is changing call site from Air Force One to USAF 27000 at 12:00:30pm, and only finding out what the deal was when he gets home and sees the news.

                                                                                                      1. 1

                                                                                                        There is no way in heck that linus will merge some DIY home rolled crypto code into the kernel

                                                                                                        1. 11

                                                                                                          It seems like you may not recognize the author. I would typically agree with you on first glance, but given who it is and what it is I wouldn’t be surprised if it got merged.

                                                                                                          1. 8

                                                                                                            That’s a good point but missing key detail. I’ll add author did WireGuard which has had good results in both formal verification and code review.

                                                                                                          2. 7

                                                                                                            Where else is kernel crypto code rolled?

                                                                                                              1. 2

                                                                                                                High praise from linus!

                                                                                                              2. 2

                                                                                                                Why not? How would Linus even know if some crypto code was DIY nonsense?

                                                                                                                (The subtext of these commits from Jason is that the existing kernel crypto APIs are not particularly good, IMO.)

                                                                                                              1. 3

                                                                                                                Now we’re just waiting on Safari…

                                                                                                                I’m extremely frustrated Apple is not being more proactive in adding support for WebAuth/U2F. Phishing is a serious problem, and U2F is a solution to it that works (as opposed to phishing tests and telling employees not to click on links, but of which demonstrably do not work). iOS’s lack of support for NFC for WebAuthn is a massive hindrance to adoption (BLE is a significantly worse UX).

                                                                                                                1. 4

                                                                                                                  I personally find this API fairly frustrating. This call can have three different semantics, depending on the values and context in which you call it. This contributes to complexity.

                                                                                                                  I notice that in the userspace diff, the “lock unveil” functionality is never used, even in cases where unveil is added to the pledge string. As far as I understand it, this means that if an attack obtained code execution, they’d simply be able to undo the unevil with unveil("/", "rwx"). That’s unintuitive and likely to be a regular source of programming errors.

                                                                                                                  Grabbing some comments I made on IRC last night on how I’d persue this API:

                                                                                                                  22:10:09 <Alex_Gaynor> If I was doing this API, I'd probably do `sandbox_context *sandbox_context_create(void)` and then a bunch of `sandbox_context_add_X(sandbox_context *, ...)` with appropriate signatures, and then a `sandbox_context_apply(sandbox_context *)` and basically a default `sandbox_context` had no permissions, and then you can add back whatever you want, and calling `sandbox_apply` a second time on a process killed the process or something
                                                                                                                  22:10:34 <Alex_Gaynor> (Or maybe was allowed, as long as the permissions were a strict subset of what was already applied)
                                                                                                                  22:12:33 <Alex_Gaynor> Oh, and they should add a platform-specific `posix_spawn_...` thing to take a `sandbox_context` so that it's applied right at `exec`, before any user code runs.
                                                                                                                  22:13:23 <Alex_Gaynor> Basically the two properties I've found useful in sandboxing are: a) It should be extremely easy to see what capabilities your process has, you want them all in one place, and defaulted to "nothing" so basically the permissions are what you have written down, b) It should be extremely easy to draw a perimeter around what your process already does, and slowly wittle it down by basically deleteing "adds".
                                                                                                                  
                                                                                                                  1. 2

                                                                                                                    I notice that in the userspace diff, the “lock unveil” functionality is never used, even in cases where unveil is added to the pledge string.

                                                                                                                    I only saw two or three diffs where it isn’t clear if the unveil pledge is later revoked. All others that add unveil to pledge also have a pledge without unveil soon after the unveil calls. It’s possible the two or three cases also have it but it’s just not visible in the diff.

                                                                                                                    So in these programs, that attack does not work unless you get your RCE during the initialization phase.

                                                                                                                    Even if unveil was never locked, it can still protect against all-too-common path traversal style bugs (especially in web crapps) that leak data without RCE.

                                                                                                                  1. 2

                                                                                                                    So, I only took a skim, but I started with the advice for strings: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152038

                                                                                                                    The advice here basically just says “don’t have a bug”. Don’t pass non-nul terminated strings to functions that want a nul-terminated string!

                                                                                                                    A coding standard should give you entire practices not to use to avoid bugs. For example, never use nul-terminated strings, as they are to error prone! Simply giving you example bug-types and telling you not to write them isn’t particularly useful.

                                                                                                                    (Obligatorily: a huge number of the bug-classes described here are basically unique to C/memory-unsafe programming languages. Telling people “please stop writing bugs” is a losing strategy, even with all the static and dynamic analysis in the world. We can’t produce bugs en masse and then de-bug our way out of it, we need to adopt programming languages that prevent the bugs in the first place.)