Threads for jamesw

  1. 9

    I’m really excited about releases like these. It’s just “finishing” the language and not adding any new features conceptually, just making it all more cohesive. The lack of Enum default derive is one of those things I run into rarely, but adding it in now reduces the conceptual overhead of Rust since deriving default now works on both Enums and Structs.

    I also think this shows the benefit of Rust’s release model, which is that smaller fixes and stabilizations can be made over time, and don’t have to be part of a larger release. I’m curious how the potential Rust stabilization in GCC affects things, especially when smaller fixes in a release like this might be nice in older versions of Rust (and as far as I know GCC is targeting an older Rust version).

    1. 10

      Rust has a fixed 6-week release train model. Nobody decides which release is going to be small or not. When stuff is ready, it lands.

      Once in a while a large feature that took years to develop lands, and people freak out and proclaim that Rust is changing to fast and rushing things, as if it invented and implemented every feature in 6 weeks.

      In this release: cargo add feature request was filed 8 years ago. Implementation issue has been opened 4 years ago. It waited for a better TOML parser/serializer to be developed, and once that happened, the replacement work started 5 months ago.

      1.  

        a better TOML parser/serializer

        This piques my interest. What library is this? Does it maintain comments/formatting?

        1.  

          The crate is toml_edit, and it does preserve comments and (most) formatting.

          Maybe something to format Cargo.toml files could be helpful as well?

      2. 1

        I’m curious how the potential Rust stabilization in GCC affects things

        What do you mean? The gcc-rs project? I’d hope it doesn’t affect mainline Rust at all.

        1. 2

          Yeah the gcc-rs project. I wonder about certain stabilizations in later versions of Rust which are very easily added to earlier versions of Rust built by gcc-rs. I don’t think it will affect mainline Rust, but if certain nice-to-haves, or more importantly unsound fixes, are backported for gcc-rs that could cause an unfortunate schism in the ecosystem.

          I haven’t seen or heard of anything indicating this might happen, but with multiple implementations in-use I do think it is something that will eventually occur (especially for safety-related and unsound concerns)

        2. 1

          I have never liked the idea of a Default trait or typeclass. Default with respect to what operation? Most times people want defaulting, they seem to have some kind of monoidal operation in mind.

          1. 9

            Default with respect to what operation?

            Initialization right? I don’t see how one would use the trait for any other operation. To me it seems quite natural that a number has a “reasonable default” (0) as well as a string (""). It’s not like the language forces you to use Default in case you have other defaults in mind.

        1. 4

          How do I ssh -X with wayland?

          1. 14

            waypipe will proxy Wayland messages similarly to ssh -X.

          1. 36

            The core problem is the only entities currently paying for web browser development have mixed motives. The EU should just buy out Mozilla and make Firefox into the browser for the people instead of waiting around for Google to stop breaking their laws.

            1. 9

              What’s to buy? It’s open source. They can contribute to it or fork it if Mozilla Corp doesn’t like their changes.

              1. 21

                The Mozilla organization, including the expertise necessary to develop and maintain Firefox. It would probably cost more to build an independent organization capable of doing the same thing.

                1. 3

                  Which Mozilla organization? The non-profit Mozilla Foundation or the for-profit Mozilla Corporation?

                  1. 7

                    I’m not sure, what do you think?

                    1. 5

                      The Mozilla Corporation is owned in its entirety by the Mozilla Foundation. Even if somehow the Foundation were convinced to sell the Corporation, the Foundation is the one that owns the key intellectual property and is the actual steward of the things people think of as “Mozilla”. The Corporation’s purpose is to be an entity that pays taxes and thus can have types of revenue and business deals that are forbidden to a non-profit.

                      1. 1

                        The employees who work on Firefox and everything that encompasses work for the Corporation. It has more of a purpose than “taxes”.

                        1. 3

                          I am a former employee of the Mozilla Corporation, so I am aware of what the MoCo employees do.

                          1. 1

                            MoCo gets all of the revenue that’s generated by Firefox and employs most of the developers. All but one of the members of the Firefox Technical Leadership team work for Mozilla Corp - the one that doesn’t did until relatively recently: https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership

                            While the Foundation technically owns the IP the Corporation controls the direction of the product and collects all of the revenue generated by the work of both their employees and contributions from the community.

                  2. 9

                    Declare Firefox a public infrastructure and fund Mozilla or another entity to upkeep and enhance that infrastructure.

                  3. 11

                    No thanks, I’ve had enough cookie popups for one day.

                    1. 55

                      The GDPR is specific about cookie banners not being obtrusive, and that rejecting tracking is as easy as accepting.

                      The only compliant banner I regularly see is from gov.uk, and I find it doesn’t annoy me at all.

                      The popups are as obnoxious as possible to make us hate the GDPR. Can’t we oppose the tracking instead of the law telling us when it’s happening?

                      1. 8

                        And of course the core thing is you don’t need the cookie popups if you’re not doing random tracking of people!

                        Every cookie popup is an announcement that the site has some automated trackers set up. If you are just using cookies for things like handling sessions you do not need the cookies.

                        1. 8

                          Absolutely. The options are either make your tracking opt-in through genuinely informed consent, or don’t track at all.

                          Companies found the secret third option, which is just ignore the law and dark pattern your users into agreeing to anything.

                          Banners say things like “we need cookies for this site to work” and pretend they need your permission to use them. Ironically they only need permission for the cookies that aren’t essential to make the site work.

                          Hiding things away under “legitimate interest” makes things even more confusing. Are the other things illegitimate interests?

                          1. 2

                            Can someone explain to me what “legitimate interest” actually means?

                          2. 2

                            …you do not need the cookies.

                            Do you mean the cookies or the popups? I’m not familiar with how the GDPR treats non-cookie based things like JWT in local storage and sent with every request.

                            1. 2

                              The same. You require consent to store any data on user computer. However it do not require some “essential” cookies - for example cookie with preferences for dark/light theme do not require consent if it is direct action on website, cookie containing session ID do not require consent, etc. That applies for local cookies only though.

                        2. 11

                          Same. I really wish companies would stop choosing to add them to their websites.

                          1. 4

                            If you already block tracking by any mean, you can get rid of those banners using something like https://addons.mozilla.org/en-GB/firefox/addon/i-dont-care-about-cookies/.

                            1. 3

                              Yeah, the EU’s heart was in the right place, but implementation has been a disaster. It’s like passing a law that murder is okay as long you say “I am going to murder you” as you take out the knife.

                              1. 27

                                What the EU did was basically passing a law that makes murder illegal. Companies/Murderers just ignore it and go around saying “anyone that doesn’t want to be murdered please answer by saying your name within of the next millisecond. Guess no one answered, so you’ve just consented to murder!”

                                GDPR explicitly bans all the annoying dark patterns of cookie banners. A GDPR-compliant cookie banner would ask you once whether you consent to tracking. It’d have one huge no button (but no easily accessible yes button). If you ever click no, it’d have to remember as long as possible and close itself immediately. If you click yes, you’d have to go through a handful of options to specifically choose which tracking methods to allow.

                                1. 10

                                  So, basically the polar opposite of many cookie popups today, which have a big “I ACCEPT” button and a “More options” button that you have to click to manually turn off all tracking…

                                2. 3

                                  Except large Internet companies are much more powerful and accountable to public pressure than murderers, so they should face at least as much public scorn as the lawmakers.

                                  1. 2

                                    There’s a saying, that road to hell is paved with good intentions.

                                    That often means that if someone’s is not sure how to help, then proceeding with helping can create more problems than resolve anything.

                                    1. 2

                                      That’s better than having no law against murder. Then we can move away from all the people saying “I am going to murder you.”

                                    2. 2

                                      Umm… we’ve just today decided to instruct Matomo not to use cookies rather then implement cookie banner for our new Wagtail-based websites. I think it’s working?

                                      1. 1

                                        Cookie popups on websites linked to by Google?

                                    1. 2

                                      Stabilized Not for !.

                                      Interesting that any trait with only methods and no functions can be implemented for the never type since they can’t be called: Primitive Type never.

                                      1. 3

                                        Interesting that any trait with only methods and no functions can be implemented for the never type

                                        In other contexts, that is called the bottom type, because it sits at the bottom of the type lattice, and is therefore a subtype of every other type. So I find this fairly unsurprising.

                                        1. 1

                                          Isn’t that the initial type? I thought the bottom type was () since we can always reach it

                                          1. 4

                                            No. ‘bottom’ refers to subtyping relationships, not compositional relationships. It’s true you can make anything from (), |, and *. But () isn’t a subtype of ()|().

                                            E: this is general nomenclature. It’s possible rust has its own vocabulary I don’t know about.

                                      1. 4

                                        Would ‘grepability’ be solved by having the source code of direct dependencies downloaded to a subfolder of the project. Almost a decade ago when I used to code in Java, maven would download the source code of all the dependencies and it was trivial to search through them if I needed to. I have not messed with Rust yet and so I am wondering if crate has similar capabilities?

                                        1. 5

                                          cargo vendor is what you want for downloading dependency sources.

                                        1. 40

                                          Looks like the employee is based in the UK. As you might expect, most of the responses to his announcement are Bad Legal Advice. This comment is also going to be Bad Legal Advice (IANAL!) but I have some experience and a little background knowledge so I hope I can comment more wisely…

                                          The way FOSS (and indeed all private-time) software development works here for employees is that according to your contract your employer will own everything you create, even in your private time. Opinions I’ve heard from solicitors and employment law experts suggest that this practice might constitute an over-broad, “unfair”, contract term under UK law. That means you might be able to get it overturned if you really tried, but you’d have to litigate to resolve it. At any rate the de facto status is: they own it by default.

                                          What employees typically do is seek an IP waiver from their employer where the employer disclaims ownership of the side-project. The employer can refuse. If you’ve already started they could take ownership, as apparently is happening in this case. Probably in that scenario what you should not do is try to pre-emptively fork under some idea that your project is FOSS and that you have that right. The employer will likely take the view that because you aren’t the legal holder of the IP that you aren’t entitled to release either the original nor the fork as FOSS - so you’ve improperly releasing corporate source code. Pushing that subject is an speedy route to dismissal for “gross misconduct” - which a sufficient reason for summary dismissal, no process except appeal to tribunal after the fact.

                                          My personal experience seeking IP waivers, before I turned contractor (after which none of the above applies), was mixed. One startup refused it and even reprimanded me for asking - the management took the view that any side project was a “distraction from the main goal”. Conversely ThoughtWorks granted IP waivers pretty much blanket - you entered your project name and description in a shared spreadsheet and they sent you a notice when the solicitor saw the new entry. They took professional pride in never refusing unless it conflicted with the client you were currently working with.

                                          My guess is that legal rules and practices on this are similar in most common law countries (UK, Australia, Canada, America, NZ).

                                          1. 27

                                            The way FOSS (and indeed all private-time) software development works here for employees is that according to your contract your employer will own everything you create, even in your private time.

                                            This seems absurd. If I’m a chef, do things I cook in my kitchen at home belong to my employer? If I’m a writer do my kids’ book reports that I help with become privileged? If I’m a mechanic can I no longer change my in-laws’ oil?

                                            Why is software singled out like this and, moreover, why do people think it’s okay?

                                            1. 10

                                              There have been cases of employees claiming to have written some essential piece of software their employer relied on in their spare time. Sometimes that was even plausible, but still it’s essentially taking your employer hostage. There have been cases of people starting competitors to their employer in their spare time; what is or is not competition is often subject to differences of opinion and are often a matter of degree. These are shadow areas that are threatening to business owners that they want to blanket prevent by such contractual stipulations.

                                              Software isn’t singled out. It’s exactly the same in all kinds of research, design and other creative activities.

                                              1. 12

                                                There have been cases of people starting competitors to their employer in their spare time;

                                                Sounds fine to me, what’s the problem? Should it be illegal for an employer to look for a way to lay off employees or otherwise reduce its workforce?

                                                1. 4

                                                  what’s the problem?

                                                  I think it’s a pretty large problem if someone can become a colleague, quickly hoover up all the hard won knowledge we’ve together accumulated over the past decade, then start a direct competitor to my employer, possibly putting me out of work.

                                                  You’re thinking of large faceless companies that you have no allegiance to. I’m thinking of the two founders of the company that employs me and my two dozen colleagues, whom I feel loyal towards.

                                                  This kind of thing protects smaller companies more than larger ones.

                                                  1. 2

                                                    …start a direct competitor to my employer, possibly putting me out of work.

                                                    Go work for the competitor! Also, people can already do pretty much what you describe in much of the US where non-competes are unenforceable. To be clear, I think this kind of hyper competitiveness is gross, and I would much rather collaborate with people to solve problems than stab them in the back (I’m a terrible capitalist). But I’m absolutely opposed to giving companies this kind of legal control over (and “protection” from) their employees.

                                                    1. 3

                                                      Go work for the competitor!

                                                      Who says they want me? Also I care for my colleagues: who says they want them as well?

                                                      where non-competes are unenforceable

                                                      Overly broad non-competes are unenforceable when used to attempt to enforce against something not clearly competition. They are perfectly enforceable if you start working for, or start, a direct competitor, profiting from very specific relevant knowledge.

                                                      opposed to giving companies this kind of legal control

                                                      As I see it we don’t give “the company” legal control: we effectively give humans, me and my colleagues, legal control over what new colleagues are allowed to do, in the short run, with the knowledge and experience they gain from working with us. We’re not protecting some nameless company: we’re protecting our livelihood.

                                                      And please note that my employer does waive rights to unrelated side projects if you ask them, waives rights to contributions to OSS, etc. Also note that non-compete restrictions are only for a year anyway.

                                                      1. 1

                                                        Who says they want me? Also I care for my colleagues: who says they want them as well?

                                                        Well then get a different job, get over it, someone produced a better product than your company, that’s the whole point of capitalism!

                                                        They are perfectly enforceable if you start working for, or start, a direct competitor, profiting from very specific relevant knowledge.

                                                        Not in California, at least, it’s trivially easy to Google this.

                                                        As I see it we don’t give “the company” legal control: we effectively give humans, me and my colleagues, legal control over what new colleagues are allowed to do, in the short run, with the knowledge and experience they gain from working with us.

                                                        Are you a legal party to the contract? If not, then no, it’s a contract with your employer and if it suits your employer to use it to screw you over, they probably will.

                                                        I truly hope that you work for amazing people, but you need to recognize that almost no one else does.

                                                        Even small startups routinely screw over their employees, so unless I’ve got a crazy amount of vested equity, I have literally zero loyalty, and that’s exactly how capitalism is supposed to work: the company doesn’t have to care about me, and I don’t have to care about the company, we help each other out only as long as it benefits us.

                                                      2. 1

                                                        Go work for the competitor?

                                                        Why would the competitor want/need the person they formerly worked with/for?

                                                        1. 1

                                                          Why did the original company need the person who started the competitor? Companies need workers and if the competitor puts the original company out of business (I was responding to the “putting me out of work” bit) then presumably it has taken on the original company’s customers and will need more workers, and who better than people already familiar with the industry!

                                                    2. 1

                                                      Laying off and reducing the workforce can be regulated (and is in my non-US country). The issue with having employees starting competitor products is that they benefit from an unfair advantage and create a huge conflict of interest.

                                                      1. 2

                                                        Modern Silicon Valley began with employees starting competitor products: https://en.wikipedia.org/wiki/Traitorous_eight

                                                        If California enforced non-compete agreements, Silicon Valley might well not have ended up existing. Non-enforcement of noncompetes is believed to be one of the major factors that resulted in Silicon Valley overtaking Boston’s Route 128 corridor, formerly a competitive center of technology development: https://hbr.org/2016/11/the-reason-silicon-valley-beat-out-boston-for-vc-dominance

                                                        1. 1

                                                          I don’t think we are talking about the same thing. While I agree that any restriction on post-employment should be banned, I don’t think it is unfair for an organization to ask their employees to not work on competing products while being under their payroll. These are two very different situations.

                                                        2. 2

                                                          If the employee uses company IP in their product then sure, sue them, that’s totally fair. But if the employee wants to use their deep knowledge of an industry to build a better product in their free time, then it sucks for their employer, but that’s capitalism. Maybe the employer should have made a better product so it would be harder for the employee to build something to compete with it. In fact, it seems like encouraging employees to compete with their employers would actually be good for consumers and the economy / society at large.

                                                          1. 1

                                                            An employee working on competing products on its free time creates an unfair advantage because the employees have access to an organization IP to build its new product while the organization does not have access to the competing product IP. So what’s the difference between industrial espionage and employees working on competing products on their free time?

                                                            1. 1

                                                              If the employee uses company IP in their product then sure, sue them, that’s totally fair.

                                                              That was literally in the comment you responded to.

                                                    3. 4

                                                      Joel Spolsky wrote a piece that frames it well, I think. I don’t personally find it especially persuasive, but I think it does answer the question of why software falls into a different bucket than cooking at home or working on a car under your shade tree, and why many people think it’s OK.

                                                      1. 3

                                                        Does this article suggest the employers view contracts as paying for an employee’s time, rather than just paying for their work?

                                                        Could a contract just be “in exchange for this salary, we’d like $some_metric of work”, with working hours just being something to help with management? It seems irrelevant when you came up with something, as long as you ultimately give your employer the amount of work they paid you for.

                                                        Why should an employer care about extra work being released as FOSS if they’ve already received the amount they paid an employee for?

                                                        EDIT: I realise now that $some_metric is probably very hard to define in terms of anything except number of hours worked, which ends up being the same problem

                                                        1. 2

                                                          Does this article suggest the employers view contracts as paying for an employee’s time, rather than just paying for their work?

                                                          I didn’t read it that way. It’s short, though. I’d suggest reading it and forming your own impression.

                                                          Could a contract just be “in exchange for this salary, we’d like $some_metric of work”, with working hours just being something to help with management? It seems irrelevant when you came up with something, as long as you ultimately give your employer the amount of work they paid you for.

                                                          I’d certainly think that one of many possible reasonable work arrangements. I didn’t link the article intending to advocate for any particular one, and I don’t think its author intended to with this piece, either.

                                                          I only linked it as an answer to the question that I read in /u/lorddimwit’s comment as “why is this even a thing?” because I think it’s a plausible and cogent explanation of how these agreements might come to be as widespread as they are.

                                                          Why should an employer care about extra work being released as FOSS if they’ve already received the amount they paid an employee for?

                                                          As a general matter, I don’t believe they should. One reason I’ve heard given for why they might is that they’re afraid it will help their competition. I, once again, do not find that persuasive personally. But it is one perceived interest in the matter that might lead an employer to negotiate an agreement that precludes releasing side work without concurrence from management.

                                                          1. 1

                                                            I only linked it as an answer to the question that I read in /u/lorddimwit’s comment as “why is this even a thing?” because I think it’s a plausible and cogent explanation of how these agreements might come to be as widespread as they are.

                                                            I think so too, and hope I didn’t come across as assuming you (or the article) were advocating anything that needs to be argued!

                                                            I didn’t read it that way. It’s short, though. I’d suggest reading it and forming your own impression.

                                                            I’d definitely gotten confused because I completely ignored that the author is saying that the thinking can become “I don’t just want to buy your 9:00-5:00 inventions. I want them all, and I’m going to pay you a nice salary to get them all”. Sorry!

                                                      2. 3

                                                        There is a huge difference: We’re talking about creativity and invention. The company isn’t hiring your for changing some oil or swapping some server hardware. They’re hiring you to solve their problems, to be creative and think of solutions. (Which is also why I don’t think it’s relevant how many hours you actually coded, the result and time you thought about it matters.) Your company doesn’t exist because it’s changing oil, the value is in the code (hopefully) and thus their IP.

                                                        So yes, that’s why this stuff is actually different. Obviously you want to have exemptions from this kind of stuff when you do FOSS things.

                                                        1. 2

                                                          I think the chef and mechanic examples are a bit different since they’re not creating intellectual property, and a book report is probably not interesting to an employer.

                                                          Maybe a closer example would be a chef employed to write recipes for a book/site. Their employer might have a problem with them creating and publishing their own recipes for free in their own time. Similarly, maybe a writer could get in trouble for independently publishing things written in their own time while employed to write for a company. I can see it happening for other IP that isn’t software, although I don’t know if it happens in reality.

                                                          1. 3

                                                            I think the “not interesting” bit is a key point here. I have no idea what Bumble is or the scope of the company, and I speak out of frustration of these overarching “legal” restrictions, but its sounds like they are an immature organization trying to hold on to anything interesting their employees do, core to the current business, or not, in case they need to pivot or find a new revenue stream.

                                                            Frankly if a company is so fearful that a couple of technologies will make make or break their company, their business model sucks. Technology != product.

                                                            1. 2

                                                              Similarly, maybe a writer could get in trouble for independently publishing things written in their own time while employed to write for a company

                                                              I know of at least one online magazine’s contracts which forbid exactly this. If you write for them, you publicly only write for them.

                                                          2. 10

                                                            This is pretty much my (non-lawyer) understanding and a good summary, thanks.

                                                            If you find yourself in this situation, talk to a lawyer. However I suspect that unless you have deep pockets and a willingness to litigate “is this clause enforceable” through several courts, your best chance is likely to be reaching some agreement with the company that gives them what they want whilst letting you retain control of the project or at least a fork.

                                                            One startup refused it and even reprimanded me for asking - the management took the view that any side project was a “distraction from the main goal”

                                                            I think the legal term for this is “bunch of arsehats”. I’m curious to know whether you worked for them after they started out like this?

                                                            1. 6

                                                              I think the legal term for this is “bunch of arsehats”.

                                                              https://www.youtube.com/watch?v=Oz8RjPAD2Jk

                                                              I’m curious to know whether you worked for them after they started out like this?

                                                              I left shortly after for other reasons

                                                            2. 2

                                                              The way FOSS (and indeed all private-time) software development works here for employees is that according to your contract your employer will own everything you create, even in your private time

                                                              Is it really that widespread? It’s a question that we get asked by candidates but our contract is pretty clear that personal-time open source comes under the moonlighting clause (i.e. don’t directly compete with your employer). If it is, we should make a bigger deal about it in recruiting.

                                                              1. 1

                                                                I would think the solution is to quit, then start a new project without re-using any line of code of the old project - but I guess the lawyers thought of this too and added clauses giving them ownership of the new project too…

                                                              1. 7

                                                                Finally, a bug which could not be fixed by using Rust :D

                                                                1. 15

                                                                  I am by no means a Rust fanboy, but I actually disagree in this case. The root cause of this appears to be incorrect error checking and I think this is caused by in-band signalling of error results. A language with union types that required an explicit match to differentiate between the error and non-error case would have prevented this kind of error.

                                                                  1. 5

                                                                    Well, it was worth a try ;) Thanks for the clarification :)

                                                                  2. 5

                                                                    In fairness, this looks like the kind of bug that’s harder to write in Rust since you’ve got to handle the error value (or explicitly ignore it) to get the success value. Polkit’s errors are a bit like tagged unions (without the union) in that the returned boolean tells you whether the *out_uid/*out_pid or the *error value is valid, but in this case the wrong tag was being returned. Putting them in a proper sum type would help with that.

                                                                    1. 3

                                                                      finally? many more of those around, take my favourite of the year: https://alephsecurity.com/2021/02/16/apport-lpe/

                                                                    1. 13

                                                                      Rust seems to do very well with the balance between its core team and the community driving the project. Posts like this give the impression that they’re getting wide discussions and covering a lot of use cases, but everything still manages to feel solid and well planned out in the language features and tooling.

                                                                      Of the other languages I use, C/C++ appears to have quite a disconnected community and the language itself gets driven by a tight group of people. On the other end of the spectrum, Perl has quite an interactive community and the language seems to be full of quirks that maybe weren’t thought through too much.

                                                                      Maybe this is a naive way of seeing things from the outside looking in. It would be nice to know whether people within these communities see things the same way.

                                                                      1. 37

                                                                        Hello, I am here to derail the Rust discussion before it gets started. The culprit behind sudo’s vast repertoire of vulnerabilities, and more broadly of bugs in general, is accountable almost entirely to one matter: its runaway complexity.

                                                                        We have another tool which does something very similar to sudo which we can compare with: doas. The portable version clocks in at about 500 lines of code, its man pages are a combined 157 lines long, and it has had two CVEs (only one of which Rust would have prevented), or approximately one every 30 months.

                                                                        sudo is about 120,000 lines of code (100x more), its had 140 CVEs, or about one every 2 months since the CVE database came into being 21 years ago. Its man pages are about 10,000 lines and include the following:

                                                                        $ man sudoers | grep -C1 despair
                                                                        The sudoers file grammar will be described below in Extended Backus-Naur
                                                                        Form (EBNF).  Don't despair if you are unfamiliar with EBNF; it is fairly
                                                                        simple, and the definitions below are annotated.
                                                                        

                                                                        If you want programs to be more secure, stable, and reliable, the key metric to address is complexity. Rewriting it in Rust is not the main concern.

                                                                        1. 45

                                                                          its had 140 CVEs

                                                                          Did you even look at that list? Most of those are not sudo vulnerabilities but issues in sudo configurations distros ship with. The actual list is more like 39, and a number of them are “disputed” and most are low-impact. I didn’t do a full detailed analysis of the issues, but the implication that it’s had “140 security problems” is simply false.

                                                                          sudo is about 120,000 lines of code

                                                                          More like 60k if you exclude the regress (tests) and lib directories, and 15k if you exclude the plugins (although the sudoers plugin is 40k lines, which most people use). Either way, it’s at least half of 120k.

                                                                          Its man pages are about 10,000 lines and include the following:

                                                                          12k, but this also includes various technical documentation (like the plugin API); the main documentation in sudoers(1) is 741 lines, and sudoers(5) is 3,255 lines. Well under half of 10,000.

                                                                          We have another tool which does something very similar to sudo which we can compare with: doas.

                                                                          Except that it only has 10% of the features, or less. This is good if you don’t use them, and bad if you do. But I already commented on this at HN so no need to repeat that here.

                                                                          1. 12

                                                                            You’re right about these numbers being a back-of-the-napkin analysis. But even your more detailed analysis shows that the situation is much graver with sudo. I am going to include plugins, becuase if they ship, they’re a liability. And their docs, because they felt the need to write them. You can’t just shove the complexity you don’t use and/or like under the rug. Heartbleed brought the internet to its knees because of a vulnerability in a feature no one uses.

                                                                            And yes, doas has 10% of the features by count - but it has 99% of the features by utility. If you need something in the 1%, what right do you have to shove it into my system? Go make your own tool! Your little feature which is incredibly useful to you is incredibly non-useful to everyone else, which means fewer eyes on it, and it’s a security liability to 99% of systems as such. Not every feature idea is meritous. Scope management is important.

                                                                            1. 9

                                                                              it has 99% of the features by utility

                                                                              Citation needed.

                                                                              what right do you have to shove it into my system?

                                                                              Nobody is shoving anything into your system. The sudo maintainers have the right to decide to include features, and they’ve been exercising that right. You have the right to skip sudo and write your own - and you’ve been exercising that right too.

                                                                              Go make your own tool!

                                                                              You’re asking people to undergo the burden of forking or re-writing all of the common functionality of an existing tool just so they can add their one feature. This imposes a great cost on them. Meanwhile, including that code or feature into an existing tool imposes only a small (or much smaller) cost, if done correctly - the incremental cost of adding a new feature to an existing system.

                                                                              The key phrase here is “if done correctly”. The consensus seems to be that sudo is suffering from poor engineering practices - few or no tests, including with the patch that (ostensibly) fixes this bug. If your software engineering practices are bad, then simpler programs will have fewer bugs only because there’s less code to have bugs in. This is not a virtue. Large, complex programs can be built to be (relatively) safe by employing tests, memory checkers, good design practices, good architecture (which also reduces accidental complexity) code reviews, and technologies that help mitigate errors (whether that be a memory-safe GC-less language like Rust or a memory-safe GC’ed language like Python). Most features can (and should) be partitioned off from the rest of the design, either through compile-time flags or runtime architecture, which prevents them from incurring security or performance penalties.

                                                                              Software is meant to serve the needs of users. Users have varied use-cases. Distinct use-cases require more code to implement, and thereby incur complexity (although, depending on how good of an engineer one is, additional accidental complexity above the base essential complexity may be added). If you want to serve the majority of your users, you must incur some complexity. If you want to still serve them, then start by removing the accidental complexity. If you want to remove the essential complexity, then you are no longer serving your users.

                                                                              The sudo project is probably designed to serve the needs of the vast majority of the Linux user-base, and it succeeds at that, for the most part. doas very intentionally does not serve the needs of the vast majority of the linux user-base. Don’t condemn a project for trying to serve more users than you are.

                                                                              Not every feature idea is meritous.

                                                                              Serving users is meritous - or do you disagree?

                                                                              1. 6

                                                                                Heartbleed brought the internet to its knees because of a vulnerability in a feature no one uses.

                                                                                Yes, but the difference is that these are features people actually use, which wasn’t the case with Heartleed. Like I mentioned, I think doas is great – I’ve been using it for years and never really used (or liked) sudo because I felt it was far too complex for my needs, before doas I just used su. But I can’t deny that for a lot of other people (mainly organisations, which is the biggest use-case for sudo in the first place) these features are actually useful.

                                                                                Go make your own tool! Your little feature which is incredibly useful to you is incredibly non-useful to everyone else

                                                                                A lot of these things aren’t “little” features, and many interact with other features. What if I want doas + 3 flags from sudo + LDAP + auditing? There are many combinations possible, and writing a separate tool for every one of them isn’t really realistic, and all of this also required maintenance and reliable consistent long-term maintainers are kind of rare.

                                                                                Scope management is important.

                                                                                Yes, I’m usually pretty explicit about which use cases I want to solve and which I don’t want to solve. But “solving all the use cases” is also a valid scope. Is this a trade-off? Sure. But everything here is.

                                                                                The real problem isn’t so much sudo; but rather that sudo is the de-facto default in almost all Linux distros (often installed by default, too). Ideally, the default should be the simplest tool which solves most of the common use cases (i.e. doas), and people with more complex use cases can install sudo if they need it. I don’t know why there aren’t more distros using doas by default (probably just inertia?)

                                                                                1. 0

                                                                                  What if I want doas + 3 flags from sudo + LDAP + auditing?

                                                                                  Tough shit? I want a pony, and a tuba, and barbie doll…

                                                                                  But “solving all the use cases” is also a valid scope.

                                                                                  My entire thesis is that it’s not a valid scope. This fallacy leads to severe and present problems like the one we’re discussing today. You’re begging the question here.

                                                                                  1. 4

                                                                                    Tough shit? I want a pony, and a tuba, and barbie doll…

                                                                                    This is an extremely user-hostile attitude to have (and don’t try claiming that telling users with not-even-very-obscure use-cases to write their own tools isn’t user-hostile).

                                                                                    I’ve noticed that some programmers are engineers that try to build tools to solve problems for users, and some are artists that build programs that are beautiful or clever, or just because they can. You appear to be one of the latter, with your goal being crafting simple, beautiful systems. This is fine. However, this is not the mindset that allows you to build either successful systems (in a marketshare sense) or ones that are useful for many people other than yourself, for previously-discussed reasons. The sudo maintainers are trying to build software for people to use. Sure, there’s more than one way to do that (integration vs composition), but there are ways to do both poorly, and claiming the moral high ground for choosing simplicity (composition) is not only poor form but also kind of bad optics when you haven’t even begun to demonstrate that it’s a better design strategy.

                                                                                    My entire thesis is that it’s not a valid scope.

                                                                                    A thesis which you have not adequately defended. Your statements have amounted to “This bug is due to sudo’s complexity which is driven by the target scope/number of features that it has”, while both failing to provide any substantial evidence that this is the case (e.g. showing that sudo’s bugs are due to feature-driven essential complexity alone, and not use of a memory-unsafe language, poor software engineering practices (which could lead to either accidental complexity or directly to bugs themselves), or simple chance/statistics) and not actually providing any defense for the thesis as stated. Assume that @arp242 didn’t mean “all” the usecases, but instead “the vast majority” of them - say, enough that it works for 99.9% of users. Why is this “invalid”, exactly? It’s easy for me to imagine the argument being “this is a bad idea”, but I can’t imagine why you would think that it’s logically incoherent.

                                                                                    Finally, you have repeatedly conflated “complexity” and “features”. Your entire argument is, again, invalid if you can’t show that sudo’s complexity is purely (or even mostly) essential complexity, as opposed to accidental complexity coming from being careless etc.

                                                                              2. 9

                                                                                I dont’t think “users (distros) make a lot of configuration mistakes” is a good defence when arguing if complexity is the issue.

                                                                                But I do agree about feature set. And I feel like arguing against complexity for safety is wrong (like ddevault was doing), because systems inevitably grow complex. We should still be able to build safe, complex systems. (Hence why I’m a proponent of language innovation and ditching C.)

                                                                                1. 11

                                                                                  I dont’t think “users (distros) make a lot of configuration mistakes” is a good defence when arguing if complexity is the issue.

                                                                                  It’s silly stuff like (ALL : ALL) NOPASSWD: ALL. “Can run sudo without a password” seems like a common theme: some shell injection is found in the web UI and because the config is really naïve (which is definitely not the sudo default) it’s escalated to root.

                                                                                  Others aren’t directly related to sudo configuration as such; for example this one has a Perl script which is run with sudo that can be exploited to run arbitrary shell commands. This is also a common theme: some script is run with sudo, but the script has some vulnerability and is now escalated to root as it’s run with sudo.

                                                                                  I didn’t check all of the issues, but almost all that I checked are one of the above; I don’t really see any where the vulnerability is caused directly by the complexity of sudo or its configuration; it’s just that running anything as root is tricky: setuid returns 432 results, three times that of sudo, and I don’t think that anyone can argue that setuid is complex or that setuid implementations have been riddled with security bugs.

                                                                                  Other just mention sudo in passing by the way; this one is really about an unrelated remote exec vulnerability, and just mentions “If QCMAP_CLI can be run via sudo or setuid, this also allows elevating privileges to root”. And this one isn’t even about sudo at all, but about a “sudo mode” plugin for TYPO3, presumably to allow TYPO3 users some admin capabilities without giving away the admin password. And who knows why this one is even returned in a search for “sudo” as it’s not mentioned anywhere.

                                                                                  1. 3

                                                                                    it’s just that running anything as root is tricky: setuid returns 432 results, three times that of sudo

                                                                                    This is comparing apples to oranges. setuid affects many programs, so obviously it would have more results than a single program would. If you’re going to attack my numbers than at least run the same logic over your own.

                                                                                    1. 2

                                                                                      It is comparing apples to apples, because many of the CVEs are about other program’s improper sudo usage, similar to improper/insecure setuid usage.

                                                                                      1. 2

                                                                                        Well, whatever we’re comparing, it’s not making much sense.

                                                                                        1. If sudo is hard to use and that leads to security problems through its misusage, that’s sudo’s fault. Or do you think that the footguns in C are not C’s fault, either? I thought you liked Rust for that very reason. For this reason the original CVE count stands.
                                                                                        2. But fine, let’s move on on the presumption that the original CVE count is not appropriate to use here, and instead reference your list of 39 Ubuntu vulnerabilities. 39 > 2, Q.E.D. At this point we are comparing programs to programs.
                                                                                        3. You now want to compare this with 432 setuid results. You are comparing programs with APIs. Apples to oranges.

                                                                                        But, if you’re trying to bring this back and compare it with my 140 CVE number, it’s still pretty damning for sudo. setuid is an essential and basic feature of Unix, which cannot be made any smaller than it already is without sacrificing its essential nature. It’s required for thousands of programs to carry out their basic premise, including both sudo and doas! sudo, on the other hand, can be made much simpler and still address its most common use-cases, as demonstrated by doas’s evident utility. It also has a much smaller exposure: one non-standard tool written in the 80’s and shunted along the timeline of Unix history every since, compared to a standardized Unix feature introduced by DMR himself in the early 70’s. And setuid somehow has only 4x the number of footgun incidents? sudo could do a hell of a lot better, and it can do so by trimming the fat - a lot of it.

                                                                                        1. 3

                                                                                          If sudo is hard to use and that leads to security problems through its misusage, that’s sudo’s fault.

                                                                                          It’s not because it’s hard to use, it’s just that its usage can escalate other more (relatively) benign security problems, just like setuid can. This is my point, as a reply to stephank’s comment. This is inherent to running anything as root, with setuid, sudo, or doas, and why we have capabilities on Linux now. I bet that if doas would be the default instead of sudo we’d have a bunch of CVEs about improper doas usage now, because people do stupid things like allowing anyone to run anything without password and then write a shitty web UI in front of that. That particular problem is not doas’s (or sudo’s) fault, just as cutting myself with the kitchen knife isn’t the knife’s fault.

                                                                                          reference your list of 39 Ubuntu vulnerabilities. 39 > 2, Q.E.D.

                                                                                          Yes, sudo has had more issues in total; I never said it doesn’t. It’s just a lot lower than what you said, and quite a number are very low-impact, so I just disputed the implication that sudo is a security nightmare waiting to happen: it’s track record isn’t all that bad. As always, more features come with more (security) bugs, but use cases do need solving somehow. As I mentioned, it’s a trade-off.

                                                                                          sudo, on the other hand, can be made much simpler and still address its most common use-cases, as demonstrated by doas’s evident utility

                                                                                          We already agreed on this yesterday on HN, which I repeated here as well; all I’m adding is “but sudo is still useful, as it solves many more use cases” and “sudo isn’t that bad”.

                                                                                          Interesting thing to note: sudo was removed from OpenBSD by millert@openbsd.org; who is also the sudo maintainer. I think he’ll agree that “sudo is too complex for it to the default”, which we already agree on, but not that sudo is “too complex to exist”, which is where we don’t agree.

                                                                                          Could sudo be simpler or better architectured to contain its complexity? Maybe. I haven’t looked at the source or use cases in-depth, and I’m not really qualified to make this judgement.

                                                                                  2. 5

                                                                                    I think arguing against complexity is one of the core principles of UNIX philosophy, and it’s gotten us quite far on the operating system front.

                                                                                    If simplicity was used in sudo, this particular vulnerability would not have been possible to trigger it: why have sudoedit in the first place, which just implies the -e flag? This statement is a guarantee.

                                                                                    If it would’ve ditched C, there is no guarantee that this issue wouldn’t have happened.

                                                                                  3. 2

                                                                                    Did you even look at that list? Most of those are not sudo vulnerabilities but issues in sudo configurations distros ship with.

                                                                                    If even the distros can’t understand the configuration well enough to get it right, what hope do I have?

                                                                                  4. 16

                                                                                    OK maybe here’s a more specific discussion point:

                                                                                    There can be logic bugs in basically any language, of course. However, the following classes of bugs tend to be steps in major exploits:

                                                                                    • Bounds checking issues on arrays
                                                                                    • Messing around with C strings at an extremely low level

                                                                                    It is hard to deny that, in a universe where nobody ever messed up those two points, there are a lot less nasty exploits in the world in systems software in particular.

                                                                                    Many other toolchains have decided to make the above two issues almost non-existent through various techniques. A bunch of old C code doesn’t handle this. Is there not something that can be done here to get the same productivity and safety advantages found in almost every other toolchain for tools that form the foundation of operating computers? Including a new C standard or something?

                                                                                    I can have a bunch of spaghetti code in Python, but turning that spaghetti into “oh wow argv contents ran over some other variables and messed up the internal state machine” is a uniquely C problem, but if everyone else can find solutions, I feel like C could as well (including introducing new mechanisms to the language. We are not bound by what is printed in some 40-year-old books, and #ifdef is a thing).

                                                                                    EDIT: forgot to mention this, I do think that sudo is a bit special given that its default job is to take argv contents and run them. I kinda agree that sudo is a bit special in terms of exploitability. But hey, the logic bugs by themselves weren’t enough to trigger the bug. When you have a multi-step exploit, anything on the path getting stopped is sufficient, right?

                                                                                    1. 14

                                                                                      +1. Lost in the noise of “but not all CVEs…” is the simple fact that this CVE comes from an embarrassing C string fuckup that would be impossible, or at least caught by static analysis, or at very least caught at runtime, in most other languages. If “RWIIR” is flame bait, then how about “RWIIP” or at least “RWIIC++”?

                                                                                      1. 1

                                                                                        I be confused… what does the P in RWIIP mean?

                                                                                        1. 3

                                                                                          Pascal?

                                                                                          1. 1

                                                                                            Python? Perl? Prolog? PL/I?

                                                                                          2. 2

                                                                                            Probably Python, given the content of the comment by @rtpg. Python is also memory-safe, while it’s unclear to me whether Pascal is (a quick search reveals that at least FreePascal is not memory-safe).

                                                                                            Were it not for the relative (accidental, non-feature-providing) complexity of Python to C, I would support RWIIP. Perhaps Lua would be a better choice - it has a tiny memory and disk footprint while also being memory-safe.

                                                                                            1. 2

                                                                                              Probably Python, given the content of the comment by @rtpg. Python is also memory-safe, while it’s unclear to me whether Pascal is (a quick search reveals that at least FreePascal is not memory-safe).

                                                                                              That’s possibly it.

                                                                                              Perhaps Lua would be a better choice - it has a tiny memory and disk footprint while also being memory-safe.

                                                                                              Not to mention that Lua – even when used without LuaJIT – is simply blazingly fast compared to other scripting languages (Python, Perl, &c)!

                                                                                              For instance, see this benchmark I did sometime ago: https://0x0.st/--3s.txt. I had implemented Ackermann’s function in various languages (the “./ack” file is the one in C) to get a rough idea on their execution speed, and lo and behold Lua turned out to be second only to the C implementation.

                                                                                      2. 15

                                                                                        I agree that rewriting things in Rust is not always the answer, and I also agree that simpler software makes for more secure software. However, I think it is disingenuous to compare the overall CVE count for the two programs. Would you agree that sudo is much more widely installed than doas (and therefore is a larger target for security researchers)? Additionally, most of the 140 CVEs linked were filed before October 2015, which is when doas was released. Finally, some of the linked CVEs aren’t even related to code vulnerabilities in sudo, such as the six Quest DR Series Disk Backup CVEs (example).

                                                                                        1. 4

                                                                                          I would agree that sudo has a bigger target painted on its back, but it’s also important to acknowledge that it has a much bigger back - 100× bigger. However, I think the comparison is fair. doas is the default in OpenBSD and very common in NetBSD and FreeBSD systems as well, which are at the heart of a lot of high-value operations. I think it’s over the threshold where we can consider it a high-value target for exploitation. We can also consider the kinds of vulnerabilities which have occured internally within each project, without comparing their quantity to one another, to characterize the sorts of vulnerabilities which are common to each project, and ascertain something interesting while still accounting for differences in prominence. Finally, there’s also a bias in the other direction: doas is a much simpler tool, shipped by a team famed for its security prowess. Might this not dissuade it as a target for security researchers just as much?

                                                                                          Bonus: if for some reason we believed that doas was likely to be vulnerable, we could conduct a thorough audit on its 500-some lines of code in an hour or two. What would the same process look like for sudo?

                                                                                        2. 10

                                                                                          So you’re saying that 50% of the CVEs in doas would have been prevented by writing it in Rust? Seems like a good reason to write it in Rust.

                                                                                          1. 11

                                                                                            Another missing point is that Rust is only one of many memory safe languages. Sudo doesn’t need to be particularly performant or free of garbage collection pauses. It could be written in your favorite GCed language like Go, Java, Scheme, Haskell, etc. Literally any memory safe language would be better than C for something security-critical like sudo, whether we are trying to build a featureful complex version like sudo or a simpler one like doas.

                                                                                            1. 2

                                                                                              Indeed. And you know, Unix in some ways have been doing this for years anyway with Perl, python and shell scripts.

                                                                                              1. 2

                                                                                                I’m not a security expert, so I’m be happy to be corrected, but if I remember correctly, using secrets safely in a garbage collected language is not trivial. Once you’ve finished working with some secret, you don’t necessarily know how long it will remain in memory before it’s garbage collected, or whether it will be securely deleted or just ‘deallocated’ and left in RAM for the next program to read. There are ways around this, such as falling back to manual memory control for sensitive data, but as I say, it’s not trivial.

                                                                                                1. 2

                                                                                                  That is true, but you could also do the secrets handling in a small library written in C or Rust and FFI with that, while the rest of your bog-standard logic not beholden to the issues that habitually plague every non-trivial C codebase.

                                                                                                  1. 2

                                                                                                    Agreed.

                                                                                                    Besides these capabilities, ideally a language would also have ways of expressing important security properties of code. For example, ways to specify that a certain piece of data is secret and ensure that it can’t escape and is properly overwritten when going out of scope instead of simply being dropped, and ways to specify a requirement for certain code to use constant time to prevent timing side channels. Some languages are starting to include things like these.

                                                                                                    Meanwhile when you try to write code with these invariants in, say, C, the compiler might optimize these desired constraints away (overwriting secrets is a dead store that can be eliminated, the password checker can abort early when the Nth character of the hash is wrong, etc) because there is no way to actually express those invariants in the language. So I understand that some of these security-critical things are written in inline assembly to prevent these problems.

                                                                                                    1. 1

                                                                                                      overwriting secrets is a dead store that can be eliminated

                                                                                                      I believe that explicit_bzero(3) largely solves this particular issue in C.

                                                                                                      1. 1

                                                                                                        Ah, yes, thanks!

                                                                                                        It looks like it was added to glibc in 2017. I’m not sure if I haven’t looked at this since then, if the resources I was reading were just not up to date, or if I just forgot about this function.

                                                                                            2. 8

                                                                                              I do think high complexity is the source of many problems in sudo and that doas is a great alternative to avoid many of those issues.

                                                                                              I also think sudo will continue being used by many people regardless. If somebody is willing to write an implementation in Rust which might be just as complex but ensures some level of safety, I don’t see why that wouldn’t be an appropriate solution to reducing the attack surface. I certainly don’t see why we should avoid discussing Rust just because an alternative to sudo exists.

                                                                                              1. 2

                                                                                                Talking about Rust as an alternative is missing the forest for the memes. Rust is a viral language (in the sense of internet virality), and a brain worm that makes us all want to talk about it. But in actual fact, C is not the main reason why anything is broken - complexity is. We could get much more robust and reliable software if we focused on complexity, but instead everyone wants to talk about fucking Rust. Rust has its own share of problems, chief among them its astronomical complexity. Rust is not a moral imperative, and not even the best way of solving these problems, but it does have a viral meme status which means that anyone who sees through its bullshit has to proactively fend off the mob.

                                                                                                1. 32

                                                                                                  But in actual fact, C is not the main reason why anything is broken - complexity is.

                                                                                                  Offering opinions as facts. The irony of going on to talk about seeing through bullshit.

                                                                                                  1. 21

                                                                                                    I don’t understand why you hate Rust so much but it seems as irrational as people’s love for it. Rust’s main value proposition is that it allows you to write more complex software that has fewer bugs, and your point is that this is irrelevant because the software should just be less complex. Well I have news for you, software is not going to lose any of its complexity. That’s because we want software to do stuff, the less stuff it does the less useful it becomes, or you have to replace one tool with two tools. The ecosystem hasn’t actually become less complex when you do that, you’re just dividing the code base into two chunks that don’t really do what you want. I don’t know why you hate Rust so much to warrant posting anywhere the discussion might come up, but I would suggest if you truly cannot stand it that you use some of your non-complex software to filter out related keywords in your web browser.

                                                                                                    1. 4

                                                                                                      Agree with what you’ve wrote, but just to pick at a theme that’s bothering me on this thread…

                                                                                                      I don’t understand why you hate Rust so much but it seems as irrational as people’s love for it.

                                                                                                      This is obviously very subjective, and everything below is anecdotal, but I don’t agree with this equivalence.

                                                                                                      In my own experience, everyone I’ve met who “loves” or is at least excited about rust seems to feel so for pretty rational reasons: they find the tech interesting (borrow checking, safety, ML-inspired type system), or they enjoy the community (excellent documentation, lots of development, lots of online community). Or maybe it’s their first foray into open source, and they find that gratifying for a number of reasons. I’ve learned from some of these people, and appreciate the passion for what they’re doing. Not to say they don’t exist, but I haven’t really seen anyone “irrationally” enjoy rust - what would that mean? I’ve seen floating around a certain spiteful narrative of the rust developer as some sort of zealous online persona that engages in magical thinking around the things rust can do for them, but I haven’t really seen this type of less-than-critical advocacy any more for rust than I have seen for other technologies.

                                                                                                      On the other hand I’ve definitely seen solid critiques of rust in terms of certain algorithms being tricky to express within the constraints of the borrow checker, and I’ve also seen solid pushback against some of the guarantees that didn’t hold up in specific cases, and to me that all obviously falls well within the bounds of “rational”. But I do see a fair amount of emotionally charged language leveled against not just rust (i.e. “bullshit” above) but the rust community as well (“the mob”), and I don’t understand what that’s aiming to accomplish.

                                                                                                      1. 3

                                                                                                        I agree with you, and I apologize if it came across that I think rust lovers are irrational - I for one am a huge rust proselytizer. I intended for the irrationality I mentioned to be the perceived irrationality DD attributes to the rust community

                                                                                                        1. 2

                                                                                                          Definitely no apology needed, and to be clear I think the rust bashing was coming from elsewhere, I just felt like calling it to light on a less charged comment.

                                                                                                        2. 1

                                                                                                          I think the criticism isn’t so much that people are irrational in their fondness of Rust, but rather that there are some people who are overly zealous in their proselytizing, as well as a certain disdain for everyone who is not yet using Rust.

                                                                                                          Here’s an example comment from the HN thread on this:

                                                                                                          Another question is who wants to maintain four decades old GNU C soup? It was written at a different time, with different best practices.

                                                                                                          In some point someone will rewrite all GNU/UNIX user land in modern Rust or similar and save the day. Until this happens these kind of incidents will happen yearly.

                                                                                                          There are a lot of things to say about this comment, and it’s entirely false IMO, but it’s not exactly a nice comment, and why Rust? Why not Go? Or Python? Or Zig? Or something else.

                                                                                                          Here’s another one:

                                                                                                          Rust is modernized C. You are looking for something that already exists. If C programmers would be looking for tools to help catch bugs like this and a better culture of testing and accountability they would be using Rust.

                                                                                                          The disdain is palatable in this one, and “Rust is modernized C” really misses the mark IMO; Rust has a vastly different approach. You can consider this a good or bad thing, but it’s really not the only approach towards memory-safe programming languages.


                                                                                                          Of course this is not representative for the entire community; there are plenty of Rust people that I like and have considerably more nuanced views – which are also expressed in that HN thread – but these comments certainly are frequent enough to give a somewhat unpleasant taste.

                                                                                                        3. 2

                                                                                                          While I don’t approve of the deliberately inflammatory form of the comments, and don’t agree with the general statement that all complexity is eliminateable, I personally agree that, in this particular case, simplicity > Rust.

                                                                                                          As a thought experiment, world 1 uses sudo-rs as a default implementation of sudo, while world 2 uses 500 lines of C which is doas. I do think that world 2 would be generally more secure. Sure, it’ll have more segfaults, but fewer logical bugs.

                                                                                                          I also think that the vast majority of world 2 populace wouldn’t notice the absence of advanced sudo features. To be clear, the small fraction that needs those features would have to install sudo, and they’ll use the less tested implementation, so they will be less secure. But that would be more than offset by improved security of all the rest.

                                                                                                          Adding a feature to a program always has a cost for those who don’t use this feature. If the feature is obscure, it might be overall more beneficial to have a simple version which is used by the 90% of the people, and a complex for the rest 10%. The 10% would be significantly worse off in comparison to the unified program. The 90% would be slightly better off. But 90% >> 10%.

                                                                                                          1. 2

                                                                                                            Rust’s main value proposition is that it allows you to write more complex software that has fewer bugs

                                                                                                            I argue that it’s actually that it allows you to write fast software with fewer bugs. I’m not entirely convinced that Rust allows you to manage complexity better than, say, Common Lisp.

                                                                                                            That’s because we want software to do stuff, the less stuff it does the less useful it becomes

                                                                                                            Exactly. Software is written for people to use. (technically, only some software - other software (such as demoscenes) is written for the beauty of it, or the enjoyment of the programmer; but in this discussion we only care about the former)

                                                                                                            The ecosystem hasn’t actually become less complex when you do that

                                                                                                            Even worse - it becomes more complex. Now that you have two tools, you have two userbases, two websites, two source repositories, two APIs, two sets of file formats, two packages, and more. If the designs of the tools begin to differ substantially, you have significantly more ecosystem complexity.

                                                                                                            1. 2

                                                                                                              You’re right about Rust value proposition, I should have added performance to that sentence. Or, I should have just said managed language, because as another commenter pointed out Rust is almost irrelevant to this whole conversation when it comes to preventing these type of CVEs

                                                                                                            2. 1

                                                                                                              The other issue is that it is a huge violation of principle of least privilege. Those other features are fine, but do they really need to be running as root?

                                                                                                        4. 7

                                                                                                          Just to add to that: In addition to having already far too much complexity, it seems the sudo developers have a tendency to add even more features: https://computingforgeeks.com/better-secure-new-sudo-release/

                                                                                                          Plugins, integrated log server, TLS support… none of that are things I’d want in a tool that should be simple and is installed as suid root.

                                                                                                          (Though I don’t think complexity vs. memory safety are necessarily opposed solutions. You could easily imagine a sudo-alike too that is written in rust and does not come with unnecessary complexity.)

                                                                                                          1. 4

                                                                                                            What’s wrong with EBNF and how is it related to security? I guess you think EBNF is something the user shouldn’t need to concern themselves with?

                                                                                                            1. 6

                                                                                                              There’s nothing wrong with EBNF, but there is something wrong with relying on it to explain an end-user-facing domain-specific configuration file format for a single application. It speaks to the greater underlying complexity, which is the point I’m making here. Also, if you ever have to warn your users not to despair when reading your docs, you should probably course correct instead.

                                                                                                              1. 2

                                                                                                                Rewrite: The point that you made in your original comment is that sudo has too many features (disguising it as a point about complexity). The manpage snippet that you’re referring to has nothing to do with features - it’s a mix between (1) the manpage being written poorly and (2) a bad choice of configuration file format resulting in accidental complexity increase (with no additional features added).

                                                                                                              2. 1

                                                                                                                EBNF as a concept aside; the sudoers manpage is terrible.

                                                                                                              3. 3

                                                                                                                Hello, I am here to derail the Rust discussion before it gets started.

                                                                                                                I am not sure what you are trying to say, let me guess with runaway complexity.

                                                                                                                • UNIX is inherently insecure and it cannot be made secure by any means
                                                                                                                • sudo is inherently insecure and it cannot be made secure by any means

                                                                                                                Something else maybe?

                                                                                                                1. 4

                                                                                                                  Technically I agree with both, though my arguments for the former are most decidedly off-topic.

                                                                                                                  1. 5

                                                                                                                    Taking Drew’s statement at face value: There’s about to be another protracted, pointless argument about rewriting things in rust, and he’d prefer to talk about something more practically useful?

                                                                                                                    1. 7

                                                                                                                      I don’t understand why you would care about preventing a protracted, pointless argument on the internet. Seems to me like trying to nail jello to a tree.

                                                                                                                  2. 3

                                                                                                                    This is a great opportunity to promote doas. I use it everywhere these days, and though I don’t consider myself any sort of Unix philosophy purist, it’s a good example of “do one thing well”. I’ll call out Ted Unangst for making great software. Another example is signify. Compared to other signing solutions, there is much less complexity, much less attack surface, and a far shallower learning curve.

                                                                                                                    I’m also a fan of tinyssh. It has almost no knobs to twiddle, making it hard to misconfigure. This is what I want in security-critical software.

                                                                                                                    Relevant link: Features Are Faults.

                                                                                                                    All of the above is orthogonal to choice of implementation language. You might have gotten a better response in the thread by praising doas and leaving iron oxide out of the discussion. ‘Tis better to draw flies with honey than with vinegar. Instead, you stirred up the hornets’ nest by preemptively attacking Rust.

                                                                                                                    PS. I’m a fan of your work, especially Sourcehut. I’m not starting from a place of hostility.

                                                                                                                    1. 3

                                                                                                                      If you want programs to be more secure, stable, and reliable, the key metric to address is complexity. Rewriting it in Rust is not the main concern.

                                                                                                                      Why can’t we have the best of both worlds? Essentially a program copying the simplicity of doas, but written in Rust.

                                                                                                                      1. 2

                                                                                                                        Note that both sudo and doas originated in OpenBSD. :)

                                                                                                                        1. 9

                                                                                                                          Got a source for the former? I’m pretty sure sudo well pre-dates OpenBSD.

                                                                                                                          Sudo was first conceived and implemented by Bob Coggeshall and Cliff Spencer around 1980 at the Department of Computer Science at SUNY/Buffalo. It ran on a VAX-11/750 running 4.1BSD. An updated version, credited to Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso and Don Gworek, was posted to the net.sources Usenet newsgroup in December of 1985.

                                                                                                                          The current maintainer is also an OpenBSD contributor, but he started maintaining sudo in the early 90s, before OpenBSD forked from NetBSD. I don’t know when he started contributing to OpenBSD.

                                                                                                                          So I don’t think it’s fair to say that sudo originated in OpenBSD :)

                                                                                                                          1. 1

                                                                                                                            Ah, looks like I was incorrect. I misinterpreted OpenBSD’s innovations page. Thanks for the clarification!