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

171–180 of 201 posts

Re: The curious case of the missing period

#171

Post by pja »

TeMPOraL wrote: post #140
throw10920 wrote: post #134

Earlier quoted context omitted.

> all protocols include in-band signalling somewhere That's an incredibly reductionistic view of the world that's utterly useless for anything (including actually engineering systems) except pedantry. It's obvious that the level at which you include control information is meaningful and significantly affects the design of the protocol, as we see in the submission. Directly embedding the control information into the m…

No, it's not reductionist and pedantic. It's a reminder that there is no magic. Building an abstraction layer that separates control and data doesn't win you anything if, like the people in the article, you then forget it's a thing and write directly to the level below it.

> No, it's not reductionist and pedantic. It's a reminder that there is no magic.

Exactly! This is an even better phrasing of my point.

Re: The curious case of the missing period

#172

Post by KwanEsq »

boxed wrote: post #76
Biganon wrote: post #75

Earlier quoted context omitted.

Secret codes being used in recommandation letters are an urban legend. HR people have no incentive to create a secret code for them and their potential rivals, let alone teach it to new HR people while also keeping it secret. This legend comes from the fact that HR people cannot be too explicit about the fact that you've been a pain in the ass (you could probably sue if it's too transparent), so if they have nothing…

So.. secret codes are a myth, and here are some examples of secret codes?

"Damning with faint praise" is hardly a secret code.

Re: The curious case of the missing period

#173

Post by bronson »

markisus wrote: post #138
Gigachad wrote: post #130

Earlier quoted context omitted.

This doesn’t seem like a real issue. Servers can handle a several megabyte executable, and CVE warnings for libraries you aren’t using can be ignored.

In the hypothetical above, you won’t have any way to know which libraries are actually being used unless you read through the source code. Many libraries will transitively include protobuf, but most functions will not call protobuf.

Agreed. Even if you establish that it's not being used today, that doesn't mean that it will continue to be unused after the next few commits land.

And, even though you might not see a way to call into the unused code, an attacker might find a way (XZ Utils).

Re: The curious case of the missing period

#176

Post by treflop »

pja wrote: post #170
treflop wrote: post #155

Earlier quoted context omitted.

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.

If your metadata about the data is in the same channel as the data then you’re doing in-band signalling.

Not in modern times.

The terms harken back from the day of circuit switched networks but now that we have heavily transitioned to packets, bands are an artificial construct on top of packets and applying the term isn’t very clear cut.

The main property of in-band data in the circuit-switched network days is that you could inject commands into your data stream. If we apply that criteria that to a modern protocol, even if you mix metadata and data in the same “band,” if your data can never be interpreted as commands then “out of band” makes an apt description.

See https://en.m.wikipedia.org/wiki/Out-of-band_data

Re: The curious case of the missing period

#178

Post by Animats »

throw10920 wrote: post #103
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 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…

SMTP is that way because running the entire contents of a message through some escape character processing was expensive back then, in the era of 0.25 MIPS machines.

Re: The curious case of the missing period

#179

Post by kjellsbells »

throw10920 wrote: post #144
TeMPOraL wrote: post #140

Earlier quoted context omitted.

No, it's not reductionist and pedantic. It's a reminder that there is no magic. Building an abstraction layer that separates control and data doesn't win you anything if, like the people in the article, you then forget it's a thing and write directly to the level below it.

> No, it's not reductionist and pedantic. It's very reductionistic, because it intentionally ignores meaningful detail, and it's pedantic because it's making a meaningless distinction. > It's a reminder that there is no magic. This is irrelevant. Nobody is claiming that there's any magic. I'm pointing out the true fact that details about the abstraction layers matter . In this case, the abstraction layer was poorly-d…

I dont disagree with your criticisms of SMTP, but reading those early RFCs (eg 772) is a reminder of what a wildly different place the Internet was back then, and in that light, I feel it only fair to grant some grace.

MTP had one concern which was to get mail over to a host that stood a better chance of delivering it, where the total host pool was maybe a hundred nodes?

I speculate that Postel and Sluizer were aware of alternatives and rejected them in favor of things that were easily implemented on highly diverse, low powered hardware. Not everyone had IBM-grade budgets after all.

Alternative implementations of mail that did follow the kinds of precepts that you suggest existed at one time. X.400 is the obvious example. If I recall correctly, it did have rigorous protocol spec definitions, message length tags for every entity sent on the wire, bounds and limits on each PDU, the whole hog. It was also crushed by SMTP, and this was in the era when you needed to understand sendmail and its notoriously arcane config to do anything. So sometimes the technically worse solution just wins, and we are stuck with it.

Re: The curious case of the missing period

#180

Post by smallnamespace »

throw10920 wrote: post #144
TeMPOraL wrote: post #140

Earlier quoted context omitted.

No, it's not reductionist and pedantic. It's a reminder that there is no magic. Building an abstraction layer that separates control and data doesn't win you anything if, like the people in the article, you then forget it's a thing and write directly to the level below it.

> No, it's not reductionist and pedantic. It's very reductionistic, because it intentionally ignores meaningful detail, and it's pedantic because it's making a meaningless distinction. > It's a reminder that there is no magic. This is irrelevant. Nobody is claiming that there's any magic. I'm pointing out the true fact that details about the abstraction layers matter . In this case, the abstraction layer was poorly-d…

> or JSON encoding

JSON needs to escape backslashes, SMTP needs to escape newline followed by period. If you're already accepted doing escaping, what's the issue?

Post reply on HN