kbirkeland

While not explicitly pointed toward SSH, the "Asymmetric signatures" section covers this. Their recommendation is to use Ed25519 and avoid all other options mentioned in the article.

"Explicit is better than implicit" - PEP20

I wouldn't really say that it's a hurdle to greeting the world since you can just throw `print("Hello world")` at the top level.

In this case, it looks like a NASCAR spotter was the winner: https://kickinthetires.net/esports/spotter-josh-williams-ups...

Google scholar returns a pdf[0] when searching the doi.

[0] https://epubs.siam.org/doi/pdf/10.1137/0206025

We're already past 768k and are now around 800k[0].

[0] https://bgp.potaroo.net/as2.0/bgp-active.html

I feel like the last two are cheating a bit by explicitly using 32 bit integers where the other examples seemed to use 64 bit.

Also due to the ambiguity of ports also using a colon delimiter, the IPv6 address may be in brackets:

    [::1:2:0:0:dead:beef]:443

And link-local addresses are mandatory and scoped per interface, so they need a zone id supplied as either an integer or interface name:

    fe80::1:2:0:0:dead:beef%eth0

Leaking a /4 into BGP would do basically nothing unless the originator was originally advertising a /4. IP forwarding is based on the longest-prefix match. Since allocations are sized from /8 to /24, anybody actually advertising their space would not get hijacked by a /4. The leaker would just get traffic destined toward non-advertised networks.

A completely OOB management network is an amazingly high cost when you have presence all over the world. I don't think anybody has gone to the length to double up on dark fiber and OTN gear just for management traffic.

I'm curious what your experiences are here. With enterprise-level networking equipment and LACP (802.3ad), I've never run into any weird issues.

I believe that's an iota (ι) not a 1.

IMO they would have ideally used "key derivation function" instead of "hash function". It could lead those who know enough to be dangerous to think that safely storing passwords is a simple `sha512($password)` away.

I was curious why you added the `-X GET` to that, but it seems twilio returns 405 Method Not Allowed for HEAD requests. Is there any legitimate reason they would block these?

AFAICT still no update out for the android version either

This is useless without authentication though. You're opening yourself up to attacks on the first retrieve. Sure, you can make sure you're getting the file they want you to have, but you don't know _who_ is giving you that file.

That dip is probably not related to the 768k limit. The limit doesnt remove all the current routes, it just doesnt allow for new ones to be installed in hardware. All the routing logic is done in software, so the routes will probably be propagated correctly but not forwarded correctly. See potaroo[0] for other route graphs that don't have the same dip.

The article somehow manages to avoid discerning between control plane and forwarding plane which is a key concept for this issue.

[0]: https://bgp.potaroo.net

Honestly I skimmed the first part of the article and then checked the comments. It may be a design cliche, but it may be true. I didn't make it to that part.

Is your argument that you only need integrity if you verified the authenticity out of band?

A hash only provides integrity. A signature provides integirty and authentication.

Advertising the longest generally-accepted prefix is more of a BGP hijack defense than a DDoS defense. Longest prefix always wins in IP forwarding, so advertising the longest prefix enforces that the best path to you is (usually) selected by local preference or AS path length.

I think the reason for using /30s instead of /31s is mostly legacy. It's a 19 year old standard and most vendors support it.

Regardless of the point-to-point subnet used for the local peering connection, it's interesting that that many /30s have leaked into the default-free zone. BCP 194 recommends filtering IPv4 prefixes longer than a /24.

Isn't this what git lfs[0] sets out to solve?

[0] https://git-lfs.github.com/

> that's when I learned the difference between being right, and being right in the eyes of the law

It sounds like there's an interesting story here. Care to elaborate more?

The algorithm for generating those tokens is explained in the Lexical Analysis reference[0], and a quick look at the cpython source shows the logic is implemented in Parser/tokenizer.c[1].

[0]: https://docs.python.org/3/reference/lexical_analysis.html#in...

[1]: https://github.com/python/cpython/blob/master/Parser/tokeniz...

I don't know why you think I'm contradicting them. I was just pointing out that there are newer RFCs. They also happen to have a stronger and more complete definition of safe methods.

FWIW RFC 2616 was obsoleted by the newer HTTP/1.1 RFCs: https://tools.ietf.org/html/rfc7231#section-4.2

Besides security policy, mDNS uses a link-local multicast address, so routers will not forward it to other network segments. Many operators utilize a number of VLANs on their wireless networks, so this creates an issue when devices in separate VLANs attempt to discover each other over mDNS.

This is usually solved through some sort of mDNS proxy, but you don't really want to proxy everything. If your phone discovered all of the apple tvs and chromecasts across campus, then it wouldn't make for a good user experience for anybody.

While the rant is valid, I feel like the amount of effort venting about this was equal to or more than actually attempting to get this to work. The author claims that there is "a fair amount of multicast in play which could be part of the issue," but there are no inherent issues with multicast over wifi. My suspicion is that it uses mDNS or some other _link-local_ multicast protocol for discovery. This isn't really news though; any network operator that supports Apple TVs, Chromecasts, etc on their network has had to deal with this (and most vendors have solutions for proxying mDNS).

64 bit pointers are pretty important for security. When using ASLR, a certain number of the bits cannot be randomized. This leaves you with a randomization space of about 12 bits with 32-bit addresses, but over 40 bits of randomization with 64 bit addresses.

He also did one for 2017[0]. I imagine if he does this one it will end up in the same repo.

[0] https://github.com/norvig/pytudes/blob/master/ipynb/Advent%2...