Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curious case of the missing period

tjaart.substack.com

Post reply on HN
Print view View original

151–160 of 201 posts

Re: The curious case of the missing period

#151

Post by angst_ridden »

HankB99 wrote: post #98
Biganon wrote: post #80

Earlier quoted context omitted.

Please refrain from willingly picking the naive interpretation when you've understood my point perfectly fine, it's against the rules of this website. ...sigh: Secret codes as in "watermark-level omission of characters" are a myth. Lingo and jargon do however exist, and convey meaning in a particularly subtle way. They are shared and taught by culture, not by a secret handbook passed down from generation to generatio…

This reminds me of the joke whose punch line is > You will be lucky to have this person work for you.

"I cannot recommend X too highly. X always served as an example to their colleagues. The quality of X's code was unequalled in our department, and X's work always merited special attention." (etc)

Re: The curious case of the missing period

#152

Post by bruce343434 »

vardump wrote: post #124
bruce343434 wrote: post #81

As someone who configures email servers for a living (among other things): email needs to be replaced, frankly. This is a stupid protocol with even stupider file formats. What is the reason for such a hard coded line limit? It's just a stream of bytes... Not to mention all the weird bandaids on top of bandaids to try to get sender verification and tamper proof emails working. That alongside the complete lack of end t…

You’re not wrong, but how would you suggest to accomplish this? Replacing whole email infrastructure seems nearly impossible.

My hope is that people move away from email as they get tired by it, and towards more convenient instant messaging platforms which pretty much get the feature set right (attachments, encryption, blocking/spam provisions, provenance, "stories" and special group chat modes for broadcasting) and for which open protocols arise ((are being forced by the eu)): https://www.theverge.com/2024/2/6/24063705/whatsapp-interope...

In the future, I hope that email will be like fax, or at least treated like http in comparison to instant messaging (https).

Re: The curious case of the missing period

#153

Post by renewiltord »

Suspected it was the 990 char limit per line but this is another one. I assume this is an old system? Despite many claims about “best practices”, there were definitely past platforms where these didn’t exist and a minimal implementation was safer just because you knew the scope of error.

Of course if it was modern, different question.

Re: The curious case of the missing period

#154

Post by spankalee »

TeMPOraL wrote: post #122
evmar wrote: post #5

> A portion of this code implemented a SMTP client. If I wanted to root cause this, the real problem is right there. Implementing protocols correctly is hard and bugs like in the post are common. A properly implemented SMTP client library, like one you would pull off the shelf, would accept text and encode it properly per the SMTP protocol, regardless of where the periods were in the input. The templating layer shoul…

The real problem isn't the protocol, but the cowboy approach to interacting with it. It's not hard to "accept text and encode it properly per the SMTP protocol", you just need to realize you need to do it in the first place. There is a multitude of classes of errors and security vulnerabilities, including "SQL injection", XSS, and similar, that are all caused by the same mistake that this case of missing period was[0…

> [1] - Templating systems themselves are thus a mistake belonging to this class

This is not universally true.

JavaScript has an amazing feature called tagged template literals which let you tag a string with interpolations with a function that handles the literal and interpolation parts separately. This lets the tag function handle the literals as trusted developer written HTML or SQL, and the interpolations as untrusted user-provided values.

Lit's HTML template system[1] uses this to basically eliminate XSS (there are some HTML features like "javascript: " attributes that require special handling).

ex:

    html`Hello, ${name}`
If `name` is a user-provided string, it can never insert a or tag, etc., because it's escaped.

There are similar tags for SQL, GraphQL, etc. Java added a similar String Templates feature in 21.

[1]: https://lit.dev/docs/templates/overview/

Re: The curious case of the missing period

#155

Post by treflop »

pja wrote: post #128
throw10920 wrote: post #103

Earlier quoted context omitted.

The real problem is that SMTP is a "plain-text" protocol that includes in-band signaling. It literally happened because SMTP defined "a line that only contains a single period in it" as a control sequence and not a literal line that only contains a single period in it. SMTP is an example of an unnecessarily complex design, and the implementation bugs reflect it. SMTP shouldn't be hard for someone to correctly impleme…

At some point, all protocols include in-band signalling somewhere: You have to put packets on the line, and those packets are ultimately just a stream of anonymous bytes. If it wasn’t a period, it would be something else & you’d have to handle that instead.

From my experience, almost no protocols have in-band signaling. No protocol I’ve ever built has in-band signaling because it’s nuts.

You always know what the next byte means because either you did a prefixed length, your protocol has stringent escaping rules, or you chose an obvious and consistent terminator like null.

Re: The curious case of the missing period

#156

Post by doktrin »

angst_ridden wrote: post #151
HankB99 wrote: post #98

Earlier quoted context omitted.

This reminds me of the joke whose punch line is > You will be lucky to have this person work for you.

"I cannot recommend X too highly. X always served as an example to their colleagues. The quality of X's code was unequalled in our department, and X's work always merited special attention." (etc)

> I cannot recommend X too highly

This isn't a veiled statement. It's outright dunking on the applicant.

Re: The curious case of the missing period

#157

Post by cratermoon »

spankalee wrote: post #154
TeMPOraL wrote: post #122

Earlier quoted context omitted.

The real problem isn't the protocol, but the cowboy approach to interacting with it. It's not hard to "accept text and encode it properly per the SMTP protocol", you just need to realize you need to do it in the first place. There is a multitude of classes of errors and security vulnerabilities, including "SQL injection", XSS, and similar, that are all caused by the same mistake that this case of missing period was[0…

> [1] - Templating systems themselves are thus a mistake belonging to this class This is not universally true. JavaScript has an amazing feature called tagged template literals which let you tag a string with interpolations with a function that handles the literal and interpolation parts separately. This lets the tag function handle the literals as trusted developer written HTML or SQL, and the interpolations as untr…

> If `name` is a user-provided string, it can never insert a or tag, etc., because it's escaped.

Be careful with that "never". A curious and persistent person might discover a bug in the implementation, leading to something like the Log4Shell issue.

Re: The curious case of the missing period

#158

Post by yencabulator »

treflop wrote: post #155
pja wrote: post #128

Earlier quoted context omitted.

At some point, all protocols include in-band signalling somewhere: You have to put packets on the line, and those packets are ultimately just a stream of anonymous bytes. If it wasn’t a period, it would be something else & you’d have to handle that instead.

From my experience, almost no protocols have in-band signaling. No protocol I’ve ever built has in-band signaling because it’s nuts. You always know what the next byte means because either you did a prefixed length, your protocol has stringent escaping rules, or you chose an obvious and consistent terminator like null.

SMTP has stringent escaping rules. The authors of the code in the article were incompetent.

Re: The curious case of the missing period

#159

Post by thedanbob »

doktrin wrote: post #156
angst_ridden wrote: post #151

Earlier quoted context omitted.

"I cannot recommend X too highly. X always served as an example to their colleagues. The quality of X's code was unequalled in our department, and X's work always merited special attention." (etc)

> I cannot recommend X too highly This isn't a veiled statement. It's outright dunking on the applicant.

It can be interpreted both ways: "I cannot recommend X too highly (because they suck)" vs "I cannot recommend X too highly (because whatever praise I give will be inadequate)"

Re: The curious case of the missing period

#160

Post by Learner100 »

roer wrote: post #113
Learner100 wrote: post #112

- The SMTP client they implemented could insert a newline such that a line was comprised of only a single period. - The SMTP client spec says that an additional period would be added here. - The SMTP server spec says that it would remove this additional period, bringing us back to one period. I don’t get how this led to there being no period at all. Am I missing something?

The spec says that an additional period should be added on the client, but their implementation did not do that.

Ah, thanks!
Post reply on HN