Hacker News Reader

Comment by dataangel | Hacker News Reader

I find this research to be both ethical and necessary, and I think kernel devs decrying it as wasting their time are missing the point. They demonstrated the whole "with enough eyes all bugs are shallow" security model doesn't really work. If some of the best devs out there fall for bad patches, it can happen to any OSS project (and for that matter for prop code bases too, but there you at least have to go through the hurdle of being hired before your code is considered).

View on HN

In which line of work or venue could a competent person with intentions like these NOT succeed in introducing subtle problems? If there were such a thing where someone could not possibly introduce a problem if they tried, what would that even look like? Certainly not an aspirational open source project. Maybe you couldn't do this with FAA regs or it would take too much time to build up the credibility to "commit code" there, or I guess for an extreme example the US Constitution, but most other things I can think of you can do something like this "study" and achieve similar meaningless results. Yes, people rely on other's goodwill and intentions to some degree when collaborating.

> Maybe you couldn't do this with […] for an extreme example the US Constitution,

The Eighteenth Amendment says hello.

Preventing the introduction of subtle bugs when making changes to a complex system is hard, even disregarding intent. I'd say it's easier to catch deliberately-malicious patches, because easy-to-predict failures are the easiest to catch.

Every law has subtle problems. This is about introducing subtle but serious and exploitable issues on purpose, and I wouldn't say the eighteenth amendment is anywhere near that territory.

Well, there's another example. It was deliberately exploited by other lawmakers, but I imagine the original issue was probably accidental.

The thirteenth amendment, while intended to abolish slavery, actually rendered state-sanctioned slavery explicitly constitutional (albeit, with extra steps); e.g. the Black Codes in certain states prohibited “vagrancy”, which (afaik) basically let them enslave anyone they could get a jury to agree wasn't “contributing to society” via “gainful employment”. This lead to the fourteenth amendment trying to patch this issue – not by forbidding slavery as punishment for a crime, but by requiring “equal protection”: in essence, states couldn't make laws that only applied to certain people.

I don't have any examples of exploitable issues being deliberately introduced to legislation, because generally, people in a position to introduce them don't have to be subtle about it. Perhaps the 11th Congress of the Russian Communist Party's creation of the position of General Secretary was an example, but I don't know if we know what happened there.

Before the thirteenth amendment to the US constitution, §4.2.3 permitted slavery and, arguably, implicitly required its enforcement even by states that outlawed slavery. That might count, seeing as many drafters were anti-slavery, and did not expect this clause to allow the 19th-century resurgence of slavery-powered plantations; whereas other drafters were pro-slavery, and presumably insisted upon this clause's inclusion.

Did you read the report? (<https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/>) Allow me to quote from it:

    Patch 3
    
    First email: Thu, 20 Aug 2020 22:44:57 -0500 (Fri, 21 Aug 2020 03:44:57 UTC)
    First reply: Fri, 21 Aug 2020 11:14:49 +0300 (Fri, 21 Aug 2020 08:14:49 UTC)
     https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com
    
    This patch was quickly recognized by a reviewer to be incorrect, and the
    reviewer offered up possible changes that the submitter could make in
    order to turn it into a correct change.  These suggestions were ignored
    by the submitter and no further changes were submitted in this area.
    
    The maintainer was attempting to mentor an obviously junior contributor,
    taking time to teach the developer what the proper thing to do here
    would be, and what is needed in order to have them create a
    contribution that would be acceptable.  The contributor knew that the
    patch was bad, showing that the researchers were willing to waste the
    resource that is in shortest supply in our community: the time of
    reviewers and maintainers.  Having this waste of an "effort of someone
    trying to teach another" be created by an educational institution was
    especially hurtful to the community and caused many of the bad feelings
    on the community's side, further amplified by not having any idea which
    patches out of the hundreds sent by UMN or from new contributors using
    gmail accounts might be intentionally bad.

    […]

    Summary of "Hypocrite Commits" patch attempts
    
    All patch submissions that were invalid were caught, or ignored, by the
    Linux kernel developers and maintainers.  Our patch-review processes
    worked as intended when confronted with these malicious patches.

As you can see, the time that was wasted was especially valuable, and the research did not demonstrate any such thing.

Why's it necessary? We already know that this method of software development, like all methods, isn't perfect if you pick a short enough timeframe.

Reply on news.ycombinator.com