-
Although this response is reasonable up to and including the first point, the second point is a little less convincing. The idea that it’s okay to be bad at security simply because someone else was bad at security is unfortunate at best.
The first point is - although not completly wrong - definitely debatable since these connections can be made simultaneously and aren’t blocking each other, which seems like they are trying to insinuate here.
-
I think there’s a distinction to be made between “bad at security” and “not actually a security boundary”. If you retroactively redefine public info to be a secret, it shouldn’t be surprising that everyone is “bad” at protecting it, or that someone might pushback and say not a bug.
-
And how and why is a username considered public information, they asked? https://lobste.rs/u
-
-
They mentioned the MaxStartups parameter, which does seem like it will cause connections to block.
-
-
tedu
3 days ago
|
link
| on:
Intel Publishes Microcode Security Patches, No Benchmarking Or Comparison Allowed
UPDATE: Intel has resolved their microcode licensing issue which I complained about in this blog post. The new license text is here.
-
Here the ‘new’ license text: https://01.org/mcu-path-license-2018
Here the license text prior to the 2018-08 microcode drop: https://tracker.debian.org/media/packages/i/intel-microcode/copyright-3.20180703.2
They’re identical.
-
-
One thing about SPAs…they seemed to be really popular starting with the rise of Rails, mostly as a way of compensating for Rails amazingly slow rendering.
-
-
Server-side rendering is a thing.
-
-
-
Also, there’s (eg)
react-railswhich does server-rendering of a react SPA (so you get the HTML which your react code would generate, served by rails).
-
-
-
-
-
-
For the trivial case where wrapping behaviour does allow simply detecting overflow after it occurs, it is also straightforward to determine whether overflow would occur, before it actually does so. The example above can be rewritten as follows:
If it’s really so trivial then why not have the compiler do that rewrite? Given that the “wrong” version is valid language syntax, programmers will write it and compilers will have to compile it; no amount of encouraging programmers to rewrite gets us away from having to decide what the compiler should do when fed the “wrong” code.
An obvious mitigation for the problem of programmers expecting this particular behaviour is for the compiler to issue a warning when it optimises based on the alternative undefined-behaviour-is-assumed-not-to-occur semantics.
Building for maximum performance and warning about a correctness violation seems like the wrong priority. Why not build the code to behave in the way that you’re sure matches the programmer’s intent and warn about the missed optimisation opportunity?
Also, even without overflow check elimination, it is not necessarily correct to assume that wrapping integers has minimal direct cost even on machines which use 2’s complement representation. The Mips architecture, for example, can perform arithmetic operations only in registers, which are fixed size (32 bit). A “short int” is generally 16 bits and a “char” is 8 bits; if assigned to a register, the underlying width of a variable with one of these types will expand, and forcing it to wrap according to the limit of the declared type would require at least one additional operation and possibly the use of an additional register (to contain an appropriate bitmask). I have to admit that it’s been a while since I’ve had exposure to any Mips code and so I’m a little fuzzy on the precise cost involved, but I’m certain it is non-zero and other RISC architectures may well have similar issues.
It would be good to permit trapping. It would be good to permit whatever the native MIPS behaviour is. But it’s obviously absurd to permit optimizing out the programmer’s overflow check.
How about: “An expression in which signed integer overflow occurs shall evaluate to an implementation-defined value and may also cause the program to receive a signal”? In conjunction with the rules in 5.1.2.3.5 this still permits the compiler to trap, still permits the compiler to use the machine behaviour (twos-complement wrapping, some other form of wrapping, saturating or what-have-you), and still permits the compiler to reorder arithmetic operations (provided they don’t cross a sequence point), but rules out craziness like the elimination of overflow checks.
-
If it’s really so trivial then why not have the compiler do that rewrite?
Because the compiler doesn’t know what was intended. And I sure as heck don’t want the compiler re-writing any of my code to what it “thinks” I intended. And automatically “fixing” it in some cases but not others (less trivial) will likely lead to confusion.
Why not build the code to behave in the way that you’re sure matches the programmer’s intent and warn about the missed optimisation opportunity?
The compiler can’t be sure what the programmer intended.
You can’t be sure that the code will match the programmer’s intent. Maybe that “overflow check” really is redundant. Maybe the code is generated. Maybe the “overflow check” is only obviously redundant after several other optimisation passes have taken effect.
Giving a warning lets the programmer decide: Is this really ok or did I make a mistake? “Fixing” it for them pesimises without any way to undo that pesimisation, except in the very trivial cases, which, again, might be in generated source code.
It would be good to permit trapping. It would be good to permit whatever the native MIPS behaviour is. But it’s obviously absurd to permit optimizing out the programmer’s overflow check.
Both trapping and the MIPS behaviour (where a value in an integer of some type can be stored in a register wider than that type, which can incidentally also be done on just about any architecture) would make leaving the overflow check in absurd - because it wouldn’t achieve what it was intended to achieve anyway (even if the compiler could determine the intent).
-
In Ada, you can tell the compiler what behavior you want for integer overflow (or checks to catch it). Are there compiler hints in C for that or other undefined behavior that make the result predictable?
-
-
Thanks! Ill look it up.
-
-
-
Because the compiler doesn’t know what was intended. And I sure as heck don’t want the compiler re-writing any of my code to what it “thinks” I intended. And automatically “fixing” it in some cases but not others (less trivial) will likely lead to confusion.
It would be hard to do worse than deleting overflow checks that the programmer wrote into the code, but only sometimes, which is the current behaviour. Undefined behaviour practically guarantees all the things that you’ve just said you don’t want. (Indeed, the compiler is already permitted to behave in the way I’ve suggested it should - it’s just also permitted to do other, less helpful and more confusing, things).
(I do agree that it’s not actually trivial for the compiler to fix these cases - my point was if it’s not so trivial for the compiler, it’s not so trivial for the programmer either. So “the programmer should just rewrite their code so the problem doesn’t happen” isn’t a good answer.)
You can’t be sure that the code will match the programmer’s intent. Maybe that “overflow check” really is redundant. Maybe the code is generated. Maybe the “overflow check” is only obviously redundant after several other optimisation passes have taken effect.
Indeed you can’t be sure, which is why a responsible compiler should fail-safe rather than fail-dangerous. A missed optimization opportunity is much better than a security bug.
Both trapping and the MIPS behaviour (where a value in an integer of some type can be stored in a register wider than that type, which can incidentally also be done on just about any architecture) would make leaving the overflow check in absurd - because it wouldn’t achieve what it was intended to achieve anyway (even if the compiler could determine the intent).
Trapping achieves what the programmer usually intends - the programmer usually wants the function to abort/error when overflow occurs. Certainly it avoids the worst possible outcome, the one thing we can be certain that the programmer didn’t intend - blindly continuing to execute after overflow.
On second thoughts you’re right about MIPS. The programmer almost certainly never intended for an integer to be operated on at a certain width and then truncated at some mysterious later point in the execution of their program. That is so rarely an intended behaviour that I don’t think any responsible compiler should implement it without being very explicitly instructed to.
-
Undefined behaviour practically guarantees all the things that you’ve just said you don’t want.
No, it doesn’t. In making this claim, you are implying that code which invokes undefined behaviour still has defined semantics. Certainly, the compiler won’t guess what was intended and then try to use undefined behaviour to try and implement that; it assumes that what it was told was intended (i.e. what was expressed by the code, according to the semantics of the language) is what was intended. That’s a reasonable assumption to make given the nature and purpose of a compiler.
It would be hard to do worse than deleting overflow checks that the programmer wrote into the code, but only sometimes, which is the current behaviour.
I agree that, if the compiler could divine that some check (which it would otherwise optimise away) is meant to be a wrapping overflow check for some particular preceding operation, it would be nice if the compiler could issue a strong warning. I do not believe it should ever silently “fix” the problem by applying wrapping semantics to the relevant preceding operations, because that is going to lead to C programmers increasingly believing that overflow does have wrapping behaviour, and I don’t think that is a good idea even if wrapping was the ideal overflow behavior.
One question is, would assuming that most/all code that fits that general pattern is an indication that wrapping behaviour was required by previous operations and compiling accordingly (with a warning), have a negative impact on optimisations and performance? I think the answer is “probably not for most existing programs”, but I also think it could clearly have a significant impact potentially. This could be extended generally to a question about whether wrapping semantics generally could impact optimisation (which I think has the same answer).
Another question is, is wrapping behaviour generally useful, other than for purpose of these overflow checks? I’ve address that in the post; I think the answer is clearly no.
However, is wrapping better behaviour (disregarding performance) than undefined behaviour? From a safety perspective it may be slightly better, since the effect of overflow bugs is more constrained, but the bugs can still happen and can still be exploited. This is anecdotal, but most of the overflow-related security holes that I’ve seen, other than the small number due to compiler-removed post-overflow checks, have been directly caused by the wrapping and not by any other associated undefined behaviour.
So:
- I’m not convinced that wrapping semantics will never significantly impact performance in real programs
- I don’t see wrapping as a useful behaviour, other than for implementing erroneous post-overflow checks, which can and should anway be re-written as correct pre-overflow checks
- I’m not convinced that wrapping on overflow is much better than UB on overflow, in practice (yes, in theory UB can do very nasty things. But for this particular case of UB, practically speaking, the effects are usually constrained). But let’s assume that we want to avoid arbitrary UB. In that case:
- Trap-on-overflow is a superior alternative because it’s safer, except in cases where performance is critical (and in those cases, wrapping might not be the right choice either).
Getting back to what you said, the only way to not delete any overflow checks is to enforce wrapping semantics everywhere, and I disagree with that due to the points above.
Indeed you can’t be sure, which is why a responsible compiler should fail-safe rather than fail-dangerous. A missed optimization opportunity is much better than a security bug.
Agreed - that’s why trapping and not wrapping is the right behaviour.
Thanks for bringing up some reasonable discussion. I don’t think there’s a totally objective right/wrong answer at this point - but I hope you see some validity in the points I’ve raised above.
(some small edits made after posting to improve readability).
-
-
-
-
Should it be legal to rob a bank and turn yourself in?
-
-
Sometimes I like to think that I know how computers work, and then I read something written by someone who actually does and I’m humbled most completely.
-
-
I guess to me it doesn’t feel like there’s much Windows specific complexity here, just a generally complex issue; a bug in v8’s sandboxed runtime and how it interacts with low-level OS-provided virtual memory protection and specific lock contention behavior, which only expressed itself by happenstance for the OP.
Some of this stuff just feels like irreducible complexity, though my lack of familiarity with Windowsisms (function naming style, non-fair locks, etc.) probably doesn’t help there.
-
-
Do you mean CFI?
CFG is MS’s Control Flow Guard, it’s a combination of compile-time instrumentation from MSVC and runtime integration with the OS. CFI on Linux (via clang/LLVM), in contrast, is entirely compile time AFAIK, with basically no runtime support.
See:
- https://blog.trailofbits.com/2016/10/17/lets-talk-about-cfi-clang-edition/
- https://blog.trailofbits.com/2016/12/27/lets-talk-about-cfi-microsoft-edition/
for more details on the differences.
-
-
-
-
-
Quote from Wikipedia:
An enumeration is a complete, ordered listing of all the items in a collection.
Could someone enlight me on this? What the Article describes doesn’t seem like “complete listing”.
-
-
igorclark
10 days ago
|
link
| on:
TLS 1.3 is Coming - an Opportunity for Amazon, Google and Microsoft to End Censorship
Wasn’t sure if this was really on-topic, mainly wanted to see what lobsters think about the idea of Google & Amazon voluntarily doing this, particularly given Google’s reported China search plans.
-
I feel it’s inevitable that somebody breaks some service’s security using SNI/Host confusion. I’m not sure what the attack looks like, but I know it has to happen. :) Something like cache poisoning maybe. https://portswigger.net/blog/practical-web-cache-poisoning
-
I run an SSL termination endpoint with multiple domains on it. I would not, in a terms of service sense, permit one of those domains to domain front by setting the SNI field to another domain I was incidentally also hosting. I do however have a domain that does nothing but handle SSL/TLS requests when there is no SNI field. It allows my endpoint to gracefully degrade in to an error message that can be delivered via https. Typically this would only happen with old and deprecated SSL software and connections, but I wouldn’t be bothered by a domain owner using this already dedicated domain in their SNI field if they wanted to.
I’m a long way from having the problems or concerns highlighted in this article, but you did ask what folk thought.
-
-
-
tscs37
12 days ago
|
link
| on:
Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution
I’m gonna sit in the smug corner for people running AMD.
Otherwise, this is all kinds of “very very bad”. The kind of where in a cartoon you’d have sirens spin up to warn of incoming air raids.
-
-
I am a maths researcher at the university of Cologne and adressed this in a thesis I wrote in 2016. See chapter 3, especially the first part of section 3.1.
Dividing by zero is totally well defined for the projectively extended real numbers (only one unsigned infinity inf) but the argument for the usual extended real numbers (+-inf) not working is not based on field theory, but of infinitisemal nature, given you can approach a zero-division both from below and above and get either +inf or-inf equally likely.
Defining 1/0=0 not only breaks this infinitiseminal form, it‘s also radically counterintuïtive given how the values behave when you approach the division from small numbers, e.g. 1/10, 1/1, 1/0.1, 1/0.001…
lim x->0 1/x = 0 makes no sense and is wrong in terms of limits.
See the thesis where I proved a/0=inf to be well-defined for a!=0.
tl;dr: There‘s more to this than satisfying the field conditions. If you redefine division, this has consequences on higher levels, in this case most prominently in infinitisemal analysis.
-
I used to be a maths researcher, and would just like to point out that some of the people who define division by zero to mean infinity do it because they’re more interested in the geometric properties of the spaces that functions are defined on than the functions themselves. This is the reason for the Riemann sphere in complex analysis, where geometers really like compact spaces more than noncompact ones, so they’re fine with throwing away the field property of the complex numbers. The moment any of them need to compute things, however, they pick local coordinates where division by zero doesn’t happen and use the normal tools of analysis.
-
Thanks for laying this out and pointing out the issue with +/- Inf
Could you summarize here why +Inf is a good choice. As a practical man I approach this from the limit standpoint - usually when I end up with a situation like this it’s because the correct answer is +/- Inf and it depends on the context which one it should be. Here context means on which side of zero was my history of the denominator.
The issue is that the function 1/x has a discontinuity at 0. I was taught that this means 1/0 is “undefined”. IMO in code this means throw an exception.
In practical terms I end up adding a tiny number to the denominator (e.g. 1e-10) and continuing, but that implicitly means I’m biased to the positive side of line.
I think Pony’s approach is flat out wrong.
-
It is not +inf, but inf. For the projectively extended real numbers, we only extend the set with one infinite element which has no sign. Take a look at page 18 of the thesis which includes an illustration of this. Rather than having a number line we have a number circle.
Dividing by zero, the direction we approach the denominator does not matter, even if we oscillate around zero, given it all ends up in one single point of infinity. We really don’t limit ourselves here with hat as we can express a limit to +inf or -inf in the traditional real number extension by the direction from which we approach inf in the projectively extended real numbers (see remark 3.5 on page 19).
1/x is discontinuous at 0, this is true, but we can always look at limits. :) I am also a practical man and hope this relatively formal way I used to describe it did not distract from the relatively simple idea behind this.
Pony’s approach is reasonable within field theory, but it’s not really useful when almost the entire analytical building on top of it collapses on your head. NaN was invented for a reason and given the IEEE floating-point numbers use the traditional +-inf extension, they should just return the indeterminate form on division by zero in Pony.
-
NaN only exists for floating point, not integers. If you want to use NaN or something like it for integers, you will need to box all integer numbers and take a large performance hit.
-
-
-
-
-
-
The problem turns out to be some obscure FUSE mounts that the author had lying around in a broken state, which subsequently broke the kernel namespace system. Meanwhile, I have been running systemd on every computer I’ve owned in many years and have never had a problem with it.
Does this not seem a bit melodramatic?
-
From the twitter thread:
Systemd does not of course log any sort of failure message when it gives up on setting up the DynamicUser private namespace; it just goes ahead and silently runs the service in the regular filesystem, even though it knows that is guaranteed to fail.
It sounds like the system had an opportunity to point out an anomaly that would guide the operator in the right direction, but instead decided to power through anyways.
-
-
-
-
We have monitoring and alerting around how much money is coming in, that we compare with historical data and predictions. It’s actually a very reliable canary for when things go wrong, and for when they are right again, on the scale of seconds to a few days. But you are right that things getting a little suckier slowly over a long time would only show up as real growth not being in line with predictions.
-
-
-
I tend to agree that hard failures are nicer in general (especially to make sure things work), but I’ve also been in scenarios where buggy logging code has caused an entire service to go down, which… well that sucked.
There is a justification for partial service functionality in some cases (especially when uptime is important), but like with many things I think that judgement calls in that are usually so wrong that I prefer hard failures in almost all cases.
-
-
Everybody thinks it’s a good idea “some service is surely better than no service” until it happens to them.
So if the server is over capacity, kill it and don’t serve anyone?
Router can’t open and forward a port, so cut all traffic?
I guess that sounds a little too hyperbolic.
But there’s a continuum there. At $work, I’ve got a project that tries to keep going even if something is wrong. Honest, I’m not sure I like how all the errors are handled. But then again, the software is supposed to operate rather autonomously after initial configuration. Remote configuration is a part of the service; if something breaks, it’d be really nice if the remote access and logs and all were still reachable. And you certainly don’t want to give up over a problem that may turn out to be temporary or something that could be routed around… reliability is paramount.
-
And you certainly don’t want to give up over a problem that may turn out to be temporary
I think that’s close to the core of the problem. Temporary problems recur, worsen, etc. I’m not saying it’s always wrong to retry, but I think one should have some idea of why the root problem will disappear before retrying. Computers are pretty deterministic. Transient errors indicate incomplete understanding. But people think a try-catch in a loop is “defensive”. :(
-
-
-
-
So you never had legacy systems (or configurations) to support? I read Chris’ blog regularly, and he works at a university on a heterogeneous network (some Linux, some other Unix systems) that has been running Unix for a long time. I think he started working there before
systemdwas even created. -
Why do you say that the FUSE mounts were broken? As far as we can see they were just set up in a uncommon way https://twitter.com/thatcks/status/1027259924835954689
-
-
Yes, it seems melodramatic, even to my anti-systemd ears. It’s a documentation and error reporting problem, not a technical problem, IMO. Olivier Lacan gave a great talk last year about good errors and bad errors (https://olivierlacan.com/talks/human-errors/). I think it’s high time we start thinking about how to improve error reporting in software everywhere – and maybe one day human-centric error reporting will be as ubiquitous as unit testing is today.
-
In my view (as the original post’s author) there are two problems in view. That systemd doesn’t report useful errors (or even notice errors) when it encounters internal failures is the lesser issue; the greater issue is that it’s guaranteed to fail to restart some services under certain circumstances due to internal implementation decisions. Fixing systemd to log good errors would not cause timesyncd to be restartable, which is the real goal. It would at least make the overall system more debuggable, though, especially if it provided enough detail.
The optimistic take on ‘add a focus on error reporting’ is that considering how to report errors would also lead to a greater consideration of what errors can actually happen, how likely they are, and perhaps what can be done about them by the program itself. Thinking about errors makes you actively confront them, in much the same way that writing documentation about your program or system can confront you with its awkward bits and get you to do something about them.
-
-
-
This blogpost is a good example of fragmented, hobbyist security maximalism (sprinkled with some personal grudges based on the tone).
Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.
Talking about threat models, it’s important to start from them and that explains most of the misconceptions in the post.
- Usable security for the most people possible. The vast majority people on the planet use iOS and Android phones, so while it is theoretically true that Google or Apple could be forced to subvert their OSs, it’s outside the threat model and something like that would be highly visible, a nuclear option so to speak.
- Alternative distribution mechanisms are not used by 99%+ of the existing phone userbases, providing an APK is indeed correctly viewed as harm reduction.
- Centralization is a feature. Moxie created a protocol and a service used by billions and millions of people respectively that provides real, measureable security for a lot of people. The fact is that doing all this in a decentralized way is something we don’t yet know how to do or doing invites tradeoffs that we shouldn’t make. Federation atm either leads to insecurity or leads to the ossification of the ecosystem, which in turn leads to a useless system for real users. We’ve had IRC from the 1990s, ever wonder why Slack ever became a thing? Ossification of a decentralized protocol. Ever wonder why openpgp isn’t more widespread? Noone cares about security in a system where usability is low and design is fragile. Ever tried to do key rotation in gpg? Even cryptographers gave up on that. Signal has that built into the protocol.
Were tradeoffs made? Yes. Have they been carefully considered? Yes. Signal isn’t perfect, but it’s usable, high-level security for a lot of people. I don’t say I fully trust Signal, but I trust everything else less. Turns out things are complicated when it’s about real systems and not fantasy escapism and wishes.
-
Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.
In this article, resistance to governments constantly comes up as a theme of his work. He also pushed for his tech to be used to help resist police states like with the Arab Spring example. Although he mainly increased the baseline, the tool has been pushed for resisting governments and articles like that could increase perception that it was secure against governments.
This nation-state angle didn’t come out of thin air from paranoid, security people: it’s the kind of thing Moxie talks about. In one talk, he even started with a picture of two, activist friends jailed in Iran in part to show the evils that motivate him. Stuff like that only made the stuff Drew complains about on centralization, control, and dependence on cooperating with surveillance organization stand out even more due to the inconsistency. I’d have thought he’d make signed packages for things like F-Droid sooner if he’s so worried about that stuff.
-
A problem with the “nation-state” rhetoric that might be useful to dispel is the idea that it is somehow a God-tier where suddenly all other rules becomes defunct. The five-eyes are indeed “nation state” and has capabilities that are profound; like the DJB talk speculating about how many RSA-1024 keys that they’d likely be able to factor in a year given such and such developments and what you can do with that capability. That’s scary stuff. On the other hand, this is not the “nation state” that is Iceland or Syria. Just looking at the leaks from the “Hacking Team” thing, there are a lot of “nation states” forced to rely on some really low quality stuff.
I think Greg Conti in his “On Cyber” setup depicts it rather well (sorry, don’t have a copy of the section in question) and that a more reasonable threat model of capable actors you do need to care about is that of Organized Crime Syndicates - which seems more approachable. Nation State is something you are afraid of if you are political actor or in conflict with your government, where the “we can also waterboard you to compliance” factors into your threat model, Organized Crime hits much more broadly. That’s Ivan with his botnet from internet facing XBMC^H Kodi installations.
I’d say the “Hobbyist, Fragmented Maximalist” line is pretty spot on - with a dash of “Confused”. The ‘threats’ of Google Play Store (test it, write some malware and see how long it survives - they are doing things there …) - the odds of any other app store; Fdroid, the ones from Samsung, HTC, Sony et al. - being completely owned by much less capable actors is way, way higher. Signal (perhaps a Signal-To-Threat ratio?) perform an good enough job in making reasonable threat actors much less potent. Perhaps not worthy of “trust”, but worthy of day to day business.
-
-
Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.
And yet, Signal is advertising with the face of Snowden and Laura Poitras, and quotes from them recommending it.
What kind of impression of the threat models involved do you think does this create?
-
-
Whichever ones are normally on the media for information security saying the least amount of bullshit. We can start with Schneier given he already does a lot of interviews and writes books laypeople buy.
-
-
He encourages use of stuff like that to increase baseline but not for stopping nation states. He adds also constantly blogged about the attacks and legal methods they used to bypass technical measures. So, his reporting was mostly accurate.
We counterpoint him here or there but his incentives and reo are tied to delivering accurate info. Moxie’s incentives would, if he’s selfish, lead to locked-in to questionable platforms.
-
-
-
-
-
We’ve had IRC from the 1990s, ever wonder why Slack ever became a thing? Ossification of a decentralized protocol.
I’m sorry, but this is plain incorrect. There are many expansions on IRC that have happened, including the most recent effort, IRCv3: a collectoin of extensions to IRC to add notifications, etc. Not to mention the killer point: “All of the IRCv3 extensions are backwards-compatible with older IRC clients, and older IRC servers.”
If you actually look at the protocols? Slack is a clear case of Not Invented Here syndrome. Slack’s interface is not only slower, but does some downright crazy things (Such as transliterating a subset of emojis to plain-text – which results in batshit crazy edge-cases).
If you have a free month, try writing a slack client. Enlightenment will follow :P
-
I’m sorry, but this is plain incorrect. There are many expansions on IRC that have happened, including the most recent effort, IRCv3: a collectoin of extensions to IRC to add notifications, etc. Not to mention the killer point: “All of the IRCv3 extensions are backwards-compatible with older IRC clients, and older IRC servers.”
Per IRCv3 people I’ve talked to, IRCv3 blew up massively on the runway, and will never take off due to infighting.
-
-
There are swathes of people still using Windows XP.
The primary complaint of people who use Electron-based programs is that they take up half a gigabyte of RAM to idle, and yet they are in common usage.
The fact that people are using something tells you nothing about how Good that thing is.
At the end of the day, if you slap a pretty interface on something, of course it’s going to sell. Then you add in that sweet, sweet Enterprise Support, and the Hip and Cool factors of using Something New, and most people will be fooled into using it.
At the end of the day, Slack works just well enough Not To Suck, is Hip and Cool, and has persistent history (Something that the IRCv3 group are working on: https://ircv3.net/specs/extensions/batch/chathistory-3.3.html)
-
At the end of the day, Slack works just well enough Not To Suck, is Hip and Cool, and has persistent history (Something that the IRCv3 group are working on […])
The time for the IRC group to be working on a solution to persistent history was a decade ago. It strikes me as willful ignorance to disregard the success of Slack et al over open alternatives as mere fashion in the face of many meaningful functionality differences. For business use-cases, Slack is a better product than IRC full-stop. That’s not to say it’s perfect or that I think it’s better than IRC on all axes.
To the extent that Slack did succeed because it was hip and cool, why is that a negative? Why can’t IRC be hip and cool? But imagine being a UX designer and wanting to help make some native open-source IRC client fun and easy to use for a novice. “Sisyphean” is the word that comes to mind.
If we want open solutions to succeed we have to start thinking of them as products for non-savvy end users and start being honest about the cases where closed products have superior usability.
-
IRC isn’t hip and cool because people can’t make money off of it. Technologies don’t get investment because they are good, they get good because of investment. The reason that Slack is hip/cool and popular and not IRC is because the investment class decided that.
It also shows that our industry is just a pop culture and can give a shit about good tech .
-
There were companies making money off chat and IRC. They just didn’t create something like Slack. We can’t just blame the investors when they were backing companies making chat solutions whose management stayed on what didn’t work in long-term or for huge audience.
-
-
My point was there were companies selling chat software, including IRC clients. None pulled off what Slack did. Even those doing IRC with money or making money off it didn’t accomplish what Slack did for some reason. It would help to understand why that happened. Then, the IRC-based alternative can try to address that from features to business model. I don’t see anything like that when most people that like FOSS talk Slack alternatives. Then, they’re not Slack alternatives if lacking what Slack customers demand.
-
Thanks for clarifying. My point can be restated as… There is no business model for federated and decentralized software (until recently , see cryptocurrencies). Note most open and decentralized tech of the past was government funded and therefore didn’t face business pressures. This freed designets to optimise other concerns instead of business onrs like slack does.
-
-
-
-
-
-
Right, as I said I think it’s important for proponents of open tech to look at successful products like Slack and try to understand why they succeeded. If you really think there is no meaningful difference then I think you’re totally disconnected from the needs/context of the average organization or computer user.
-
That’s all well and good, I just don’t see why we can’t build those systems on top of existing open protocols like IRC. I mean: of course I understand, it’s about the money. My opinion is that it doesn’t make much sense to insist that opaque, closed ecosystems are the way to go. We can have the “hip-and-cool” factor, and all the amenities provided by services like Slack, without abandoning the important precedent we’ve set for ourselves with protocols like IRC and XMPP. I’m just disappointed that everyone’s seeing this as an “either-or” situation.
-
-
-
-
-
Open, standard chat tech has had persistent history and much more for decades in the form of XMPP. Comparing to the older IRC on features isn’t really fair.
-
-
I don’t see how Good and “good enough to solve a problem” are related here. The first is a metric of quality, the second is the literal bare minimum of that metric.
-
-
-
-
-
Alternative distribution mechanisms are not used by 99%+ of the existing phone userbases, providing an APK is indeed correctly viewed as harm reduction.
I’d dispute that. People who become interested in Signal seem much more prone to be using F-Droid than, say, WhatsApp users. Signal tries to be an app accessible to the common person, but few people really use it or see the need… and often they are free software enthusiasts or people who are fed up with Google and surveillance.
-
-
Ossification of a decentralized protocol.
IRC isn’t decentralised… it’s not even federated
-
-
Didn’t systemd hard code 8.8.8.8 as well at some point?
It’s such a good thing that people are watching out for violations in free software.
-
They use it as the default for the fallback if no DNS is configured. https://github.com/systemd/systemd/blob/master/meson_options.txt#L200
-
-
That depends on your individual situation. Some users might appreciate that the system ‘just works’ even if not configured properly. Other wouldn’t, for 2 reasons:
- Sending data a third party, especially one like google, without telling the user, is not ok in terms of privacy.
- If something is misconfigured but silently falls back to a default which appears to work (while actually behaving in a different manner to how the user intended), then it’s much more difficult for the user to know that it needs fixing, and often much more difficult for the user to fix.
-
-
-
-
You cannot imagine how many people mark comments they do not like as incorrect without even checking the sources, commenting or noticing that they are opinions!
You shouldn’t care much: other might learn something from your comment anyway. At least an incorrect downvote make you double check the sources!
-
-
-
-
Premature optimization is the root of all evil
- C.A.R. Hoare
Wasn’t that Knuth?
-
The punchline is that the AES key is just MD5(password || IV[:8]).
Would somebody please tell me if
passwordis the phrase that you enter at theEnter passphrase (empty for no passphrase):prompt during an invocation ofssh-keygen?Would somebody describe how the article should change to take into account empty passphrases?
-
-
I’m not sure I like this article. It raises a good point (use -o) but it’s obviously being misread.
-
-
This is why you Don’t Implement Your Own Crypto! Come on folks.
-
-
-
Pretty sure this comment was intended as a joke for this reason?
-
-
-
-
I read the article, and the situation seems related to OpenSSL only. Joel Sing confirmed that commits https://github.com/libressl-portable/openbsd/commit/17b1f1ce28ae8bc5a873951ad6c8aa564b68c0ab and https://github.com/libressl-portable/openbsd/commit/952c1252f58f5f57227f5efaeec0169759c77d72 fixed the issues back in 2017 for LibreSSL. More details by Billy Brumley to the oss-security earlier this year: http://www.openwall.com/lists/oss-security/2018/04/16/3 .
In conclusion OpenBSD and Void Linux have this mitigated.
-
-
-
There is no way in heck that linus will merge some DIY home rolled crypto code into the kernel
-
-
That’s a good point but missing key detail. I’ll add author did WireGuard which has had good results in both formal verification and code review.
-
-
-
-
-
-
Why not? How would Linus even know if some crypto code was DIY nonsense?
(The subtext of these commits from Jason is that the existing kernel crypto APIs are not particularly good, IMO.)
-
-
Kinda surprised that reddit - a site which hosts rougher parts of the internet - has not had a Head of Security until 2.5 months ago?
-
-
-
-
-
-
-
I’ll add to mulander’s hypothetical that this happened in all kinds of big companies with significant investments in security. They were breached for years without knowing they were compromised. They started calling them “APT’s” as a PR move to reduce humiliation. It was often vanilla attacks or combos of those with some methods to bypass monitoring that companies either didn’t have or really under-invested in. Reddit could be one if they had little invested in security or especially intrusion detection/response.
-
-
-
-
-
-
Because reddit is not hosting financial data or (for the most part) deeply personal data that is not already out in the open, I would assume that they are not that interesting a target for hackers looking for financial gain, but more interesting for
peoplescript kiddies who are looking to DOX or harass other users.-
Many subreddits host content and discussions that people don’t want to be attached to. The post even appreciates that and recommends deletion of those posts.
I find it telling that you go out of your way pushing people interested in gaining personal data in the script kiddie corner. Yes, SMS based attacks are in the range of “a script kiddie could do that”, which makes it even worse.
-
-
-
-
The response from the moderators of the Elm subreddit to this post is perhaps a good example of some of the things described by the author. Characterization of this post as abusive is something that sticks out.
They actually did lock the post. As in here’s how we prove you right.
That reads like a copy paste that’s not actually in response to the article?
One interesting thing I immediately noticed about that is that it isn’t a single moderate (despite them having them) – it is a collective, the “elm_mods”. This feels like a shield allow the mods to be harsher than they might be as an individuals because no individual is ever responsible for the posts from “elm_mods”.