mehrdadn

15 ms·

121.
by mehrdadn 6y ago
Oh interesting. So that would mean it would depend on a compromised build machine. Yeah, that would make sense, and I guess you couldn't prevent it like this in that case. Thanks!
122.
by mehrdadn 6y ago
What does 70% more transmissible mean?
123.
by mehrdadn 6y ago
Note that it shouldn't be an "action" on GitHub Actions, since those are specified in the repo itself, and can hence be removed in the same commit. It needs to be an external thing.
124.
by mehrdadn 6y ago
I recall hearing Airbus had its own messes to deal with... such as https://www.reuters.com/article/us-airbus-probe/airbus-bribe...
125.
by mehrdadn 6y ago
Hmm, interesting. I'm confused if that's how I should read this. You might be right. I assume you're referring to this paragraph? > Evidence suggests that as early as October 2019, these attackers have been testing their a
126.
by mehrdadn 6y ago
Maybe, assuming it's all committed in one shot (rather than, say, a couple lines per review) and the reviewer scrolls through and glances at every chunk of code. It's some 4000 lines of code, so I wouldn't be surprised if at
127.
by mehrdadn 6y ago
I can imagine it failing or succeeding depending on how intrusive the UX is. It's worth trying out I think, especially in an opt-in fashion. They can improve it gradually and people can leave it disabled if they don't like it.
128.
by mehrdadn 6y ago
Any GitHub/GitLab/etc. employees here? I think you might be able to help mitigate some of these kinds of attacks: > To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encod
129.
by mehrdadn 6y ago
It's not hard to envision code reviews that don't review every single line. Been on both sides of it. Code review isn't a security barrier, it's a (noisy) safety check. It can't even catch every silly bug, let alone
130.
by mehrdadn 6y ago
Does any airline guarantee a flight won't happen on MAX? I haven't heard of such a thing. Can't they later change the plane? Do they give you your money back?
131.
by mehrdadn 6y ago
> What you are suggesting would break email. No it would not. Firstly, because you would just rejected twice; the sky wouldn't fall down. Secondly, because the RFC in fact permits this too; it's within spec even if you want to
132.
by mehrdadn 6y ago
I'm tired of arguing about this. Engineers agree on standards for a good reason, yes, but they also agree on "should not" rather than "must not" for a good reason too. I'll leave this as my last comment, but yo
133.
by mehrdadn 6y ago
Sending an email doesn't require "seeing" anything other than whether the server is willing to receive email for that address though, right? Also, that problem occurs due to lack of authorization, not due to authentication fa
134.
by mehrdadn 6y ago
I'm skimming this but so far I still don't understand how any kind of authentication failure can or should lead to an SMTP server returning "this address doesn't exist". Does anyone see an explanation? Edit 1: Oh wo
135.
by mehrdadn 6y ago
Confused, how is NOBUS supposed to reduce any attack surface? NOBUS means you don't patch vulnerabilities that you believe only you have access to. Wouldn't that expand an attack surface (or leave it as-is)? How would a refusa
136.
by mehrdadn 6y ago
Louis Rossmann also has a good talk [1] on the USA Today article [2]. [1] https://www.youtube.com/watch?v=eTNd3n0Ixfw [2] https://www.usatoday.com/story/news/health/2020/12/15/p
137.
Bell’s Palsy, Chills, Joint Pain Among Side Effects Reported in Vaccine Trials(khn.org)
3 points by mehrdadn 6y ago|1 comments
138.
by mehrdadn 6y ago
I mean... you understand why it's not consensual here, right? It's not because they're trying to use your data for marketing purposes, it's because they need it to address public health. When you send your kids to school
139.
by mehrdadn 6y ago
Normally I care more about privacy than other people, and for a lot of illnesses I'd find this more than understandable, but for this pandemic, I don't understand your sentiment. Not only has it already infected over 74M people
140.
by mehrdadn 6y ago
No, that's not a sane way to interpret this RFC for the receiver either. I already answered this, so you'll have to go back to my earlier comment (this might be my last comment as I won't keep repeating myself): any system (b
141.
by mehrdadn 6y ago
No, I am quite explicitly not ignoring the spec. It quite deliberately says should not , not must not . If anyone is ignoring the spec here, it's you, not me. Should not is sound advice; it's telling you what you're sup
142.
by mehrdadn 6y ago
I have 2 responses to the sender reputation concern: 1. If the user's mail service penalizes you equally regardless of whether the recipient's addressed existed 1 day vs. never existed, that itself is absolutely inexcusable nonsen
143.
by mehrdadn 6y ago
There's no clear-cut rule here. Some workarounds stay workarounds and never get standardized. Some become so well-accepted and adopted that people then put them into standards. It's great to put things into standards, so by all me
144.
by mehrdadn 6y ago
You "should not" repeat delivery in basically the same way the mailman "should not" knock a second time if he's told the recipient doesn't reside at the designated address. What "should not" means in
145.
by mehrdadn 6y ago
The phrase "must not" appears some 60 times in this RFC.
146.
by mehrdadn 6y ago
You're entirely missing the point by blaming this on Google. This is meant to detect and handle some failure modes, and they could happen to anyone (including Google), for reasons that can be both inside and outside their control.
147.
by mehrdadn 6y ago
> That is exactly the thought process that leads to non-standard mess that we see numerous examples of. I didn't suggest people should apply this thought process in arbitrary cases. I said it should be applied in this case. You ca
148.
by mehrdadn 6y ago
Gmail screwed up, but that's beside the point. We're talking about designing robust systems. You don't design a robust system by assuming nobody will screw up! Re: the RFC, note it says "should not", not "must
149.
by mehrdadn 6y ago
Right. In this case it's already pretty typical for mailing lists to track bounces and retry under some errors, so I imagined that part is mostly done, and the missing piece would be taking more care in checking the error conditions.
150.
by mehrdadn 6y ago
Mail agents already queue emails that bounce though; it's a matter of changing the conditions for when you retry and/or unsubscribe. I imagine you can do the analysis in real time too... just look at the bounce and see if it perta

More ›