_urga

"as important as any of these factors"

Surely direction has to be more important?

A great team is great, but not if "we're on a road to nowhere".

And even a good (or possibly mediocre) team with a great direction, a noble goal, must be better than a great team with a dead-end direction, because people will sacrifice and put up with all kinds of politics if the cause is worthy, if there are lives on the line.

The same is true for bestseller business books, all concerned with the How and not the Why, when it's the Why that moves the needle.

And you see this blind adherence to "process over purpose" everywhere in software teams, with things like Agile, Scrum, Kubernetes, microservices etc. where none of this actually matters to the user.

Henry Ford's autobiography is one of the few that focuses on the Why, and it is ironic that business schools tend to talk about him in terms of the How ("he revolutionized the production process"). Henry Ford's secret to everything was not his production process, but the basis on which he conducted business and approached industry.

The thing is, if you get the Why right, then the How automatically follows: do things in the most direct way possible with a minimum of red tape.

"How you build it: How much do you value the application of specific technologies, engineering practices or processes when building software?"

And the inverse: How much do you value doing things in the most direct way possible with a minimum of specific technologies, dependencies, frameworks, practices or processes (i.e. red tape)?

Following Conway's Law, the problem with the internet is not so much the internet but the destruction of IRC and the centralization of email. The stagnation in open-source email software and security, the embrace-extend-extinguish of AMP for email, and the decline in quality independent email providers. Fix email (and revive IRC) and we can start fixing the internet.

"Is paying attention and acting on microaggressions and unconscious biases"

I understood this as aggresion and bias with regards to work-related technical discussions, for example ignoring or talking over people in a video call who suggest taking a deeper code dive when debugging, or saying "no, I disagree, you are wrong" on a technical point without saying why or making any effort, or starting a call by dropping f-bombs, or shouting "but the code is the documentation!!" when someone politely suggests that issue comments by a library author are also worth paying attention to when trying to understand the meaning of a rabbit's hole of code call chains... especially where these people are from different teams or companies with different incentives.

These are just recent examples of aggression and bias in a technical context that I have personally witnessed.

I came here to say the same thing: Zig. The design decisions are spot on.

For example, Modeling Data Concurrency w/ Asynchronous I/O in Zig by Andrew Kelley: https://t.co/VYNqNcrkH1?amp=1

Passing a message is immutable for starters, which means read-only access for the receiving process, enforcing the single-writer principle.

Thanks!

There are things that the parser must necessarily decide because nobody higher up the stack will understand them or think to limit them and override the default, even if a configuration object were to be exposed.

For example, one variant of this kind of MIME bomb would be defeated by a limit on the number of RFC 2231 parameter continuations acceptable per header. Even if you were to allow the user to override the default limit as you propose, your library would still need a sane default, because you would probably find that not many people would see RFC 2231 parameter continuations as a threat vector or even think to specify a limit, let alone know what a sane limit would be.

In the end, to be secure, you would have to expose so many limits that just using the library would be a mess.

As soon as you say "that's not for the parser to decide" you run the risk of things falling through the gap and no policy decisions being made at all.

You also have to accept that sometimes the parser designer alone knows best the complexity analysis of the resources the library will need.

Yes, they are still a thing, especially with David Fifield's variant, but even with simpler zip bombs. You would be amazed at what can crash an antivirus engine.

Coincidentally, https://github.com/ronomon/zip can catch David Fifield's zip bomb.

Thanks for this!

Besides upvotes, HN should have a hall of fame for comments this good.

It reminds me of 1 Corinthians 15:33 quoting the Greek poet Menander:

  Do not be misled: “Bad company corrupts good character.”

It turned out that two different variants of this also affected ClamAV and SpamAssassin:

https://blog.clamav.net/2019/11/clamav-01021-and-01015-patch...

http://mail-archives.apache.org/mod_mbox/spamassassin-announ...

> I do know that 7bit encodings can break a whole lot of parsers in unexpected ways.

That would be interesting. Would you please share some unit test cases and I will run them past @ronomon/mime?

I wrote @ronomon/mime (https://github.com/ronomon/mime) as a strict fuzz-tested MIME parser in a memory-safe language to prevent similar attacks such as:

1. Malicious character encodings that can crash email clients such as Apple Mail.

2. Malicious RFC 2231 continuation indices designed to cause overallocation.

3. Base64 data containing illegal characters such as null bytes.

4. Unterminated comments and quoted-strings.

5. Missing multipart parts (e.g. no terminating boundary delimiter).

6. Malicious data designed to cause CPU-intensive decoding or stack overflows (aka MIME bombs, the email equivalent of zip bombs).

7. Malicious multiple occurrences of crucial headers and parameters, which could cause clients to render an email differently from that scanned by antivirus software.

8. Encoded words containing malicious control characters (cf. Mailsploit).

While it won't prevent this exact attack because it seems to be purely size-based, @ronomon/mime was able to detect attacks such as Tim Cotten's "Ghost Emails" Gmail hack [1] as well as recent CVEs reported against ClamAV [2] and SpamAssassin [3], which are variants of a MIME multipart attack I disclosed through Snyk, "How to crash an email server with a single email" [4].

[1] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hid...

[2] https://blog.clamav.net/2019/11/clamav-01021-and-01015-patch...

[3] http://mail-archives.apache.org/mod_mbox/spamassassin-announ...

[4] https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...

Thanks! That sounds like what I was also thinking.

What pricing plan would work for your family?

"That's how you ensure a system sized to your hardware and ensure maximum throughput for all users."

Sure, I think we are actually in agreement. That's exactly what I meant by "processing cost and complexity analysis".

"When I thought of a reasonable maximum number of attachments on an email I'd probably say 64."

We should not be talking of a "reasonable" maximum at all.

Rather, the maximum should be orders of magnitude away from the "reasonable".

At this distance, any arbitrariness quickly fades into meaninglessness.

Detached from the "reasonable" usage, the maximum then becomes informed by processing cost and complexity analysis, which are more concrete.

"Anything that does not have a limit will eventually be abused by someone."

There should be a law named for this.

What about Limit's Law?

The problem you describe is not actually specific to this approach, the same would apply to any Size check, or any limit in general.

In fact, I think the problem is less relevant to a Quantity check, where an order of magnitude headroom above normal usage goes a long way, more so than a Size check.

For example, do you know of people who receive 10,000 attachments per email? This limit would be far and away above any reasonable usage and yet provide decent protection at the same time.

  Size. A payload of one million characters should probably
  be rejected without further analysis. As well as checking
  the total size, it is good to check the sizes of the parts.

Another thing to check, that is often overlooked, is Quantity.

Every loop should have a limit. There should be no unbounded object allocation. Usually, it's not the big things that get you but the sheer number of small things.

For example, a 20 MB email with 4 million empty attachments:

https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...

Further examples that affected ClamAV and SpamAssassin:

https://blog.clamav.net/2019/11/clamav-01021-and-01015-patch...

http://mail-archives.apache.org/mod_mbox/spamassassin-announ...

I have seen several instances of CVE-2017-11882 malware attachments.

Does anyone have experience writing checks to detect this?

"Problem is... we DON'T have the originals."

That's a common misunderstanding of textual criticism, when it comes to the Bible, often peddled by pop-scholars writing for the masses, who make out that the sheer number of minor textual variants is a major stumbling block in getting back to the original text.

On the contrary, the more copies you have, the better. It's the same with Google, you hope they make thousands of backups, and at different points in time.

With textual criticism, you don't need the originals if you have thousands of copies to compare, in different languages.

Likewise with ancient history, you don't need to have been there, to know that an event happened in the past.

I would encourage you to read people like Bruce M. Metzger, F.F. Bruce, or Paul Barnett if you want to understand the logic of ancient history and textual criticism, or if you want to balance your perspective.

Thanks! I am second-generation Dutch living in South Africa. I speak Afrikaans, so that translation sounded fine to me. Your translation does sound much more flowing.

I hope my point still stands, that what's important ultimately in Ecclesiastes is not so much any superficial style or dialect, but the substance being conveyed.

Of course, Ecclesiastes is full of beautiful poetry, and I appreciate it on that level, but the book is my favorite because of the ideas and lessons being taught, which I think transcend language and culture.

Ecclesiastes is powerful in any human language, and belongs to the whole world, every nation, tribe and tongue. It would be a mistake to make it the sole property and possession of the KJV:

"Siehe an die Werke Gottes; denn wer kann das schlicht machen, was er krümmt?"

"Aanmerk het werk Gods; want wie kan recht maken, dat Hij krom gemaakt heeft?"

"Regarde l'oeuvre de Dieu: qui pourra redresser ce qu'il a courbé?"

"A translation is basically offloading all that to a team of scholars."

Especially a brilliant translation like the ESV.

For example, Peter J. Williams (https://www.crossway.org/authors/peter-j-williams/) is just one of the PHDs who worked on the ESV Translation Oversight Committee. I once listened to a talk Peter gave at St Helens' Bishopsgate (https://www.st-helens.org.uk/resources/talk/51892/audio/) on how translating has improved his confidence in the textual reliability of the manuscripts. I've never heard someone speak so well before.

It's true that reading more than one translation helps, but I find that even just reading a formal equivalence translation such as the ESV, together with a dynamic equivalence transalation such as the old NIV, will get you 98% of the way there, and there are commentaries to help with the rest.

It would be a real shame to never read the Bible in your mother tongue, when so many translators have sacrificed so much to make that possible, simply because one feels it can't be understood unless "you read it in a 100 languages". I think the question then becomes, well, do I want to read and truly understand, am I open-minded or am I just filibustering?

Again, see Fastmail's introduction: https://fastmail.blog/2015/12/20/sanitising-html-the-dom-clo...

No code injection is required. DOM Clobbering simply presents an ambiguous view of the content being sanitized.

"I don't see [DOM Clobbering] as a valid security concern in this case"

It is for sure a valid security concern when doing client-side XSS filtering, which is what the presentation is about. And no, DOM Clobbering does not require an attacker to "have access to the page in your user's security context". Fastmail have an introduction here: https://fastmail.blog/2015/12/20/sanitising-html-the-dom-clo.... Simply put, there's no way to do safe client-side XSS filtering without addressing DOM Clobbering as a valid security concern.

"hardening the DOM won't provide the necessary solution."

And the author is not suggesting or waiting for that. On the contrary, the premise is that XSS sanitizers need to be client-side exactly because the DOM is not hardened and has so many different implementations (even across browser versions). It's counter-intuitive I know, but server-side XSS sanitizers really can't address cross-browser parser differences safely. So again, it's not a question of "stylistic concerns" or "code management" but of doing secure XSS filtering wherever it is best done.

"There are better ways to solve for this."

And if you go on to the next slide, 28, the point is that despite the difficulties, this has been solved in DOMPurify, which should be added to the DOM so that developers can finally have a first-class client-side XSS sanitizer, without having to trust DOMPurify as third-party code.

There are not many people who know more about client-side XSS filtering than Mario Heiderich. And I know of no better client-side solution than DOMPurify.

I used to think the same, except iframe sandboxes:

1. Don't resize dynamically to fit the email content, not unless you enable unique origin JS execution and do message passing to the parent window. But if you do that then you open the door to crypto-mining, tracking, spectre variants, and browser zero-days.

2. Don't play well with keyboard shortcuts since they steal keyboard events from the parent window when focused. Proxying keyboard events to the parent is even more dangerous since an attacker could then spoof keyboard events to control the parent.

3. Don't let you whitelist allowed HTML tags, attributes and CSS properties, which means there's no way to block email tracking.

And that's just for viewing email content. How would you sanitize and whitelist unsafe email content when replying/forwarding?

DOMPurify combined with CSP is safer and stricter. And if you wanted to, there's nothing to prevent you from putting the result in a sandboxed iframe once sanitized anyway. But it needs to be sanitized.

That's not referring to stylistic concerns, and it's not bashing the DOM per se.

The context of "The DOM is a mess!" on slide 27 is specifically in terms of security, namely "DOM Clobbering" where an attacker can rewrite DOM methods from underneath you, and impedance mismatch owing to parser differences and bugs ("HTML elements implemented in completely different ways, different attribute handling" in the context of defending against XSS).

It's an honest assessment that's more a statement of fact than anything intended to be hurtful. It's not even a harsh statement of truth at that. I find it hard to believe that Chrome or Firefox engineers would find that offensive. I think they would well agree.

DOMPurify is really fantastic security work. It would make for a brilliant contribution to the DOM.