> They aren't split up, there has never been any effort by you to make them palatable to upstream, and when somebody else dioes try to make them palatable to upstream, you start crying about how people are taking advantage of your work (hah), and try to make them private instead.
...
> It's literally less work for people to re-implement things than look at your mixed-up patches, and YOU SEEM TO BE DOING THAT ON PURPOSE.
> Now, prove me wrong. Start trying to integrate your work upstream, and send individual patches with commit logs that can be integrated.
>You're out of touch with reality Linus. In what world would anyone sign up for your "generous" offer to be called clowns, that their patches are garbage, that they should do thousands of hours of work for free for a bunch of multi-billion dollar corporations that aren't contributing a single dime or any direct work back?
Seems a strange thing to say for a company whose revenue is completely dependent on a product, and it's source code, which they obtain for free, to modify and sell for profit.
Seems like a waste of time for him to hold up that side of the argument. Even if he's 100% correct, what's he going to achieve? The changes aren't going into the kernel until they get past Linus, and for that to happen the patches need to meet the same standards as every other patch. It's not like he's going to lower the bar for one company.
> Even if he's 100% correct, what's he going to achieve? The changes aren't going into the kernel until they get past Linus
You are incorrectly assuming grsec guy wants the changes[1] in the mainline Linux kernel - this would destroy a huge fraction of the value proposition. In a follow-up message, Linus directly challenged them on how they intentionally make their patches hard to upstream (and how they complain about 'leeching' if someone does attempt to upstream - talk about lack of self-awareness).
1. He might not mind old changes, but the quicker the new patches get upstreamed, the less valuable the patchset becomes for their paying clients
Same goes for Linus though. The "best" he can achieve is maybe stopping people from getting patches from grsecurity, which isn't a very productive use of his time either. Relations between these two camps have been poisoned long ago, unless someone with a budget decides it's worth paying grsecurity to help patch the mainline kernel I don't expect any change, and even then I wouldn't be surprised if that project fails.
Note: this is a lot tamer than a lot of the stuff I've seen him post in lwn.net comments.
I have a lot of respect for their work. It's just a shame that their toxic communications will make the good things they do so much less likely to be widely adopted.
/u/mikemol in the reddit thread has a theory behind the contradiction:
> I've no doubt Brad is smart, but the play reads like an attempt at a Xanatos Gambits where he technically makes his fixes public, but deliberately keeps them tough to use, so his competitors get horrid press if they don't use the fixes, but have to expend more resources than necessary in order to use them, furthering his market posture.
Excuse typos from phone...A quote from Randy pausch (0) last lecture(1)
"And he put his arm around my shoulders and we went for a little walk and he said, Randy, it’s such a shame that people perceive you as so arrogant. Because it’s going to limit what you’re going to be able to accomplish in life. What a hell of a way to word “you’re being a jerk.” [laughter] Right? He doesn’t say you’re a jerk. He says people are perceiving you this way and he says the downside is it’s going to limit what you’re going to be able to accomplish.
the situation here is a mentor told this to Randy. In that context, this conversation probably has more of an effect. in any situation I think the lesson still applies, a person will be limited if they continue their behavior no matter how much success they have, they could have accomplished more if they had dropped the attitude problem.
> it’s going to limit what you’re going to be able to accomplish in life...
Sure. But the counter point is that it is also going to limit what you can learn (and hence achieve) if you are only willing to take lessons wrapped in fancy paper..
the last lecture is a good lecture Randy Pausch gave after being diagnosed with pancreatic cancer at Carnegie Mellon University, check the video out, I first watched it while in college and found it inspirational
what my point was here, is in this situation I think it is difficult to argue if Linus (And our IT community at large) had more of an attitude like the 'Lucky Ten Thousand' [0] not only would I think that have a much more positive effect on our code, it would in all aspects of technology and culture. yes you can easily have success with arrogance (I certainly have the problem every once in awhile albeit I usually vent when alone not at others unless it was started by someone else) that is not the point, the success could have been bigger and better if people worked together. personally I would like to see true open source GNU/source-phone(pardon the name) installation on smartphones so we stop having to sell our souls to apple/google/other major player and see solutions like that could be obtained with more cooperation and well reasoned and calm debate rather than inflammatory remarks.
##this part is a rant and can be safely ignored.
just to add one more note, compare reddit and HN. I think you will find people solving more complex issues and having more elegant solutions and discussion on here rather than Reddit... I find it is unfortunate that we sitll need to censor ourselves here because there are some topics that generate very emotional responses (my opinion) rather than being able to have constructive conversations, in order to keep the beauty we have here we have had to self sensor some topics and that makes me sad, I love this community and the discussions we have here, but if we cannot figure out a framework to have healthy debates about taboo topics, how can we expect others? I realize that is an elitest comment but there are a lot of smart people here and we still struggle.
Sure. But sometime, you can take away only that. but the loss will be all yours.
I mean, somebody can give you a block on gold unpolished and unwrapped. Sure, you can say, "How dare you give me that gold unwrapped! There is no way I am taking it. I demand you give that wrapped up property in fancy paper and tied with a ribbon." Sure you can say that. But the loss will be all yours. You got the shit anyway and gained no gold...
So the point is, if it the speaker who has to gain something by getting their point across, sure. They will have to be diplomatic. But when someone, halfway across the world is teaching you something from their ridiculously singular experience, seemingly in a rude way...
I'm not sure gold is the right analogy in this case.. I think that is holding grsecurity's work in higher esteem than is necessary. Don't forget, the code is just part of the work. Ones attitude in contributing that code is another large part of what makes the work "gold".
A better analogy might person A be handing person B back an improvement on person B's own recipe. However, the improvement is written on a piece of paper drenched in piss.
Don't forget, the entire reason grsecurity is able to exist at all is because the Linux kernel is open source and because countless of volunteers and companies have dedicated their time and energy doing exactly what grsecurity fails to do, contributing back in a manner which makes live livable for the maintainers. Each and every one of them could've decided to not bother properly splitting up patches, to not bother documenting their changes properly, and they personally wouldn't have been worse off in a lot of cases. However, because they decided to use proper communication skills (eg. not be a dick), everyone wins.
I think the gold in the parent's analogy is Linus's criticism. And people want it wrapped up in kinder words.
> Ones attitude in contributing that code is another large part of what makes the work "gold".
Even if the analogy meant we were talking about the code being the gold, this wouldn't make sense. The machine only executes code, regardless of the attitude of who wrote it.
I don't think so. If you read uhhfcuvv's post it is about "the other guy", to which Diederich replies and speaks about the "toxic communication", to which babyrainbow seems to take offense.
> Just like you spend your time focusing on versions of Linux nobody actually uses (they use stable kernels or distro kernels) but which benefits your corporate sponsors and maintains the churn you want to force everyone to contribute to. The days of Linux being a community project are long gone, it's a fairy tale at this point.
Clearly a load of crap. I think they should quit being spicy and think about what they should be doing instead.
The grsecurity team does have some valid criticisms of the upstream community, and of course they've done some brilliant technical work, but spender is unfortunately a pretty toxic community member who puts many upstream kernel devs to shame when it comes to ability to flame.
It's a shame - there's a lot of good stuff in grsec/PaX, but I think the upstream community is better off without the people involved. The KSPP effort to upstream grsec/PaX features is, of course, a good thing.
[disclaimer: upstream developer who lurks on kernel-hardening]
Similarly, I used to run grsec on RedHat once upon a time. But the whole thing just got too hard. When a critical update came, I could get a stock kernel running "yum update", or I could play around building a whole new grsec kernel.
I wish there was a way to take personalities out of this and let mainline merge the useful parts of grsec.
Grsecurity creates patches for issues in upstream, but their patches are too fucking big/ugly, so nobody upstream really wants to merge them, and when someone tries to fix em (take the important bits out), grsecurity complains about them using their work.
Grsecurity then say they don't feel like doing a lot of work on their patches when they're not paid to do it.
Along with that Grsec then says that if while the patch is GPLv2 if you distribute them they'll never let you subscribe again to get the patch in the future.
That's a pretty interesting loophole in the GPL: apparently (at least with V2), it might be fine to impose consequences for exercising your rights while technically giving them to you. It certainly violates the spirit of the GPL even if it doesn't violate the letter.
I'm not sure that your claim about where the line is holds up: the GPLv2 never requires you to give your source to anyone unless you first give them binaries. That's why web sites don't have to give out their sources to everyone who visits their site if they use a GPL library for instance.
In any case, if what you say is correct, the grsecurity team are still trying to hold the threat of a more annoying experience over their users in order up prevent them from exercising their rights under the GPLv2.
Grsecurity wouldn't exist if Linux made security a priority. It doesn't, because backwards compatibility and features is more important to them. It doesn't mean because Linus says something so strongly on a subject is right or wrong, he is generally abusive and rants and has for years.
Grsecurity is important to some people, not all, and vice versa for the features and backwards compatibility crowd.
Personally I'd hope someone in Linus position would see both sides of the fence, but he doesn't and always has some mouthy outrageous opinion. So this is zero surprise.
To be even weakly fair, access is a component of security. If their patches break software, they would be breaking someone's security.
That is, backwards compatibility deserves that high bar. Ideally, you could get security without breaking things. If you can't, at least use care and take incremental steps to get things in.
If backwards compatibility is broken, what you wind up with is a subsection of users that out of necessity use versions of linux with none of the updates that secure the product. You can't just tack on security patches that break user-required features willy-nilly, there's a big cost paid here.
Some evidence in favor is that, at least in the early days of Linux, Microsoft took the same strategy of prioritizing backwards compatibility over security - and reaped the rewards by becoming extremely popular and extremely full of security holes. So clearly the strategy worked for MS. On the other hand, MS did respond and prioritize security, and was able to pull it off without compromising backwards compatibility too much. (For instance, last week's stack-clash vulnerability straight up doesn't exist on Windows because MSVC and the NT kernel have been doing the right thing with stack probes for years.)
But some real evidence against is that this whole backwards-compatibility thing is a kernel policy, not a userspace policy; no distro cares nearly as much. With the a.out to ELF transition and libc5 to libc6 transition back in the day, and to this day with OpenSSL versions, the GCC 5 libstdc++ ABI change, etc., there's not a ton of backwards compatibility in what binaries you can actually run on a real-world Linux system. It seems hard to believe that the kernel-to-userspace compatibility story is what made Linux popular, given the vast amount of userspace-to-other-userspace incompatibility.
I don't think it's "very" strong. It might just be "strong".
Rehashing MS's 90s-00s history of prioritizing security creates an unfair assumed comparison. Linux doesn't get to control userland the way MS does. I don't want to belittle MS's efforts, but the attack vector is a lot smaller in NT. Linux has way more features and use cases than the NT kernel ever has (maybe by an order of magnitude). We also don't have the complete picture on NT because of the source being closed.
> With the a.out to ELF transition and libc5 to libc6 transition back in the day, and to this day with OpenSSL versions, the GCC 5 libstdc++ ABI change, etc
You need to remember that Linux's use cases are way bigger than being able to build C binaries and stay forward with SSL. It's easy to forget, but Linux is hardly just servers, they are probably the biggest embedded foot print outside the no-OS or RTOS space, tons non-PC peripheral and consumer electronic applications. You're calling out one set of features that a huge swath of Linux consumers probably never touched for a decade (remember its only been recently that embedded applications have communicated over a network, or had to do so securely).
For all his unfortunate abrasiveness one strength of Linus is and has always been his capacity to see the big picture, e.g. that usually compatibility/API,ABI stability/performances trumps extreme security measures and also he has always been able to accomodate with big players/corps in the industry.
I kind of find Linus refreshing, although I'm not sure that would survive working directly with him. I think you're begging the question though: surely compatibility/ABI stability/performance trumps extreme security (for some values of 'extreme') for people and in cases where that is true. I happen to agree with you and Linus on this (baring a known exploit of an unpatched security bug), but that heirarchy is nowhere engraven in stone. If I always recompiled a critical codebase, I wouldn't care as much about ABI compatibility. If I'm always targetting a very specific platform, I don't care about compatibility. If I'm sitting on millions of unused cycles in a single-threaded realtime environment, I only care about performance to a certain point. If I'm working on software to control a medical device or nuclear reactor, my priorites around extreme security change.
You're right about that priority for the vast majority of the Linux user-base, but that's a characteristic of those users and developers, not of kernel software in general.
I have never even tried to read the kernel source, but I read the mailing lists - quite frequently. Linus runs a tight ship. It is funniest when someone does something that will break userspace.
He sets high standards. Meet them. I don't believe any forks have really done well. His method works, as abrasive as it may appear.
Yeah that may have worked in the past when Linux was barely used by anyone. Now it is on a billion Android phones.
You can see why Google wants to move to its own OS when Linus has that attitude.
Besides, it's bullshit that you can't have ABI stability and security. It feels to me like Linus is still in the "I never write bugs" stage of denial, despite the evidence.
I'm an Arch user and I have no idea what's going on with security-focused kernels these days. I was running the grsecurity kernel package but that was recently replaced by a "linux-hardened" package that I had never heard of. Then, a pacman update tonight installed a plain Linux kernel. It's very confusing. Not unexpected for Arch but there is so little on the wiki about this.
The grsecurity patches have been made private. Although they are under the GPL (because they are a derivative work of the Linux kernel), the company that produces grsecurity engages in the unethical (and potentially illegal) business practice of threatening to terminate customer subscriptions if they exercise their right to distribute the patches.
In other words, no customer is going to distribute the patches because they will have wasted money and lost access to updates. This is very reminiscent of free speech chilling effects, and I'm surprised none of the copyright holders in Linux (myself included) have teamed up to sue them.
Long story short, the general community (including distributions) no longer has access to new patches making grsecurity useless for the community.
> the company that produces grsecurity engages in the unethical (and potentially illegal)
Unethical, probably - illegal, probably not. The GPL dictates what you can do once code hits your hands (or binaries compiled with), it doesn't prevent companies from selling it to you or what contract they do it under.
Sure you can sell it, and under whatever terms you like.
But you have to _also_ provide the full source under the GPL, not under "the GPL with additional constraints".
I'm no lawyer, but I highly doubt it'll hold. And buying Linux from them could be very toxic as "GPL violation" => "termination of license" -- and I'm not sure how you go about getting a new license :)
No, under the GPL you have the right to redistribute the source. You don't have a right to receive new patches or maintain any particular subscription, that is a different consideration that you can maintain in a separate contract.
Of course you can be punished for exercising your rights. There is no better example than free speech: you're free to say whatever you want, and your customers are free to leave in response. The considerations of many contracts include some form of restricting your rights in return for something.
That depends on how you read section 6 of the GPL2. It states in part:
> You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
The central right granted under the GPL is, of course, the right to modify and redistribute the source. I'm not a lawyer, and I'm certain that Grsecurity could find a number of legal arguments that what they're doing is allowed (likely starting with the claim that terminating a relationship with a customer isn't legally imposing a restriction on that customer's actions), but the idea that they're in violation of the GPL isn't pulled from thin air.
The point is if they punish you (such as discontinue business relationship) because you send a request to obtain the source, and exercise the rights you've been granted in the GPL, well, that's an additional restriction.
I'm no lawyer, but the spirit of the law or a contract matters.
You can't avoid a speeding ticket because the wheels of your car wasn't touching the road in the photo :)
Because grsecurity make no effort to separate out their patches, it's really hard to upstream them. Sometimes the Arch team get the effort in time, sometimes its overly difficult so you don't get the kernel rolled out by the time an update is available for plain.
Strong words. Usually when Linus ways in so strongly on a topic he's pretty certain of his take on it-it'll be interesting to see if there's further discussion on both ends.
Wouldn't it be nice if you didn't demand free work of us in our free time? seems an odd line, but is there some context for the non-Linux person on what is going on?
> Wouldn't it be nice if you didn't demand free work of us in our free time? seems an odd line, but is there some context for the non-Linux person on what is going on?
Spender (and PaXTeam) has consistently claimed for many years that although he owns a software company whose sole product is a kernel patchset (and they are the only people who develop that patchset) that all grsecurity work is done in their free time. Which means that nobody (including their paying customers) is paying them for grsecurity development.
This usually comes up when Spender wants to claim that Linux has a lot of money in its development and that it is unreasonable that he, the poor developer he is, should work on upstreaming his patches. Personally it always struck me as dishonest.
I recently had an argument with them about this, which was "fun"[1].
Don't count on this recount to be correct but as far I've followed it:
200x?
- grsecurity patchset is introduced and fixes a lot of bug-classes (!) and introduces lot's of security improvements to the kernel that are ground breaking and find their way in other systems like *BSD / Windows
200x-201x
- code and trademarks of grsecurity get ripped from embbedded vendors - Linux foundations does nothing because they don't pursue GPL violations
- no intent from grsecurity to upstream their work - at least without getting paid for it.
2016-2017:
- Linux foundation founds KSPP and works on integrating basically PaX/grsecurity into mainline - does not even ask grsecurity or PaX if they want to get paid for helping but they are flamed at and bothered with inquiries from devs
- according to grsecurity most of KSPP work is copy&paste the grsecurity code without deeper understanding - introducing even new vulns
- grsecurity only publishes patchset for current mainline kernel, no more long term releases
2017:
- things are escalating, grsecurity patches go dark
- lot's of rants and hate from all sites.
now:
- this mess.
I can see the point from the grsecurity guys - they produced ground breaking research and it got ripped of everywhere and Linux foundation does not protect it's interests because the corporations don't want GPL enforcement (not related to the current dark patchset) and they don't even bother offering them money for the work to integrate this stuff. The bad mouthing from Linus is quite idiotic if you consider that most, if not all kernel vulns did not affect grsecurity in the past years. It's also true that the patchset breaks code depeding on the settings in plenty of ways.
Add lot's of rants and flames, big ego, personal attacks from grsecurity to Linux devs and vice versa...not exactly professional. Not sure what was/is going on beyond that.
At least that's some outsider Twitter/Mailinglist perspective. It's not black and white and IMHO Linux Foundation and KSPP have some explaining to do.
Their groundbreaking research was improvements that were directly derivative of work shipped with a license that said all derivative works must be provided under the same free license they received the work with.
Your tone seems to suggest that some obligation exists that some obligation exists to do more than share the source to any improvements.
This obligation is wholly and totally imaginary. Its as if someone gave another party an entire farm and in the contract specified that he could eat some of the food that grew from it and that someone threw a fit when the first party walked up and made a sandwich.
Seeing as there is no sane and legal way to require anyone to pay for said patches the reasonable way to fund such an effort is to get the community to voluntarily fund such an effort with whatever platform is most useful preferably in advance.
It seems that they have instead chosen to rely on a mixture of manufactured drama, illegal threats, and general unpleasantness to keep their efforts from being well integrated with mainstream. While this remains so they can offer definable value.
In the long run I predict bankruptcy and irrelevance for a company that few care about now and none will care about later.
Yeah, the parent's summary is tripe and implies that the GRSecurity is somehow faultless in the drama they've vehemently instigated time and time again.
I'm having trouble seeing, apart from ignorance or misinformation, why anyone would condone GRSecurity. The code is helpful but you wouldn't want the authors in a position of authority over the operating system of a billion-plus computers.
Right now, most arguments in defense of GRSecurity are simply: "Two sides are arguing, therefore they're both wrong. Aren't I smarter for pointing it out?"
The killed comment on this thread has a line in it that's spectacular in its misunderstanding (or its dishonesty) that needs a brief explanation:
> Their research are in no way 'directly derivative' of the linux kernel. Their implementation was based on linux
This means that it's captured under the GPL, and anyone can do as they like pursuant to the license (which grsecurity has attempted, repeatedly, to constrain in contravention of that license), and that this guy has an a-gen-da and something to sell you.
"2016-2017: - Linux foundation founds KSPP and works on integrating basically PaX/grsecurity into mainline - does not even ask grsecurity or PaX if they want to get paid for helping but they are flamed at and bothered with inquiries from devs - according to grsecurity most of KSPP work is copy&paste the grsecurity code without deeper understanding"
I don't follow this stuff closely, but I believe that the KSPP was started by Kees Cook because other approaches had failed: grsecurity/PaXTeam had been unwilling to cooperate to get their patches upstream for a long time, so the only way to move things forwards for everybody was to re-implement the functionality without PaXTeam.
This is, as I understand it, the core of the thing. They're making derivative works of a GPL work. They don't get to have it both ways. There's nothing for the Linux Foundation to go after, and they wouldn't be able to even if there was because they don't have the copyright for grsecurity's stuff.
Lot's of embedded vendors have plenty of GPL violations - Linksys and Ubiquity for instance in the case of grsecurity it was appearently Wind River. Apparently even no source code even if you purchased a device.
Sure, but--so? grsecurity has the copyright on what they've created. They don't need the Linux Foundation to enforce violations and there's no cause to force the Linux Foundation to do so if they don't feel it's best for Linux; copyright is optionally enforced in most jurisdictions (unlike trademark in the USA). On top of that, you're miffed that the Linux Foundation didn't "ask grsecurity or PaX if they want to get paid for helping", which is orthogonal to everything?
Your posts don't make sense to me, and I've been observing this whole mess for a very long time. What you're saying reads as if the Linux Foundation should be the heavies for a private company that has never-not-once played by the same rules as the cooperative development community they work outside of.
How are the Linux Foundation's funds allocated, and how much say does Linus have in it ? Most of this boils down to lack of money and attribution for grsec. Why didn't the Linux Foundation or Linus try to officially fund grsec to upstream their patches ? KSPP is still costing money. How much would it have cost to pay grsec directly instead ?
As far as I understand that is the opposite of how it works. The linux foundation was set up to receive funds from big business contributors - like Intel, Microsoft etc, who have an interest in the continuation of the linux kernel and wish to pay for jobs which didn't have a source of funding (i.e. Linus's job and other maintainer) and who wished to remain non-partisan. So these companies provide both code and money. That money isn't meant to be kicked back to profit-making companies as far as I understand.
Also, probably because grsec's code doesn't meet the standards. By almost all accounts, it pretty much sucks. I am unqualified to opine, but I trust the opinions of who are qualified - by being the people who try to implement it.
A genuine question: Why isn't it perfectly reasonable to accept to break compatibility in order to increase security? Isn't that what we do in our lifes all the time? When the authorities issue new fire safety regulations for buildings, then that is breaking compatibility to the older building standard. We still do it because there is good reason. Sometimes even old buildings need to be retrofitted, and that is then what is done.
I don't get Linus in this point, and suspect so far that he is wrong, or that I didn't get it yet.
> When the authorities issue new fire safety regulations for buildings, then that is breaking compatibility to the older building standard.
Do the old buildings automagically get updated to the new standard everyone is using? Does the city shut down every business in a building that doesn't match standard (= break software) until that building is retrofitted (which is time-consuming and costly)? That's what breaking backwards compatability does, it stops people from doing their thing until someone fixes it (sometimes it's on them, sometimes it's on you). And not everyone can afford a 'drop everything now to fix the issues brought up by the kernel release'.
In any case, a good way to get people to not use your product is to keep breaking it.
> Sometimes even old buildings need to be retrofitted, and that is then what is done.
Is it? There was a very famous fire in London just a couple of weeks ago, of a building which wasn't up to standard, yet filled with people. Dozens of people died.
The example of the recent fire in London strengthens my point. If we neglect security, then there is a price to pay for it. And now in London they do fix up buildings, because it's what makes sense.
Linux including a breaking change to increase security does not stop any business. If you are not patched to the new version, don't upgrade. The breaking change could be announced well ahead, and people would have time to fix their stuff.
That would be akin to the government releasing a new regulation but not forcing anybody to upgrade directly, but by offering tax relieve to anybody who did.
It is acceptable to break compatibility to fix a security problem, but it needs to be a minimal break. The problem with this particular issue is that it's breaking compatibility with major applications, which is no good.
It is, and he's wrong, and he's usually wrong when security comes up.
See also git using SHA-1: people warned him about this, and he argued passionately and incorrectly that git doesn't use SHA-1 as an integrity measure. He also argued passionately and incorrectly that SHA-1 was unlikely to be broken and worrying about it was a waste of effort. And now other people are doing a lot of slow work to dig ourselves out of literally every single git repo in the world relying on a broken crypto primitive.
Security in git is done by signing tags with GPG. This signs the whole tree state as in all of commit IDs and blobs. To break that, you need to collide a blob hash and commit hash or potentially pack file hash. Much harder than doing it for one file.
(Albeit git used to be lax with its compression allowing garbage at the end.)
It signs the whole tree state, which is a collection of SHA-1 hashes. If I'm interested in introducing a backdoor in an application, I'm basically only interested in colliding the hash of one file; colliding a SHA-1 signature on a file is exactly as hard as colliding the SHA-1 hash of a single file inside a git tree inside a git commit signed with a stronger-than-SHA-1 signature. That is, if I've collided the file's SHA-1 hash, the tree that contains the file is going to have the exact same hash because the tree contains the SHA-1 of the file.
Git is not really using SHA-1 for encryption, just as unique hashes. I think it is unlikely to get a collision in a non-contrived instance. Eventually git will move off of SHA-1, but I imagine it will never matter.
> Git is not really using SHA-1 for encryption, just as unique hashes.
By "encryption" do you mean "cryptography"?
If I sign a git tag, I am signing a data structure that consists of SHA-1 hashes of other data structures. Any attack on SHA-1 means that the thing I'm signing can be subverted.
So, yes, git is using SHA-1 for cryptographic purposes.
> I think it is unlikely to get a collision in a non-contrived instance.
Why do you think this? Usually in engineering we prefer to back up statements like this with evidence.
In particular, practical SHA-1 collisions have been demonstrated: https://shattered.io/
And an attacker is going to be trying to contrive a collision, are they not?
And none of this explains why git didn't use SHA-256 back when it was easy to change. Even if SHA-1 isn't broken in practice (which it is), there's no downside to using SHA-256.
It certainly has been used for encryption and probably still is. I wouldn't lose any sleep hashing my passwords with it since most mortals couldn't break it. https://en.wikipedia.org/wiki/SHA-1#Cryptography
grsecurity, i like it. pretty secure for my machine. never had any breakage...
i think Linus should probarbly pay more attention to security issues in 'his' os instead of being ratty about people taking it in their own hands to fix it...
if u want to know: you can increase the stack guard page for grsecurity too, as theirs is also way small...
On the otherhand i dont see why a kernel doesn't track it's stack pointers and heap allocations to see if there is overlap, its basic idea and stupid that they ever dared to say this is not exploitable. Even though not many ppl seem to have looked at it and/or done it, its plainly obvious there is an issues with there being a possibility of overlap;. The stack guard page is a stupid mechanism which at best causes an application crash (fking handle that shit properly??) masked as 'security incident'....
that being said, linux, grsecurity, still my main choice, still much love for linus and grsecurity folks. whish they could get along better and perhaps someday think of actual solutions instead of infinite bandaids!
After reading the entire exchange between Torvalds and Spengler I must say Torvalds was thoroughly trounced. It was like watching a child argue with an adult. Spengler provided facts, justification, reasoning and proof while Torvalds acted like a child and called him names and his work garbage. If you're going to call someone out then at least have the decency to properly address their reply instead of completely ignoring what they said and just saying what you want to say.
A differently sounding username would have at least helped your case. :)
Even if Windows kernel security is more robust, anybody can easily fault you for some form of cognitive bias. I use Windows, therefore Windows is more superior.
> A differently sounding username would have at least helped your case. :)
No, it wouldn't; it is quite obvious that the account was created by a Linux fanboi just to make this lame ironic joke, and that lame account creation just to make a lame (and off-topic) joke is likely why it was flagged.
This is a very weird post. It's like some kind of sith mind trick. "I'd love to know more, but your name implies a connection to the subject matter and we wouldn't want that chuckle taken the wrong way."
I guess it's not too far from the reality - at least since Windows 10? Windows got a lot of stuff that is better than Linux in that regard. Control flow guard, Device Guard Virtualisation, ALSR - the current stack/heap guard page mess is also solved there. Linux is full of local priv escalation bugs (basically every update fixes one - http://www.cvedetails.com/vulnerability-list/vendor_id-33/pr...)
I'm not going to agree or disagree on this, but Microsoft's choice to shove all syscalls into a DLL where a defined ABI is easier to maintain certainly makes dramatic security improvements to the kernel easier without breaking userspace.
I am indeed. Linux lacks many of the security features and exploit mitigations present in Windows, despite the efforts of contributors such as grsecurity.
There appears to be no overarching strategy in Linux to improve security, it's all rather haphazard.
You're not using the term "crying wolf" correctly[1]. It has a very specific meaning in English, and that is what my complaint is in relation to. No amount of personal derision about how I "lack the level of abstraction capabilities" (whatever that means) will change that you are using the phrase incorrectly.
I even specifically said that I agree that we need less difficult personalities in kernel development. It's quite ironic that you then followed up the way you did.
Let me break it down for you with all the necessary substitutions
> (idiomatic) To raise a false alarm; to constantly warn others about an imagined threat, thereby failing to get assistance when a real threat appears.
The imagined threat is the level of quality in patches. He consistently raises false alarms about the quality of patches. The false part being the absolute terms he uses about the character of the people that proposed the patches. Calling someone an infantile moron qualifies as falsehood in my book and counts as raising a false alarm. Now that he is complaining about grsecurity I'm not inclined to listen because the level of alarm he has used previously has been incommensurate with reality, as in he has said "here is a wolf" (this patch is the worst thing ever and the person that wrote it is a moron) when in reality there was no wolf (patch was actually fine and the person was not a moron). Less alarmism would have helped everyone involved get along better and make a more secure kernel. Instead I'm arguing about how comparing his alarmism to crying wolf is or isn't idiomatic. FML
> The imagined threat is the level of quality in patches.
No, it often is a real threat.
> The false part being the absolute terms he uses about the character of the people that proposed the patches.
So feel free to disregard his opinions about the characters of other people, but don't be surprised that barely anyone treats you seriously when you suggest that the above somehow invalidates his technical analyses.
> Now that he is complaining about grsecurity I'm not inclined to listen
If there had been concrete examples and such, rational argument (hopefully) would have ensued, and HN would not have been notified about a completely normal engineering discussion down in the weeds. But seeing condemnation and drama works better for post material I suppose.
Crying wolf requires him to have been wrong (or lied). I think that GP was asking you for evidence of _that_, not of evidence that Linus has ranted in the past.
From memory, I can't recall a time where his ranting was not justified, but he has been wrong a couple of times. Unless I'm missing something blatant, that doesn't constitute "crying wolf" to me.
The parable of the boy crying wolf is not about lies but about desensitizing your audience to what you are saying. I've read enough of the rants to know there is very little signal to all the noise he makes.
The grsecurity stuff could be bad but I sure as hell am not gonna get my analysis from Linus. If he acted more like a grown up then maybe but he doesn't. He character assassinates and then says you are doing silly pointer arithmetic. Can just mention the pointer stuff without shouting and screaming at author of the patch.
The drama in kernel dev is a direct result of his abrasive approach. He screams and shouts so grsecurity screams and shouts. Everyone else loses. The kernel dev space needs less drama and more grown ups.
> The parable of the boy crying wolf is not about lies but about desensitizing your audience to what you are saying.
... Because the little boy was lying. If there really was a wolf every time he said there was they would consider him a brilliant scout rather than an untrustworthy source of information.
It's strange that it's necessary to explain children's parables on HN.
> The kernel dev space needs less drama and more grown ups.
I don't disagree with that, I just don't agree with saying that Linus is crying wolf. Because you don't appear to understand what it means.
The term “Crying Wolf” implies the very specific and extreme accusation of lying. Ranting, or even ranting then reversing course are very different from lying.
It's a struggle to respect the security opinions of someone who has actively admitted that he thinks "[security] bugs are just bugs". [0] Personally, I find it quite hard to respect Linus generally - his offensive personality is clearly not something that would be appropriate coming from anyone else in any community, but for some reason he gets a free ride for being a difficult genius.
>For Linux, the operating system that Torvalds created
Stopped reading right there. First of all, Linux is not an operating unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS. Because of that, the Operating System is not Linux, but rather GNU/Linux (or GNU + Linux which I recently have been calling it).
> They aren't split up, there has never been any effort by you to make them palatable to upstream, and when somebody else dioes try to make them palatable to upstream, you start crying about how people are taking advantage of your work (hah), and try to make them private instead.
...
> It's literally less work for people to re-implement things than look at your mixed-up patches, and YOU SEEM TO BE DOING THAT ON PURPOSE.
> Now, prove me wrong. Start trying to integrate your work upstream, and send individual patches with commit logs that can be integrated.